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_at_REVISION_Y, i.e. a changeset T_at_X->T_at_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.
Received on 2013-11-14 10:53:08 CET