Re: Numeric Revision Names?

[Stephen Haberman <stephen@exigencecorp.com>]

> You might as well use the commit (not author!) timestamp for that
> purpose (assuming your clocks are all synced).

True. Revision numbers are typically shorter though. E.g. we're on
~19,000 now, which is less digits than 20081003122101.

> They do not convey history membership, only history non-membership,
> for the same obvious reason that commit timestamps do.

I know--see my explicit disclaimer about false negatives in my previous
post.

I'll nit pick, revision numbers if put together with branch name, can
actually occassionally convey history membership (subject to false
negatives).

For example, our bug fix hook will say "hashX committed on topica as
r100" and so if qa is looking at a build that was built while on topica
at r105 (so labeled) "topica-r105") then it is very likely hashX is on
the box.

Okay, not with branch renames, but for all intents and purposes. Of
course, as you point out, topicb-r106 says nothing about the
availability of hashX, but that is a less common question for our qa
team than the first two. And they ask the question often enough during
the day that addressing the major 2 of the 3 cases helps cut down "hey
dev--I've got this hash..." calls.

Do not confuse my willingness to hack commit numbers into our git repo
(and my willingness to share our hack with the original poster) with
full fledged support of the concept. Hashes are superior, but, when
they work, revision numbers are nice too. I did not see a reason we
could not have both, especially if it made people more comfortable with
git.

(I also face/faced a situation where "monotonic revision numbers" were
essentially a check box item on a required list of SCM features, so
despite whatever I/the-git-team/etc. thought about their technical
inferiority, it was a criteria that could have ruled git out for us.
Hence my mentioning an FAQ entry for others faced with my same
political situation.)

- Stephen