[Svnmerge] Merge Issues

[Blair Zajac]

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

Blair