infinite recursive merging

[nico <ni...@gmail.com>]

Hello dear SVN users,

I have a problem with the merging mecanism in SVN.

Here is a litttle case study:
We have 2 branches (B1, and B2) and the trunk (T), if you do the following:
commit -> Branch
merge B1 -> T
merge T -> B2  (to propagate the change)
Then if I look to which changes are eligible for merging from B2 to the
trunk, the T->B2 is eligible !!!

It shouldn't be the case, right ? because the merginfo should be able to
track it back to the already merged change from B1 ->T.

Am I right in my assumption ?
Can somebody explain me ?

thanks a lot,
nico

-- 
|_|0|_|
|_|_|0|     Nicolas  HUOT
|0|0|0|

Re: infinite recursive merging

[nico <ni...@gmail.com>]

Thanks stefan... I guess i got it now.

But then there is only one way of using the development branches scheme
right: to merge from branches to branches until the latest make it to the
trunk...
Le 14 nov. 2013 10:49, "Stefan Sperling" <st...@elego.de> a écrit :

> On Wed, Nov 13, 2013 at 02:05:53PM +0100, nico wrote:
> > Hello dear SVN users,
> >
> > I have a problem with the merging mecanism in SVN.
> >
> > Here is a litttle case study:
> > We have 2 branches (B1, and B2) and the trunk (T), if you do the
> following:
> > commit -> Branch
> > merge B1 -> T
> > merge T -> B2  (to propagate the change)
> > Then if I look to which changes are eligible for merging from B2 to the
> > trunk, the T->B2 is eligible !!!
> >
> > It shouldn't be the case, right ? because the merginfo should be able to
> > track it back to the already merged change from B1 ->T.
> >
> > Am I right in my assumption ?
> > Can somebody explain me ?
> >
> > thanks a lot,
> > nico
> >
> > --
> > |_|0|_|
> > |_|_|0|     Nicolas  HUOT
> > |0|0|0|
>
> Do you believe it is safe to assume that the B1->T merge applies
> the same semantic changes as the T->B2 merge?
>
> If so, do you still believe so if you take into account additional
> changes made for conflict resolution during merges?
>
> Couple that with the fact that merge-tracking considers a path+revision
> pair is the basic unit of a change set, with no ability to consider just
> a subset of changes made to a file in a given revision, and the problem
> should become apparent.
>
> If Subversion assumed that B1->T == T->B2, it might miss additional
> changes that may have been needed as part the B1->T merge. The B1->T
> merge creates a new T@REVISION_Y, i.e. a changeset T@X->T@Y that might
> differ from the merged change on made on B1. I think it would be wrong
> for Subversion to ignore these additional changes during the T->B2 merge.
>
> It is unclear to me what exactly you mean with "commit -> Branch".
> Can you clarify what that is supposed to mean? If it is a commit made
> on B2, you're merging that change in a cyclic way, since the change
> eventually ends up in B2 again. That will invariably result in problems,
> for virtually any given version control system (yes, some cope better
> than others, but the core problem here is that software doesn't grasp
> the semantics of a change). You'll get repeated applications of the
> same changeset, and will need to resolve conflicts because of that
> since there is no way to make a smart decision in software.
>
> Generally, the best way to avoid this problem is to not merge in cycles.
> Draw a flow diagram of your branches, with arrows to indicate possible
> merges between them. If you follow these arrows and ever end up merging
> a change that originated from a given branch to that same branch again,
> your merging strategy is flawed because it will trigger unneeded conflicts.
>

Re: infinite recursive merging

[Stefan Sperling <st...@elego.de>]

On Wed, Nov 13, 2013 at 02:05:53PM +0100, nico wrote:
> Hello dear SVN users,
> 
> I have a problem with the merging mecanism in SVN.
> 
> Here is a litttle case study:
> We have 2 branches (B1, and B2) and the trunk (T), if you do the following:
> commit -> Branch
> merge B1 -> T
> merge T -> B2  (to propagate the change)
> Then if I look to which changes are eligible for merging from B2 to the
> trunk, the T->B2 is eligible !!!
> 
> It shouldn't be the case, right ? because the merginfo should be able to
> track it back to the already merged change from B1 ->T.
> 
> Am I right in my assumption ?
> Can somebody explain me ?
> 
> thanks a lot,
> nico
> 
> -- 
> |_|0|_|
> |_|_|0|     Nicolas  HUOT
> |0|0|0|

Do you believe it is safe to assume that the B1->T merge applies
the same semantic changes as the T->B2 merge?

If so, do you still believe so if you take into account additional
changes made for conflict resolution during merges?

Couple that with the fact that merge-tracking considers a path+revision
pair is the basic unit of a change set, with no ability to consider just
a subset of changes made to a file in a given revision, and the problem
should become apparent.

If Subversion assumed that B1->T == T->B2, it might miss additional
changes that may have been needed as part the B1->T merge. The B1->T
merge creates a new T@REVISION_Y, i.e. a changeset T@X->T@Y that might
differ from the merged change on made on B1. I think it would be wrong
for Subversion to ignore these additional changes during the T->B2 merge.

It is unclear to me what exactly you mean with "commit -> Branch".
Can you clarify what that is supposed to mean? If it is a commit made
on B2, you're merging that change in a cyclic way, since the change
eventually ends up in B2 again. That will invariably result in problems,
for virtually any given version control system (yes, some cope better
than others, but the core problem here is that software doesn't grasp
the semantics of a change). You'll get repeated applications of the
same changeset, and will need to resolve conflicts because of that
since there is no way to make a smart decision in software.

Generally, the best way to avoid this problem is to not merge in cycles.
Draw a flow diagram of your branches, with arrows to indicate possible
merges between them. If you follow these arrows and ever end up merging
a change that originated from a given branch to that same branch again,
your merging strategy is flawed because it will trigger unneeded conflicts.