Re: Numeric Revision Names?

From: Thomas Rast <trast@student.ethz.ch>
Date: Oct 3, 2008, 17:13 UTC
Message-ID: <200810031913.55594.trast@student.ethz.ch>
In-Reply-To: <20081003115557.08d80c2f.stephen@exigencecorp.com>

Stephen Haberman wrote:

Show 17 quoted lines

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