On May 8, 2011, at 11:08 PM, Prakash P M S wrote:
> From: [email protected]
> To: [email protected]
> Date: Fri, 6 May 2011 15:41:26 -0700
> CC: [email protected]
> 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
_______________________________________________
Svnmerge mailing list
[email protected]
http://www.orcaware.com/mailman/listinfo/svnmerge
