[Svnmerge] Merge Issues

[Prakash P M S]

> From: blair at orcaware.com
> Date: Tue, 10 May 2011 09:41:03 -0700
> To: prakashpms at hotmail.com
> CC: svnmerge at orcaware.com
> Subject: Re: [Svnmerge] Merge Issues
> 
> 
> On May 9, 2011, at 2:28 AM, Prakash P M S wrote:
> 
> > 
> > 
> > > From: blair at orcaware.com
> > > To: prakashpms at hotmail.com
> > > Date: Sun, 8 May 2011 23:36:26 -0700
> > > CC: svnmerge at orcaware.com
> > > Subject: Re: [Svnmerge] Merge Issues
> > > 
> > > 
> > > On May 8, 2011, at 11:08 PM, Prakash P M S wrote:
> > > 
> > > > > From: blair at orcaware.com
> > > > > To: prakashpms at hotmail.com
> > > > > Date: Fri, 6 May 2011 15:41:26 -0700
> > > > > CC: svnmerge at orcaware.com
> > > > > 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
> 

While it is true that svnmerge.py is not resolving conflicts, isn't it fair to expect it stop merging subsequent revisions when there is a conflict raised due to previous revision merge and not add the revisions to svnmerge-integrated property? It should summarize with the list of revisions that are not merged due to prior conflict, so that they can be force merged using svnmerge.py after resolving the conflict. Or it should merge the changes to foo.c.working instead of foo.c in conflict scenarios.

-- Thanks
Prakash
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/svnmerge/attachments/20110511/340c9623/attachment.html>