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.
