Merging Branches with Binaries

A. S. Budden abudden at gmail.com
Thu Mar 4 07:58:25 GMT 2010


On 19 February 2010 22:00, Eric Siegerman <lists08-bzr at davor.org> wrote:
>> With bzr 2.1.0+ you can create a per-file merge plugin, that
>> checks for any file ending in .axf and just always selects
>> OTHER.
>
> Well, as you've recognized, neither .THIS nor .OTHER is a
> particularly useful choice, as neither one corresponds to the
> sources; whichever one you pick is basically just a placeholder
> to keep the tree (and the VCS?) happy until you get a chance to
> do a new build from the just-merged sources.
>
> Rather than arbitrarily picking one of the parent Out.axf
> variants, it might be safer for the .axf merge plugin to write a
> file that's explicitly a placeholder.  That would eliminate the
> risk of somebody checking out the revision and getting confused
> by the fact that the behaviour of Out.axf doesn't match what the
> sources say it should be doing.  That sort of confusion is bad
> enough in a working tree; how much worse in a committed revision?
>
> I'm thinking of the logical equivalent of:
>        echo >Out.axf "I am a placeholder; don't expect me to work!"
>        touch -t 19700101 Out.axf
> (The "touch" is to give the file a very old change timestamp,
> to ensure that the build system considers it out of date.)
>
> John (or other bzr folks): will that totally thrash bzr's delta
> compression, or can bzr look back more than one rev. for a base
> to generate deltas against?  (I have no idea how much scope there
> is for delta compression of .axf files, but the workflow
> situation could arise with any generated-file format, some of
> which might be fairly delta-compressible.  Some might even be
> highly redundant text, like Autoconf "configure" scripts :-).)

Sounds like a sensible approach.  I think for now, we'll stick with
just picking one of the .axf files, but I agree that it makes sense
not to do this.  Perhaps if someone can comment on the way the delta
compression works then I might change to a different scheme.

>> What would be REALLY clever would be a means of picking the
>> build number file that has the highest version number, but perhaps
>> that's a bit of pipe dream!
>
> You could write a per-file merge plugin for this too.  But again,
> looking at the bigger picture:
>
>> > trunk: r1 -- r2 -- r3 -- r4 -- r5
>> >               \                /
>> > br1:          R2 -- R3 -- R4 -/
> (I've capitalized br1's revisions, for easier reference)
>
> Are build numbers meaningful for any branch other than trunk?  It
> looks to me as if they aren't, and worse than that, you can get
> duplicates -- r3 and R2 are going to have the same build number,
> i.e. r2+1, no?  Or else r3 and R3 will have the same build
> number.  Either way, two builds with the same number is another
> recipe for confusion.
>
> Basically, ISTM that a simplistic "this_build = last_build + 1"
> algorithm isn't very well suited to the DVCS world.
>
> An alternative might be to assign the build number dynamically:
>        if `bzr nick` == "trunk"
>                build_number = `bzr revno`
>        else
>                build_number = 0
>
> That way, for a build that has a non-zero build number, you know
> immediately that (a) it's an "official" build from trunk, and
> (b) which rev. it was built from.  Conversely, if a binary
> reports its build number as 0, you know it came from a branch
> other than trunk, and so isn't official.
>
> Note that this suggestion depends on the fact that we only use
> revno's from *one* branch, and it pretty much requires setting
> append_revisions_only on that branch, to prevent duplicate build
> numbers as a result of uncommit's.
>
> Question: Is append_revisions_only sufficient protection?  Or
> even with it set, are there funky things that can happen to a
> branch's revno's that would make them non-monotone-increasing?

In theory this sounds like a good approach.  I'm a bit concerned about
using the bazaar revision number, partly because of the messy-ness of
trying to implement back-tick like things in Windows (most users don't
have python installed, just the standalone bazaar) and as a matter of
policy, we don't like the build chain itself to be dependent on too
many external tools (such as bzr.exe for example).  Build numbers
aren't absolutely critical, so it's not the end of the world if they
are duplicated.

What I've adopted as an alternative is a strategy whereby when merges
are done (usually into trunk), the build number is chosen to be (this
+ other - base), so if base is 10, this is 12 and other is 13, the new
build number is 15.  A bit arbitrary, but it should be sufficient for
our purposes.

Thanks for the advice,

Al



More information about the bazaar mailing list