Merging Branches with Binaries

[Eric Siegerman]

On Fri, 2010-02-19 at 13:12 -0600, John Arbash Meinel wrote:
> A. S. Budden wrote:
> >     bzr:ERROR: No such file:
> >     u'z:/path/to/Out.axf'
> >     [IGNORE], [CLOSE]
> >
> > [plus other problems with revert from bzr-explorer]
> 
> This sounds like a bug in bzr-explorer or qbzr, which may be fixed in
> 2.1.0 (once we sort out the installer issues).

If these bzr-explorer issues have indeed been fixed, great.  But
if not, a workaround would be to bypass bzr-explorer and use
the command-line:
	bzr revert .../Out.axf


Leaving aside the problems with the tools...

> 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 :-).)


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

  - Eric