[haiku-development] Re: VOTE: Git or Mercurial (hg) as Haiku's new source control tool

  • From: Adrien Destugues <pulkomandy@xxxxxxxxxxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Sat, 14 May 2011 11:59:43 +0100

Le 14/05/2011 10:11, Niels Sascha Reedijk a écrit :

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
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.
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.

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.


Other related posts: