On Fri, 20 Apr 2007, Raman Gupta wrote: > Daniel Rall wrote: > > On Fri, 20 Apr 2007, Raman Gupta wrote: > > > >> [EMAIL PROTECTED] wrote: > >>> On Fri, Apr 20, 2007 at 10:48:04AM -0400, Raman Gupta wrote: > >>>> I can confirm the problem. This is another case of svnmerge.py not > >>>> supporting transitive (or graph-based) merges properly. > >>> I could probably write a test case for this, if someone else thinks they > >>> could track down the problem.. > >> A test case would really help -- the fix should actually be pretty > >> simple -- just ignore any merged changes to any of the svnmerge > >> integrated properties, and set them explicitly at the end of the merge. > >> > >> This would of course prevent merge information from other "distant" > >> branches being merged into the current branch implicitly (the > >> "illusion" of graph-based merging that svnmerge.py currently > >> provides). Personally I consider that a feature -- since I didn't > >> explicitly "init" merging with that distant branch, I don't want > >> unrelated merge information from it cluttering up my target branch. > > > > TestCase_TestRepo.testMergeWithPotentialPropertyConflict (currently > > XFAIL) in svnmerge_test.py is related to transitive merges. > > That test case will pass with the patch I submitted a few months ago, > although there was debate about transitive information being lost.
Yup, it definitely "fixes" this particular problem (I used your patch while developing the test case :). However, I don't consider the change to be correct, because of its lossy handling of merge history. At the time, we discussed some strategies which could be used to avoid the data loss -- one of those should be pursued instead. I'm spending all my time developing Merge Tracking in Subversion's core, so haven't the bandwidth to spend on this myself. - Dan
pgpfKHybOEPqL.pgp
Description: PGP signature
_______________________________________________ Svnmerge mailing list [email protected] http://www.orcaware.com/mailman/listinfo/svnmerge
