Noob Question: Build number
Rob Landley
rob at landley.net
Wed Nov 28 18:47:17 UTC 2007
On Wednesday 28 November 2007 01:42:53 Dustin Sallings wrote:
> On Nov 27, 2007, at 15:55, Rob Landley wrote:
> > For my projects, I just declare some repository somewhere the
> > master, and then
> > use the index in that to refer to commits.
>
> Why not the global identifier?
Because "commit 250" is easier to use in discussion than "commit cef5bbd777fa"
which is almost impossible to actually remember and which you really have to
cut and paste if you're to have any hope of using.
Plus commit 250 is after 249, so you can estimate newer/older change relative
to what went into the central repository when, for "it used to work, when did
it break" sort of discussions. The hash doesn't give you any relation to any
other commit.
I'm not saying it's perfect, I'm just saying the hashes aren't easy to
discuss.
> > If a change hasn't made it into the main repository, then I
> > generally want to
> > know this. It's a bit like linux kernel development, where somebody
> > says "I
> > encountered a bug in 2.6.23-rc2" and doesn't mention they've added
> > twelve
> > patches of their own to that...
>
> Ah, but 2.6.23-rc2 is a *label* -- a tag that points to
> 2c7522b19c386ed601d27b2aed3e7b84ac7852f0. You can certainly build
> *on* that, but it's no longer 2.6.23-rc2 if you do so. The tree
> identifier gives you a reproducible tree (or at least tells you that
> you can't reproduce it).
If the commit is in the main tree than the index is just as reproducible:
http://landley.net/hg/firmware/rev/242
http://landley.net/hg/firmware/rev/c3d2fd8b45cf
Same commit.
If they're giving you a hash out of their personal tree, and if it's not in
your tree (or in the main tree) then you have to pull their tree to reproduce
it anyway.
> > A distributed model doesn't rule out a reference implementation.
> > Every
> > project has a base tree everybody pulls from on a regular basis, and
> > tries to
> > get changes back into. If there wasn't a base tree you couldn't
> > pull changes
> > from each other, and if nobody ever pulled from the base the project
> > would
> > eventually fragment itself to death.
>
> That's not necessarily true. I bootstrapped an application one night
I say "eventually", and your counter-argument is "one night"?
> using *only* peer-to-peer mercurial with a group of people. Guy One
> says ``Hey, I just implemented x'' and people who care about x say,
> ``hg pull guyone'' -- that model works quite well when you're working
> with a group of people and don't want to set up and maintain
> infrastructure.
In the short term, sure. All sorts of things work in the short term.
Tarballs work in the short term. But it doesn't scale.
> I did eventually put a tree up in a central location where people can
> pull, but bundles are emailed to me when other contributors make
> changes.
So your "eventually" matched mine. I'm confused...
These bundles go into this central reference location so other people get them
when they resync with the reference? I'm guessing here.
> I think I'm the only one who's paid attention to this
> particular repository, though.
Quite possible. I'm unfamiliar with the project you refer to.
> > Distributed development makes synchronizing various trees orders of
> > magnitude
> > easier, but A) people did this before the tools made it easy (Alan
> > Cox comes
> > to mind, and Andrew Morton still does it with scripts), B) it
> > doesn't mean
> > there's no point to the wedge.
>
> I'm not sure I understand your point here. The first version of gnu
> arch was written in shell. You could call mercurial a python script
> if the terminology suits you, but it's still an application to solve a
> problem.
No, I mean that Alan Cox didn't use a distributed version control system to
come out with the -ac linux tree, and Andrew Morton is still using things
like "quilt" and "ketchup" to manage his -mm linux tree. (Doesn't use git,
doesn't use mercurial, doesn't use arch...)
What they _did_ do was flush patches into a central reference tree and drop
the ones they've been holding for too long that didn't go in. Because no
matter how clever your source control system is, it won't automatically port
squashfs from 2.6.20 to 2.6.23 for you.
> >> What you could do is use the changeset hash as the detailed
> >> identifier
> >> of the bug-fix, pasted into the bug-tracker as soon as it's
> >> committed;
> >> but generate "official" builds at some slower rate, like daily, and
> >> tag each one with an incremented build-number. The build number could
> >> then go into the tracker too.
> >>
> >> So for a bug report, the fix info would read like:
> >> * Checked in a fix in revision f4ff14558153
> >> * Appears in build 193
> >
> > In this case, "build number" sounds just like using the index
> > number of
> > changes in http://selenic.com/hg except with less granularity. It
> > can't make
> > it into the build without making it into http://selenic.com/hg
> > first, can it?
>
> Yes. Not every file change is a change set. Not every changeset is
> a build. Not every build is a release candidate. Not every release
> candidate is a release.
>
> Having a build number mean something other than the number of a build
> seems unnecessarily limiting.
Keeping track of build number at all seems like an unnecessary step to me when
you already have a monotonically incrementing counter built into the
repository you're building from, and it has higher granularity than your
build number so when people pull and build their own copies between the
automated builds they can coherently tell you what they were using.
If they say "I built 5540 and it did X" and you last built 5526, you have a
frame of reference. If they say they built 00b812ad67cb then you need to
fire up a gui to have any idea what they're talking about.
> > (You have to be clear that it's change #4023 in the main repository,
> > and that
> > the numbers in anybody else's tree won't match. But it's a really
> > easy way
> > to give a human-memorable URL to the thing. Even
> > http://kernel.org/hg/linux-2.6 is only up to 74k commits so far...)
>
> While that's true, they're not shipping Linux 73,295.
According to hg tags the last one they shipped was 74,284. :) Although in
that case, the hg tree _isn't_ the central repository, it's a converted
mirror of it. Linux uses git.
What I'm saying is that tagging releases with human readable names is great,
it just has very limited granularity. Your build numbers are another version
of tagging. But all versions in a project's central repository are already
tagged with a human readable index number, and I'm trying to point out that
this number can be very useful. Yes, it's local to that tree, but for
purposes of bug hunting I consider that part a good thing.
Rob
--
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
More information about the Mercurial
mailing list