[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] Star merging with 3 branches
From: |
Aaron Bentley |
Subject: |
Re: [Gnu-arch-users] Star merging with 3 branches |
Date: |
10 Dec 2003 09:13:06 -0500 |
On Tue, 2003-12-09 at 13:20, Jan Hudec wrote:
> > But this all means that star-merge is using a totally different
> > algorithm from the one I do by hand:
> >
> > 1. Read merge history file for target ($ less lastmerge)
> > 2. Determine which of the requested changes have been committed to
> > source but not to target. ($ less ../release/lasttag)
> > 3. Apply the selected changes to target. ($cvs update -j foo -j bar)
> > 4. Update merge history for target
> >
> > I'm not sure whether this algorithm is scalable, but it does seem to be
> > automatable. It's rather tricky to do by hand too, so I'd hoped Arch
> > would be able to do it automatically for me.
>
> It's tricky to do by hand principialy. And is impossible to do
> automaticaly, since it does not have universaly defined semantics.
Well, it does sound from other postings like pure-merge is similar to
what I'm doing by hand.
> Problems with semantics arise, when there is no most recent common
> ancestor (but instead several maximaly recent ancestors). When that
> happens, what should happen depends on
I'm not sure how we get maximaly recent ancestors...
>
> > Since it seems that the problem with using star-merge probably came from
> > the abruptness of the changes, so we'll probably hold off using Arch
>
> No. The size of the diffs only matters to diff when it tries to apply
> fuzzy patch. However, the problem itself is mostly making too much mess
> in merging.
Really? If I have a patch A that inserts a line at position 25 in foo.h, and
another patch B that replaces the entire contents of foo.h, it won't be
possible to apply A then B without getting conflicts.
> Please, try to get merge-dependency graph of your branches. Acnestry
> and ancestry-graph commands should help you a lot. Then try to locate
> the common ancestor.
I'm sorry. While can use those commands, I don't know what you mean by
a merge-dependency graph.
Sorry for the vertical graph here, not enough columns in email.
mainline release smallfeatures
|
V
base-0
|
V
patch-2---> base-0
| |
V V
(patch-3) patch-1 ---> base-0
| | |
V V V
patch-4<X---patch-2 patch-1
|
V
patch-2
<X--- is a bogus merge. It was originally done via CVS, and I simply
star-merged, then clobbered with the CVS result. But tla shouldn't know
that I didn't do it by hand.
(Next time, I'm tempted to use dot format instead of ascii art...)
Hmm. I think this might be where I went wrong. Here release--patch-2
actually includes all changes from detour2 up to patch-1, but tla
doesn't know about that. So when it tries to apply patch-1...
>
> * Common ancestor is a revision that is part of both targets.
That would be mainline--patch-2 and prior.
> * Maximal common ancestor is a common ancestor, that is not part of any
> other ancestor.
mainline--patch-2
> * Most recent common ancestor is the maximal common ancestor if and only
> if there is only one. If there is more than one, there is no most
> recent ancestor.
I'm not sure how one would get more than one maximal common ancestor. Unless
merges count in ancestry.
> If you can find the common ancestor, pass it to star-merge as
> --reference and things will work.
Okay, I'll give it a shot once I've rebuilt my tree to reflect the fact
that release--patch-2 includes smallfeatures--patch-1.
> If you can't find it, it's not possible to define semantics of the merge
> anyway, so you can't ask a computer program to solve the mess you have.
What I have isn't a mess. My source management system works fine, I'd just
hoped to automate more of it.
--
Aaron Bentley
Director of Technology
PanoMetrics, Inc.
Re: [Gnu-arch-users] Star merging with 3 branches, Tom Lord, 2003/12/09
Re: [Gnu-arch-users] Star merging with 3 branches, Tom Lord, 2003/12/09