There's also ample room for improvements in some of the algorithms cvs currently use. It positively SUCKS at merging stuff. It can't even work with its own keywords properly.
I no longer count the number of times I've had a *conflict* after a merge on code I committed myself in another tree, just because cvs is stupid enough to not recognize $OpenBSD: 1.1$ vs. $OpenBSD: 1.3$ And we all know that branch-merging doesn't actually work. The process to merge branches I used in the past was: - create the diff I want to use - checkout a pristine tree and apply the diff by hand. - checkout the tree I'm going to work on. - use the cvs merge/commit operations. - wipe out the work tree - cvs check out the result - compare against what I would like to have. - fix all the stupid mistakes cvs did. YES, it is THAT bad. I've done enough gcc merges to know. Ask matthieu@ as well, each xorg merge shows traces of those issues as well. In particular, cvs does resurrect files I explicitly deleted on the branch, for absolutely no good reason. The source code from GNU cvs is FULL of highly special cases that make absolutely NO SENSE in general, are totally non-documented, and were obviously hacked in because some stupid guy needed it for his own very special project with its own hackish rules. I definitely have high hopes opencvs will be better in that regard eventually. I don't care all that much for speed, but hey, when I see a version control system do dumb mistakes it has no business doing, and needing me to fix obvious stuff like that... there's MASSIVE room for improvements.
