Noob Question: Build number

[Matt Mackall]

On Tue, Nov 27, 2007 at 12:40:46AM -0000, blr at robertsr.us wrote:
> >
> > 	You don't need to involve any sort of centralized server or anything
> > of the sort.  It's terribly prone to race conditions, and you can't
> > possibly get it right.
> 
> Are you saying the "Single Central Repository" model (CVSLikePractice)
> won't work?  I was hoping to make the changes required minimal at first,
> and this is documented on the wiki and the hgbook, so I was assuming it
> would be a good first step for a 10-15 developer team using CVS.
> 
> > 	identify tells you the working tree version (i.e. what the user is
> > working on).  If a user has fixed a bug as of version f4ff14558153,
> > then that's all you need to recreate the tree.  Other branch changes,
> > incoming changes that haven't been applied or merged yet, changes that
> > occurred ``after'' the fix, etc... are not interesting to you.
> >
> 
> I'm not sure if I'm not understanding what you're recommending, or if
> you're not understanding what I'm asking (I'm new to drcs).  Developers
> check in fixes for a day or 2 before a new build goes out to the test
> servers.  The testers need to know which fixes are in the build.  If the
> build number is 175, then all the defects that are fixed in builds <= 175
> should be fixed.  Any that got checked in after the CI machine updated and
> built (fixed in > 175) aren't fixed in that build and shouldn't be
> re-tested yet.

Mercurial has several kinds of revision identifiers: revision numbers,
revision ids, tags, and branch names. You probably want to use
revision numbers for your setup, but they have a downside that's
important to understand: not all users will agree on what a
changeset's revision number is. That's because two changesets
committed in parallel on two developers' machines can get the same
number, and those numbers change when they're pushed to the central
server.

Now, so long as your test machines simply pull from your central
server, their changeset numbering will always agree. And then you can
use 'hg id -n' in your build script to get a nice number than people
can compare against the central repo to figure out what's exactly in
the build. But it won't agree with the numbers at their desktop
machines.

So, in general, hg id -i is better because it's unique.

eg:
$ hg id -i   # my current source version
92991422a847
$ hg id -n -r 92991422a # convert that to a local revision number
5546

But you can always use both, for convenience:

$ hg id -in
92991422a847 5546

You could also use tags, but adding a tag for each build will quickly
get annoying.

-- 
Mathematics is the supreme nostalgia of our time.