[Svnmerge] Merge Issues

[Prakash P M S]

> 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.

-- Thanks
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/svnmerge/attachments/20110509/880c4307/attachment.html>