Merge Issues

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Merge Issues

Prakash P M S
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 '.'


_______________________________________________
Svnmerge mailing list
[hidden email]
http://www.orcaware.com/mailman/listinfo/svnmerge
Reply | Threaded
Open this post in threaded view
|

Re: Merge Issues

Raman Gupta
On 05/06/2011 11: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?

I haven't looked at the details of your problem, but assuming
everything you say is true, try cherry-picking one revision at a time.

Cheers,
Raman
_______________________________________________
Svnmerge mailing list
[hidden email]
http://www.orcaware.com/mailman/listinfo/svnmerge
Reply | Threaded
Open this post in threaded view
|

Re: Merge Issues

Blair Zajac
In reply to this post by Prakash P M S
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

_______________________________________________
Svnmerge mailing list
[hidden email]
http://www.orcaware.com/mailman/listinfo/svnmerge
Reply | Threaded
Open this post in threaded view
|

Re: Merge Issues

Prakash P M S
> From: [hidden email]

> To: [hidden email]
> Date: Fri, 6 May 2011 15:41:26 -0700
> CC: [hidden email]
> 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

_______________________________________________
Svnmerge mailing list
[hidden email]
http://www.orcaware.com/mailman/listinfo/svnmerge
Reply | Threaded
Open this post in threaded view
|

Re: Merge Issues

Prakash P M S
In reply to this post by Raman Gupta
> Date: Fri, 6 May 2011 17:42:36 -0400

> From: [hidden email]
> To: [hidden email]
> CC: [hidden email]
> Subject: Re: [Svnmerge] Merge Issues
>
> On 05/06/2011 11: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?
>
> I haven't looked at the details of your problem, but assuming
> everything you say is true, try cherry-picking one revision at a time.
>
> Cheers,
> Raman

I have to merge all revisions that go for the build cycle by either one revision at a time or merging all of them together. But it can be commited only after merging all revisions and testing the workspace.

-- Thanks

_______________________________________________
Svnmerge mailing list
[hidden email]
http://www.orcaware.com/mailman/listinfo/svnmerge
Reply | Threaded
Open this post in threaded view
|

Re: Merge Issues

Blair Zajac
In reply to this post by Prakash P M S

On May 8, 2011, at 11:08 PM, Prakash P M S wrote:

> > From: [hidden email]
> > To: [hidden email]
> > Date: Fri, 6 May 2011 15:41:26 -0700
> > CC: [hidden email]
> > 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
[hidden email]
http://www.orcaware.com/mailman/listinfo/svnmerge
Reply | Threaded
Open this post in threaded view
|

Re: Merge Issues

Prakash P M S


> From: [hidden email]
> To: [hidden email]
> Date: Sun, 8 May 2011 23:36:26 -0700
> CC: [hidden email]
> Subject: Re: [Svnmerge] Merge Issues
>
>
> On May 8, 2011, at 11:08 PM, Prakash P M S wrote:
>
> > > From: [hidden email]
> > > To: [hidden email]
> > > Date: Fri, 6 May 2011 15:41:26 -0700
> > > CC: [hidden email]
> > > 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.

Do you see any changes to svnmerge.py to handle this behaviour?

--Thanks

_______________________________________________
Svnmerge mailing list
[hidden email]
http://www.orcaware.com/mailman/listinfo/svnmerge
Reply | Threaded
Open this post in threaded view
|

Re: Merge Issues

Prakash P M S



From: [hidden email]
To: [hidden email]
Date: Mon, 9 May 2011 09:28:47 +0000
CC: [hidden email]
Subject: Re: [Svnmerge] Merge Issues



> From: [hidden email]
> To: [hidden email]
> Date: Sun, 8 May 2011 23:36:26 -0700
> CC: [hidden email]
> Subject: Re: [Svnmerge] Merge Issues
>
>
> On May 8, 2011, at 11:08 PM, Prakash P M S wrote:
>
> > > From: [hidden email]
> > > To: [hidden email]
> > > Date: Fri, 6 May 2011 15:41:26 -0700
> > > CC: [hidden email]
> > > 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.

Do you see any changes to svnmerge.py to handle this behaviour?

--Thanks

Blair,

I hope you understand the merge scenario now. Is there any suggestion you have?

Regards
Prakash

_______________________________________________ Svnmerge mailing list [hidden email] http://www.orcaware.com/mailman/listinfo/svnmerge
_______________________________________________
Svnmerge mailing list
[hidden email]
http://www.orcaware.com/mailman/listinfo/svnmerge
Reply | Threaded
Open this post in threaded view
|

Re: Merge Issues

Blair Zajac
In reply to this post by Prakash P M S

On May 9, 2011, at 2:28 AM, Prakash P M S wrote:

>
>
> > From: [hidden email]
> > To: [hidden email]
> > Date: Sun, 8 May 2011 23:36:26 -0700
> > CC: [hidden email]
> > Subject: Re: [Svnmerge] Merge Issues
> >
> >
> > On May 8, 2011, at 11:08 PM, Prakash P M S wrote:
> >
> > > > From: [hidden email]
> > > > To: [hidden email]
> > > > Date: Fri, 6 May 2011 15:41:26 -0700
> > > > CC: [hidden email]
> > > > 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

_______________________________________________
Svnmerge mailing list
[hidden email]
http://www.orcaware.com/mailman/listinfo/svnmerge
Reply | Threaded
Open this post in threaded view
|

Re: Merge Issues

Prakash P M S

