> I'm of the monkey-proof school, and
> would argue for making the server keep the metadata.
There are two issues here: separating the metadata from the working area and
deciding whether it belongs on client or server. The first, I think, is the
key point in Steve's note. The second is a separable design decision.
His point about users munging the metadata is also well-taken, however. The
only time that I have ever found it useful to edit the CVS/ files is
removing stale directories from the Entries file. This becomes necessary
when a directory is removed in the repository. Personally, I think that the
need to do so is a (minor) bug in CVS, and that the stuff in the CVS/
directory should be read only.
Oh yes. It's also been useful on occasion to rename the server machine when
the domain name changed, but that's so exceptional that it doesn't really
warrant mention.
If we take the view that the metadata should be altered only by the program,
then I want to propose that we adopt a self-checking format. Off the top of
my head, it seems to me that an ASCII entries file could first give the
number of lines, then the entries, then a final line containing an SHA-1
hash of the preceding content. I'm not pushing an ASCII format here --
actually I favor binary because it discourages munging and avoids line end
problems -- but incorporating the hash is useful.
This seems to solve both problems at once: it lets us store metadata on the
client side where it is very convenient to have it (especially when working
detached), but allows us to detect when it has become corrupted. We can then
worry about how to reconstruct corrupted metadata as a separate problem.
shap
Received on Sat Oct 21 14:36:07 2006