As you say, with the branches in SVN, the revision numbers don't offer anyclear information. With more branches (cheap branching being one of themotivations for switching to a DVCS), SVN-style revision numbers will loseeven more of their meaning. IMO, it doesn't make sense to try to hack a property of centralized VCSs on a DVCS. It is fundamentally incompatible!Niels (hg) and Oliver (git) have both proposed identifiers that provide asmuch information as you can realistically find out about a particular build. In addition, both git and hg offer plenty of functions to locateand visualize a particular changeset. In addition, services such as GitHuboffer the possibility to visualize the history of forks. Just let SVN go and embrace the new technologies.Tons of open source projects have switched to distributed version control. Surely it can't be that bad? If you're afraid of change, there's no reasonto switch the a DVCS.
The SVN number, as I said, is short (5 digits) and convey some useful information (it says when the commit hapenned with regard to other commits). I don't see why this wouldn't work as well for a DCVS. I understand that there is no absolute ordering of commits, in SVN that was already the case, and it worked well. I know the numbers will thus be fuzzy, that is, a commit with a smaller number could land in a branch after another one with a bigger number. But still, the information is pretty useful and I don't see anything technical that would prevent it to work. Likely, the mapping to the way SVN numbers work will not be 1:1. Mabe merging a branch will not create a new commit number, maybe it will change the number of commits that were done in the branch.
I also know these number will only be of any help when working with the central Haiku repository (and yes, we are going to keep one). It also used to be the case with SVN : patches had no commit number before they were actually committed. Did that ever create problems ? I don't think so.
We are hopefully going to see more branches, and less patches. Some of the branches will live on the main Haiku server, and these may or may not get numbering of changesets. We will also likely see branches/forks hapenning on github or bitbucket or whatever other site offering similar services : like patches in the current situation, these won't get a number.
What I want is *not* "as much information as you can realistically find out" : this gets me information about the date&time, the branch where it took place, an incremental distance, and a short hash. I don't need any of this, actually. I need a way to know if a commit is from last week, month, year, or older than that. A full date is good for recent commits, but for older ones it doesn't have any use to get second-precision : only the year "2003" would tell me enough : if you're running that on your computer, upgrade now ! SVN commit numbers have the effect of providing a kind of logarithmic scale easily : look at the first number and you already know something. If it's a 4, the commit is recent. If it's a 2, it's old. then look at more digits if you need so.
The number SVN way is very short, so it's easy to copy around and use on Trac tickets. It gives just the amount of information I need, and it is human-readable and machine-readable.
I know I'll discover a lot of new tools to examine the history, but I still find it unpleasant to work with hashes or the proposed date-branch-number-hash stuff : it's just too long to be easy to work with.
Maybe try to think of it a bit like phone numbers : I know with modern technology, they are not needed anymore we could use some plaintext "place-1stname-lastname-hash" scheme there too. It would work, it would be more readable, when you see something in this format you know who owns it, where does he live. But : * If you want to remember the number, you still have to learn the hash like you had to learn the phone number before
* It's longer to type when you want to dialBoth can be overcome with modern phones having a contact list, but would you forget about phone numbers anyway ? they're easy to share and you don't need a contact list, you can still use them if you know them.
I feel the same for both phone numbers and svn commit numbers : they give you some information, but not everything ; they are short enough to easily work with them (dialing a number or checking out a revision requires only a small amount of typing) ; they are useable both by humans and machines easily. They don't do everything, but we don't expect that from them. There are of course complementary tools to make the life even easier. Maybe they'll fade away over time, but I don't think it's good to have them disapear suddenly. Give us some time to get used to the new tools and stop using the numbers before phasing them out, if that is to ever happen.
-- Adrien.
