Merging Branches with Binaries

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

A. S. Budden wrote:
> 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.

The delta compression can look at a fair number of texts. The specifics
depend a bit on the size of the file, etc. But I would expect that sort
of thing to not have any problems.
...

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

Interesting choice. Another possibility:

  bzr ancestry | wc -l # how many total revisions in the history

As for just having 'bzr.exe' available, if you are writing a per-file
merge hook, then you are running in python anyway, and have access to
'bzrlib'. But whatever works for you.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuPz3kACgkQJdeBCYSNAAPHXACfXrOSCa7Rk0cWvxuQxHaTWNEm
kEkAnjwzpbKgHtpzLTLWEs5TFM9ic7gc
=RQFH
-----END PGP SIGNATURE-----