Le 14/05/2011 10:11, Niels Sascha Reedijk a écrit :
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.Hi, 2011/5/14 Hike Danakian<hdana2@xxxxxxxxx>:On Fri, May 13, 2011 at 10:40 PM, Niels Sascha Reedijk <niels.reedijk@xxxxxxxxx> wrote:a - b - c - d - h \ e - f - g / Now I invite you to tell me whether haiku/master-4-g1234567 refers to changeset 'd' or 'f'.What if you "linearize" it like a - b - c - d - e - f - g - h, assuming the e - f - g branch was merged before h. Of course this wouldn't make much sense in the sense that revision numbers wouldn't exactly represent time, but it would be stable in the sense that a merge would not change previous (b's c's and d's) revision numbers. So a bug ticket's revision number would stay correct even after a later merge.Sure, but the number itself has no meaning, it is not directly usable and creates an assumption of comparability where there is in fact none. Both git and hg contain a lot of tools to query history, and not for nothing. History just cannot be captured by a number anymore. The SHA is king. 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.
Right now, we're going towards 50000 commits. That's 6 digits to look at, a date with second resolution would look like 2011-05-14-11-57-42, 14 digits, 3 times as much. So the information is less dense. An hash is even worse : a lot more digits, and it doesn't convey _any_ readable information as for the commit date or point in "development time". I prefer fuzzy revision numbers to unreadable hashes.