On Wed, Aug 31, 2011 at 7:18 AM, Julian Foad <julian.foad_at_wandisco.com>wrote:
> On Tue, 2011-08-30 at 18:00 +0100, Philip Martin wrote:
> > Paul Burba <ptburba_at_gmail.com> writes:
> >
> > > Could you provide some examples of when 'things start to go wrong when
> > > you next try to use "automatic" merges between the branches'? Was
> > > there a particular use-case (or cases) you had in mind, or just a
> > > general sense that maybe this is/could be a problem?
> >
> > Here's one (shorter recipes are possible):
>
> Yes, this is exactly the sort of thing I mean. What I expect in general
> is that if I have merged the same change into both branches, then an
> automatic (catch-up) merge would do nothing with that particular change.
> But here we reverse-merge the same change into both branches, and then a
> catch-up merge raises a conflict on that change.
>
Wouldn't that be entirely expected given the cyclic merge problem? You made
a change in the source branch and committed it. Instead of merging that
commit to the target branch as you would any other change, you made the same
change on the target branch. But when you synch the target with the source
it is of course going to still try to merge this same change and create a
conflict.
In at least this specific scenario, I do not think the reverse merge is
relevant. Suppose it is just a bug fix. You make the fix in the source.
You are supposed to merge that to the branch. If you instead make the same
fix in the branch, as opposed to merging the fix, then it would be expected
that you get a conflict later when you synch merge.
As long as the merge algorithm is based on merging revisions, I do not see
how you change this.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2011-08-31 14:01:25 CEST