Once again, CVS shows its weaknesses. Last night I committed a fix to pkgsrc and soon after I noticed I had a prior e-mail by Alistair, a member of PMC and the one responsible for the preparation of pkgsrc releases, asking developers to stop committing to the tree because he was going to tag it for pkgsrc-2007Q4. It turns out that my fix did not get into the branch because the directory it went in (devel/monotone) had already been tagged. Had I committed the fix to, say, x11/zenity, it would have gone into the branch. Or worse, had I committed a fix that spanned multiple files, some of them would have got to the branch and others not.

So what, am I supposed to read e-mail before I can do a commit? What if the mail does not arrive on time? What if the commit had affected many more directories and some of them had already been tagged but some not?

This is just another example of CVS showing its limitations and stupidities. Given that each file's history is stored independently — i.e. there are no global changesets — the only way to tag the repository is to go file by file and set the tag on each. And then, you need to check which revision of each file is the one to be tagged. I do not know why is this so slow even when you do a rtag (so the one doing the work is the server alone) on HEAD, but in the case of pkgsrc this process took more than 2 hours!

OK, OK, I'm hiding the truth. The thing is there are some ways around this: for example, using the tag command will tag the exact revisions you have in your working copy, or passing a date to rtag will tag the repository based on the provided timestamp. This way you ensure that the tagging process will be consistent even if people keep committing changes to the tree. However, the first of these commands will require a lot of network communication and the second will put a lot of stress on the server, making the command even slower (or that's what I've been told).

In virtually all other version control systems that support changesets, a tag is just a name for a given revision identifier. And defining this tag is a trivial and quick process. Well, Subversion is rather different because tags are just copies of the tree, but I think that they deal with these efficiently.