On Sat, 14 May 2011 12:59:43 +0200, Adrien Destugues <pulkomandy@xxxxxxxxxxxxxxxxx> wrote:
Le 14/05/2011 10:11, Niels Sascha Reedijk a écrit :That's why I suggest to put in a date. It has one advantage over a generic number and that is that we as humans are better able to perform useful interpretations.The numbers are on a time scale (on svn at least). The unit is not seconds, nanoseconds, or whatever, but number of commits, which is a better indication on how much different two revisions might be. Of course, it isn't as good when branches are involved (the branch may be out of date and the commit won't change that), but that was already the case with svn and never caused problems. Of course, we'll get more branches in the system, but is that really a problem ? We know at some point someone will have to actually dig out the changelog, but the revision number is easy to use for quick overview.
As you say, with the branches in SVN, the revision numbers don't offer any clear information. With more branches (cheap branching being one of the motivations for switching to a DVCS), SVN-style revision numbers will lose even 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 as much information as you can realistically find out about a particular build. In addition, both git and hg offer plenty of functions to locate and visualize a particular changeset. In addition, services such as GitHub offer 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 reason to switch the a DVCS. - Brecht