[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: preliminary version control requirements
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
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
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
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
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
Main Index |
Thread Index |