'merge' merged

[Aaron Bentley]

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

Martin Pool wrote:
> I've incorporated Aaron's patch to add a 'merge' command.  Thanks Aaron!
> 
> At the moment this requires a 'base' revision to be manually
> specified.  The 'base' is some common point between the two trees that
> are to be merged.  For example, if you are merging from my tree into
> yours, then the 'base' will be the previous revision that was merged
> across.
> 
> In the short term there are several things we can do:
> 
> - add online help and instructions into the tutorial
> 
> - automatic selection of a base version

Cool.  I'll be happy to work on automatic selection of a base revision,
I just need a way of finding out which revisions were merged by a
revision, and that will get you 'a better star-merge' (like Fai's).

I know we had rough agreement on the kinds of data needed, i.e. that it
was roughly as in the PatchLogPruning proposal
http://wiki.gnuarch.org/PatchLogPruning

Bzr is more snapshot-oriented than Arch, so I should specify here that
when I say 'a revision has been applied', I mean that the delta between
a revision and its precursor has been applied to the tree.

Merges will need to create some kind of 'PENDING' file.  Since we'll
need to store that data in the commit log, I guess it makes sense to use
XML, so we just need one file.  Maybe merge-pending.xml?

Robert suggested differentiating between cherry-picks and complete
merges, because cherry-picks don't make good bases.

So in revision logs, we'll need something like
<merged-revision>mbp at sourcefrog.net-20050513005732-26b0a3042cbb57d1</merged-revision>

And
<unmerged-revision>mbp at sourcefrog.net-20050513005732-26b0a3042cbb57d1</unmerged-revision>
to represent revisions being taken out.

I think we also agreed to consider that a commit is a merge of itself.
This is a little twisted, I know, but my gut instinct is that it's
right--there's some terminology we're missing here.  Maybe the trick is
to say that a tree 'contains' revisions a, b, and c, where a is an
ancestor, b is the current revision, and c was merged.

There is no need to specifically list the current revision as a merged
revision, but commits should add the newly-committed revision to the
list of merged revisions.

Oh, and it might make sense to include an XML prolog in the revision
logs, like
<?xml version="1.0" encoding="utf-8" ?>

Does this make sense to start hacking on?

> In the longer term, I am not sure that a simple three-way merge will
> really be enough, and we should explore some ideas from arch,
> codeville, and other systems.

Three-way definitely isn't the be-all and end-all, but it's a good place
to start, I think.

Aaron

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCh6BS0F+nu1YWqI0RApSFAJ4xcBUy/syYSi1ULPV+6HQP9nMHywCggS/E
KNn2IPZpq3BfWPF5AVX007c=
=6NFN
-----END PGP SIGNATURE-----