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" <s...@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. >
