On May 9, 2011, at 2:28 AM, Prakash P M S wrote: > > > > From: [email protected] > > To: [email protected] > > Date: Sun, 8 May 2011 23:36:26 -0700 > > CC: [email protected] > > Subject: Re: [Svnmerge] Merge Issues > > > > > > On May 8, 2011, at 11:08 PM, Prakash P M S wrote: > > > > > > From: [email protected] > > > > To: [email protected] > > > > Date: Fri, 6 May 2011 15:41:26 -0700 > > > > CC: [email protected] > > > > Subject: Re: [Svnmerge] Merge Issues > > > > > > > > On May 6, 2011, at 8:05 AM, Prakash P M S wrote: > > > > > > > > > While merging by cherry picking the revisions using svnmerge.py, > > > > > svnmerge.py creates issue if there are merge conflicts. > > > > > > > > > > If two versions 5118 and 5145 are merged, if there is a conflict > > > due > > > > > to revision 5118, it attempts to merge 5145, but the changes of > > > 5145 > > > > > are not merged. When the conflicts are resolved manually, only the > > > > > changes of 5118 are present in the merged file. First it doesn't > > > > > even alert that 5145 changes are not merged, but shows that merge > > > > > being done for that revision. Even if we want to merge it manually > > > > > after resolving first conflict, it doesn't allow to merge as it is > > > > > not a clean workspace. > > > > > > > > > > Is there a better way to handle this with svnmerge.py? > > > > > > > > > > --- Merging r5118 into '.': > > > > > C src/foo.c > > > > > Summary of conflicts: > > > > > Text conflicts: 1 > > > > > > > > > > --- Merging r5145 into '.': > > > > > G src/foo.c > > > > > > > > > > property 'svnmerge-integrated' set on '.' > > > > > > > > The merge of r5145 is showing as being applied, so it's odd that > > > it's > > > > not appearing in the file. > > > > > > > > Are r5118 and r5145 in the same part of the file, +/- 3 lines? > > > > > > > > BTW, if there's a merge conflict, I like to merge r5118, resolve it, > > > > commit it, then merge r5145. This will have the first merge commit > > > > show what was done more clearly. > > > > > > > > Regards, > > > > Blair > > > > > > The change of 5145 is in different part of the file. The merge of > > > 5118 resulted in conflict because 5120 is merged before 5118 and > > > both the revisions were changing at the same part/lines of the file. > > > > > > I cannot commit the first revision alone. svnmerge is used inside a > > > tool that merges the changes selectively from dev to release branch. > > > All changes that go into the build cycle/release has to be merged > > > first, built and tested and then committed. Since svnmerge allows to > > > specify specific versions, I would expect it to merge the changes > > > consolidated and raise conflict only for revisions that has > > > conflict. But the behaviour is that it attempts to merge other > > > revisions, but the changes are not merged. Atleast if there is a way > > > to force merge 5145 after resolving 5118, inspite of unclean > > > workspace, it will work for me. > > > > If I understand you correctly, you're saying that r5145 is not being > > merged? It should be and the output of svnmerge.py is showing that > > the merge is being done, with this output: > > > > > > > --- Merging r5145 into '.': > > > > > G src/foo.c > > > > It would be interesting to run the following two commands in two > > separate, clean checkouts and then do a 'diff -ru -x .svn 1 2' between > > them > > > > svn co http://.../ 1/ > > svn co http://.../ 2/ > > cd 1; svnmerge.py -r 5118; cd .. > > cd 2; svnmerge.py -r 5118,5145; cd .. > > > > By what you're saying, what's in 2 should be the same as 1. > > > > So I would double check to see what it's doing. You can pass -v -v to > > svnmerge.py. > > > > Besides this, if it doesn't work, you could do > > > > svnmerge.py -r 5118 > > svnmerge.py -r 5145 -F > > > > I tried what you said and this is my observation. > > When 5118 is merged, it raises the conflict and so it creates > foo.c.merge-left.r5117, foo.c.merge-right.r5118 and foo.c.working files. When > 5145 is merged, it merges the changes in foo.c and the changes are seen. When > the conflict is resolved, the changes are lost as it is done based on > foo.c.working.
svnmerge.py doesn't resolve conflicts in any files, so whoever is resolving is it causing the changes to be lost. You can grep through svnmerge.py and the string "resolve" doesn't appear anywhere. Blair _______________________________________________ Svnmerge mailing list [email protected] http://www.orcaware.com/mailman/listinfo/svnmerge
