Perry E. Metzger wrote:
Preserving the old version numbers is important because they're recorded all over everywhere (PRs, mailing lists, etc.) and losing the ability to correlate all those reports with the source tree would be a problem.I think there isn't a single VCS that will do that right now. If that were really a requirement, we could never upgrade from CVS. I suspect we're just going to have to manage old file version information by keeping the CVS tree around for a while.
I don't see why you couldn't do that as custom metadata. For example, you could do this in monotone by adding certificates to provide the mapping between old CVS version numbers and monotone versions.
Meanwhile, there are real reasons why hash codes are bad; they're hard for humans to use compared to small integers, and they're not ordered so you can't tell if the version you've got is newer or older than some version someone's posting about wihout digging around.The lack of ordering is certainly a problem. The length might not be a problem in practice -- git and the other systems that use them seem to allow shortest unambiguous prefix, and that's generally only five or six characters.
I don't think that the lack of ordering is as big a problem as some people make out.
The main thing that we seem to use ordering for is to answer the question, "Does this version include fix X?". Serialising all the versions is certainly one way to make it easy to answer that question, but providing that the tools exist to make it easy to answer that question, I don't see the problem.
Again taking monotone as an example, and there's probably a better way to do this, you can do:
mtn automate ancestors `mtn automate get_base_revision_id` | grep <id>to discover if that ID is in the ancestry of the currently checked out revision. (this could of course be put into a wrapper script with a more friendly name)
Regarding the length of the revision ID - despite monotone offering the ability to use short versions of the IDs, I've never felt the need to use them. When using a revision ID, I am either refering to it symbolically via a tag or a selector (such as, "the head of the branch"), or from previous output on my screen from where I can trivially cut&paste.
What the hash-as-a-version-ID scheme buys you is not having to serialise commits at a central server. In particular, it buys you offline commits. It also buys you the ability to do your merges *after* commiting code, so that you have a record of your changes as you originally made them, and if you screw up your merge then at least you can roll back and start the merge again.
I do not know of any VCS which allows true offline commits but doesn't have nonsequential version IDs.
Complete offline operation makes the world of difference to anybody working without a decent net connection, such as people hacking on code while on planes. Having been in that position myself recently, I can't stress the benefits of this enough.
> > - supports rcsids/keyword expansion> > Most of them don't per se do this, in that there aren't version> numbers for individual files in any modern system so there aren't > expandable RCSID equivalents with a file's individual version number. Why would it have to be a file's individual version number? It just has to indicate what stuff a binary file was built with. But we do need something that does that.That particular requirement can be met. However, there is an implicit requirement here that I want to mention is not going to be met.
If you wanted to put an identifier of the source file into the binary, you could do a lot worse than to ask the VCS for the version number of the tree you're building from. Most distributed VCSs should be able to give you the actual version number that would result if you were to immediately commit, and also the base version which was checked out from the repository before any local (not checked in) changes were applied.
We could conceivably get rid of all the existing rcsid strings and arrange something that didn't require keyword expansion directly in files, but it would be a lot of work and a big hassle.I wouldn't mind having to replace them across the whole tree with different names, that would be fairly straightforward work. I agree that having to set up a rube goldberg mechanism would be a big issue.
I don't see a huge amount of value in maintaining this information on a per-file basis if the VCS deals with versioning whole trees. If you want to embed a version number, embed the version number of the whole tree. Let's get rid of per-file RCSIDs if we move away from per-file version numbers.