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" <stsp_at_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_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-24 10:33:21 CET