rlucas.net: The Next Generation Rotating Header Image


Some Gotchas with using svndumpfilter

A few things:

1. svndumpfilter can take multiple args, e.g.

$ svndumpfilter include /x /y /z > mydump

to include /x, and /y, and /z. It can’t, however, do both include and exclude at once. In theory, you can run multiple dumps when you later load them, so you could (sort of; see below) accomplish the sameish thing with

$ svndumpfilter include /x > mydumpx
$ svndumpfilter include /y > mydumpy
$ svndumpfilter include /z > mydumpz

2. HOWEVER, if you have ever MOVED a file within the repository between (in the example above), /x and /y, you can’t rely upon doing it piecewise. That’s because the references within the loading process during the load of /y will no longer be valid as they point to /x/whatever.

3. It is commonly suggested that one edit “Node-path:” entries within the dump in order to fix up directory structure issues. NOTE that you MUST also change “Node-copyfrom-path:” in the same manner. Trickily, Node-copyfrom-path is only present in nodes that were (surprise!) copied from another node. This is of course tied to 2. above.

What is all this about, you ask? Well, it turns out that if you have a single respository with a lot of sprawling projects all under /trunk, you might need to break them out. (For example, if you intend to upload your repository dump to someone like a CVSDude or Beanstalk).

The error message that got me was something like:

svnadmin: File not found: revision 91, path ‘/trunk/x/whatever’

Technologies I want an excuse to use…

  • Cassandra, the Facebook-derived, neither-row-nor-column-oriented-quite, massively distributed data store.
  • New hybrid languages that run atop Java VMs: Scala and Groovy.
  • Hadoop.  Just ‘cuz.
  • The R statistical computing system.

Password Policies Must Be Disclosed!

Most all web applications require some sort of username and password to login. However, you never know upon signing up how the application (site, service, whatever) will treat your password. – Option 1: The app does what all good applications, having been entrusted with your password, ought to do: it passes it through a one-way hash function (ideally with a random salt), and stores /only/ that hash code. There is *no* mathematically feasible way to retrieve your password, given only the hash code (although in some cases dictionary attacks work). Hence, if you forget your password, they have to send you a new one, but at no time does a second human have a chance to see your chosen password. – Option 2: The app is brain-dead, and stores your password in plain-text, (or in a symmetrically encrypted form where the decryption key is programmatically available to the app). These boneheads become recognizable when, upon using the “forgot password” functionality, they /send back your original chosen password in unencrypted email!/ (Dear reader, it should hardly be necessary to describe why this is a problem, but consider that in our wireless age, every unencrypted communication may as well be considered public knowledge.) There are exceptions, of course, where option 2 is quite reasonable; the venerable mailing list manager Majordomo tells you up front, “/Do not use a valuable password as it will occasionally be emailed back to you in cleartext/,” which tells you right up front what the situation is. Yet, any number of ostensibly professionally-run web apps — /many of whom anticipate being the lucky recipient of my credit card number to consummate a transaction/ — cannot be bothered either to properly protect my password or to inform me about their practices. *Therefore, I propose:* a “Password Statement”, as an adjust to or embedded within a site’s privacy and security policies, that describes how they plan on treating your shared secret (password). This statement should be summarized in a one-sentence line next to the password box on the registration dialog, with a link to more information (much as has become the /de facto/ standard for a statement about spam policies). Finally, I propose a voluntary “seal” program whereby a TRUSTe- or Verisign secure site-like seal is made available, subject to a benign entity’s copyright and trademark protection, to both signify a site’s password policy at a glance and to serve as a link to the password statement.