[Svnmerge] Merge Issues

[Prakash P M S]

> Date: Wed, 11 May 2011 22:17:53 -0700
> From: blair at orcaware.com
> To: prakashpms at hotmail.com
> CC: svnmerge at orcaware.com
> Subject: Re: [Svnmerge] Merge Issues
> 
> On 5/11/11 1:35 AM, Prakash P M S wrote:
> >
> >  > 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.
> 
> I definitely don't think it should merge into foo.c.working as that would get 
> confusing where the last merge went, or if all merges after a conflict where 
> into .working.  What happens if you have multiple conflicts, then do they get 
> merged into .working for each conflict?
> 
> I could see the addition of a flag, --stop-on-conflict, that would stop the 
> merge process from continuing.  This would be generally useful.  Patches welcome!
> 

Thanks for the reply. Other than using svnmerge.py, I have never looked at the contents. I will check and see if I can add this option.

-- Thanks
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/svnmerge/attachments/20110512/99e62029/attachment.html>