- From an otherwise unhelpful advogato discussion:
# To anyone working on version control: consider robustness.
# Can a user (inadvertently or otherwise) corrupt the repository
# through an otherwise legal set of commands? If the power fails
# halfway through a commit, will the repository be usable when the
# machine comes back up? What happens if the repository disk becomes
The database backend should deal with server-side failures, along with
atomic commits and strong checksums for the repository data files. We
*are* putting strong checksums on the repository files, right?
# CVS falls down in these areas. For example:
# mkdir dir2; cvs add dir2
# cp dir1/* dir2
# (change files in dir2)
# cvs commit dir2
# You have likely screwed yourself here, since the "CVS" directory
# contains metadata, and it was copied into "dir2". One of the
# metadata files is a pointer to the repository directory. When "dir2"
# is committed, the contents of "dir1" in the repository will be
# overwritten. A new user may not realize this, and even experienced
# users are prone to oversights at times. I have done this, and a
# co-worker with 20+ years experience has done this. This problem is
# also messy to correct.
This scenario is difficult to avoid in any arrangement that keeps
metadata in each directory. If the metadata is in .SVN or the like,
ordinary shell globbing won't catch it, but suppose there are
versioned dotfiles (bleah) so I go to the extra effort to get them
This is _not_ solved by rename support. The above operation is a
copy, not a rename - you're cloning some skeleton code to flesh out,
say. Now it would sure be nice if a 'copy' operation was supported in
the repository, so you could see that (e.g.) cp/lex.c was copied from
version 1.234 of c-lex.c [guess what I've been hacking recently :)]
and do diffs across the boundary, and stuff. But that's hard.
Some sort of robustness check ought to be possible - remember the
subdirectory component of the path, compare it to the last component
of the cwd on each operation in that directory. [Or the inode number,
if we don't care about NT.]
Received on Sat Oct 21 14:36:06 2006