> From: [hidden email]
> Date: Tue, 10 May 2011 09:41:03 -0700
> To: [hidden email]
> CC: [hidden email]
> Subject: Re: [Svnmerge] Merge Issues
>
>
> On May 9, 2011, at 2:28 AM, Prakash P M S wrote:
>
> >
> >
> > > From: [hidden email]
> > > To: [hidden email]
> > > Date: Sun, 8 May 2011 23:36:26 -0700
> > > CC: [hidden email]
> > > Subject: Re: [Svnmerge] Merge Issues
> > >
> > >
> > > On May 8, 2011, at 11:08 PM, Prakash P M S wrote:
> > >
> > > > > From: [hidden email]
> > > > > To: [hidden email]
> > > > > Date: Fri, 6 May 2011 15:41:26 -0700
> > > > > CC: [hidden email]
> > > > > 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.

-- Thanks
Prakash

_______________________________________________
Svnmerge mailing list
[hidden email]
http://www.orcaware.com/mailman/listinfo/svnmerge
Reply | Threaded
Open this post in threaded view
|

Re: Merge Issues

Raman Gupta

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

Prakash, while I understand and agree that svnmerge.py is not working
optimally in this situation, I suspect that most of the committers
have moved on to using built-in svn merging, and/or other tools that
have better support for merging such as git -- I know I have.
Development of svnmerge.py has thus basically stopped.

Therefore, it is likely that if you want some changes to svnmerge.py
you will have to make them yourself. Once you submit a patch, myself
or one of the other committers will be more than happy to review your
changes for inclusion. Make sure to include a useful unit test.

Cheers,
Raman


_______________________________________________
Svnmerge mailing list
[hidden email]
http://www.orcaware.com/mailman/listinfo/svnmerge
Reply | Threaded
Open this post in threaded view
|

Re: Merge Issues

Blair Zajac
In reply to this post by Prakash P M S
On 5/11/11 1:35 AM, Prakash P M S wrote:

>
>  > From: [hidden email]
>  > Date: Tue, 10 May 2011 09:41:03 -0700
>  > To: [hidden email]
>  > CC: [hidden email]
>  > Subject: Re: [Svnmerge] Merge Issues
>  >
>  >
>  > On May 9, 2011, at 2:28 AM, Prakash P M S wrote:
>  >
>  > >
>  > >
>  > > > From: [hidden email]
>  > > > To: [hidden email]
>  > > > Date: Sun, 8 May 2011 23:36:26 -0700
>  > > > CC: [hidden email]
>  > > > Subject: Re: [Svnmerge] Merge Issues
>  > > >
>  > > >
>  > > > On May 8, 2011, at 11:08 PM, Prakash P M S wrote:
>  > > >
>  > > > > > From: [hidden email]
>  > > > > > To: [hidden email]
>  > > > > > Date: Fri, 6 May 2011 15:41:26 -0700
>  > > > > > CC: [hidden email]
>  > > > > > 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
_______________________________________________
Svnmerge mailing list
[hidden email]
http://www.orcaware.com/mailman/listinfo/svnmerge
Reply | Threaded
Open this post in threaded view
|

Re: Merge Issues

Prakash P M S
> Date: Wed, 11 May 2011 22:17:53 -0700

> From: [hidden email]
> To: [hidden email]
> CC: [hidden email]
> Subject: Re: [Svnmerge] Merge Issues
>
> On 5/11/11 1:35 AM, Prakash P M S wrote:
> >
> > > From: [hidden email]
> > > Date: Tue, 10 May 2011 09:41:03 -0700
> > > To: [hidden email]
> > > CC: [hidden email]
> > > Subject: Re: [Svnmerge] Merge Issues
> > >
> > >
> > > On May 9, 2011, at 2:28 AM, Prakash P M S wrote:
> > >
> > > >
> > > >
> > > > > From: [hidden email]
> > > > > To: [hidden email]
> > > > > Date: Sun, 8 May 2011 23:36:26 -0700
> > > > > CC: [hidden email]
> > > > > Subject: Re: [Svnmerge] Merge Issues
> > > > >
> > > > >
> > > > > On May 8, 2011, at 11:08 PM, Prakash P M S wrote:
> > > > >
> > > > > > > From: [hidden email]
> > > > > > > To: [hidden email]
> > > > > > > Date: Fri, 6 May 2011 15:41:26 -0700
> > > > > > > CC: [hidden email]
> > > > > > > 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

_______________________________________________
Svnmerge mailing list
[hidden email]
http://www.orcaware.com/mailman/listinfo/svnmerge
Reply | Threaded
Open this post in threaded view
|

Re: Merge Issues

Prakash P M S
In reply to this post by Raman Gupta
> Date: Wed, 11 May 2011 09:58:34 -0400

> From: [hidden email]
> To: [hidden email]
> CC: [hidden email]; [hidden email]
> Subject: Re: [Svnmerge] Merge Issues
>
>
> > 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.
>
> Prakash, while I understand and agree that svnmerge.py is not working
> optimally in this situation, I suspect that most of the committers
> have moved on to using built-in svn merging, and/or other tools that
> have better support for merging such as git -- I know I have.
> Development of svnmerge.py has thus basically stopped.
>
> Therefore, it is likely that if you want some changes to svnmerge.py
> you will have to make them yourself. Once you submit a patch, myself
> or one of the other committers will be more than happy to review your
> changes for inclusion. Make sure to include a useful unit test.
>

Initially we had the svnmerge provided by svn, but it had the overhead of renaming the source branch after merge is complete etc. For our usage, we cannot keep renaming the dev branch where development happens. I will have to see if the new version has better svnmerge capabilities. That is why we are still using svnmerge.py. Never had a chance to explore git as it involves migration to the new tool etc.

I have not looked at svnmerge.py and let me see if I can make the modification myself.

-- Thanks

_______________________________________________
Svnmerge mailing list
[hidden email]
http://www.orcaware.com/mailman/listinfo/svnmerge