[Svnmerge] Merge Issues

[Blair Zajac]

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!

Regards,
Blair