Re: Numeric Revision Names?

Stephen Haberman wrote:

quoted

Second, in my opinion revision numbers are not that useful for
projects with large number of commits (where revision number might be
something like r4321), and nonlinear history (you don't know how r4555
relates to r4556: they might be on different branches).

For projects that do have a central authority (e.g. internal corporate
projects), revision numbers make more sense.

Granted, they are on separate branches (like svn), but the nice thing
about them is that they are monotonically increasing. E.g. our qa
people love numbers--the bug fix ticket says dev just put in
r100...qa/production box says it is on r95. Doesn't matter the
branch/whatever, they know the box doesn't have r100. Now, right, if
its r105, it is trickier, although we also throw in branch name (e.g.
topica-r100) which means no false positives but can lead to false
negatives.

I wonder how that constitutes an argument for revision numbers.

First, the _only_ guarantee you get out of monotonically increasing
revision numbers is that they're ... monotonically increasing.  You
might as well use the commit (not author!) timestamp for that purpose
(assuming your clocks are all synced).  They do not convey history
membership, only history non-membership, for the same obvious reason
that commit timestamps do.

Second, Git can do the check you mention above much more accurately.
If you tell QA that the fix is in 123abc, then 'git branch --contains
123abc' lists all local branches that have the fix, 'git describe
--contains 123abc' gives you the nearest tag (i.e. usually the
lowest-numbered release version number) having the fix, etc.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch