You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Kiren Pillay <ki...@gmail.com> on 2012/11/08 16:52:07 UTC
svn conflict, svn info message incorrect?
Hi
I've notices a change in the svn info output when I have a tree conflict.
The left and right are from the same branch. Is this correct? (svn 1.7
client to 1.6 server).
kiren@Pillay2:~/Documents/workspace-TRUNK/newServer$ svn info
business_services/pams-bs-subscriber-account/src/main/java/za/co/vodacom/pams/bs/subscriber/SubscriberProfileQueryServiceImpl.java
Path:
business_services/pams-bs-subscriber-account/src/main/java/za/co/vodacom/pams/bs/subscriber/SubscriberProfileQueryServiceImpl.java
Name: SubscriberProfileQueryServiceImpl.java
Working Copy Root Path: /home/kiren/Documents/workspace-TRUNK/newServer
URL: svn://bcx-svn/
vodacom.za/pams/newServer/trunk/business_services/pams-bs-subscriber-account/src/main/java/za/co/vodacom/pams/bs/subscriber/SubscriberProfileQueryServiceImpl.java
Repository Root: svn://bcx-svn/vodacom.za
Repository UUID: 5545304e-a938-48f1-8c5a-7cf7c6df13d1
Revision: 10708
Node Kind: file
Schedule: normal
Last Changed Author: aaronm
Last Changed Rev: 10610
Last Changed Date: 2012-10-29 09:11:10 +0200 (Mon, 29 Oct 2012)
Text Last Updated: 2012-11-07 16:18:50 +0200 (Wed, 07 Nov 2012)
Checksum: e26a87463a2fb2509c669d6cc1f7e584a50ce5a5
Tree conflict: local add, incoming add upon merge
Source left: (file)
^/pams/newServer/branches/v2-0-0-QA/business_services/pams-bs-subscriber-account/src/main/java/za/co/vodacom/pams/bs/subscriber/SubscriberProfileQueryServiceImpl.java@10569
Source right: (file)
^/pams/newServer/branches/v2-0-0-QA/business_services/pams-bs-subscriber-account/src/main/java/za/co/vodacom/pams/bs/subscriber/SubscriberProfileQueryServiceImpl.java@10701
Regards
Kiren
Re: svn conflict, svn info message incorrect?
Posted by Kiren Pillay <ki...@gmail.com>.
Hi Stefan,
Thanks for the help!
Regards
Kiren
On Fri, Nov 9, 2012 at 2:40 PM, Stefan Sperling <st...@elego.de> wrote:
> On Fri, Nov 09, 2012 at 10:44:57AM +0200, Kiren Pillay wrote:
> > "--reintegrate" merge has worked like a charm for us so far, however the
> > reason I didn't do a reintegrate merge was that this was our QA branch,
> so
> > if I reintegrated, I would have to delete the QA branch and recreate it,
> > since after the merge the QA branch would not allow further commits. (I
> > guess this would be safe to do if my merge was done correctly).
>
> This is a slight misconception. You don't *have* to delete a branch
> after reintegrating it. The --reintegrate option controls Subversion's
> merge behaviour in a way that avoids spurious conflicts due to changes
> that were already merged from the reintegrate source (e.g. a branch)
> to the reintegrate target (e.g. trunk). Once the reintegrate merge is
> done and committed it looks just like any other merge.
>
> > What do you suggest is the best approach for this from your experience?
>
> There is this workaround to avoid deleting the branch, which is documented
> in the Subversion book:
>
> http://svnbook.red-bean.com/en/1.7/svn.branchmerge.advanced.html#svn.branchmerge.advanced.reintegratetwice
> I would still recommend using this approach for the time being.
>
> However, in Subversion 1.8, the --reintegrate option is going away so you
> will be able to just run 'svn merge' to merge in either direction.
> See here for detail:
> http://subversion.apache.org/docs/release-notes/1.8.html#auto-mergeo
> And here for more (probably too much) detail:
> http://wiki.apache.org/subversion/SymmetricMerge
> (There is no fixed release date for 1.8 yet, in case you're wondering.
> Nobody knows yet, thanks for asking :)
>
Re: svn conflict, svn info message incorrect?
Posted by Stefan Sperling <st...@elego.de>.
On Fri, Nov 09, 2012 at 10:44:57AM +0200, Kiren Pillay wrote:
> "--reintegrate" merge has worked like a charm for us so far, however the
> reason I didn't do a reintegrate merge was that this was our QA branch, so
> if I reintegrated, I would have to delete the QA branch and recreate it,
> since after the merge the QA branch would not allow further commits. (I
> guess this would be safe to do if my merge was done correctly).
This is a slight misconception. You don't *have* to delete a branch
after reintegrating it. The --reintegrate option controls Subversion's
merge behaviour in a way that avoids spurious conflicts due to changes
that were already merged from the reintegrate source (e.g. a branch)
to the reintegrate target (e.g. trunk). Once the reintegrate merge is
done and committed it looks just like any other merge.
> What do you suggest is the best approach for this from your experience?
There is this workaround to avoid deleting the branch, which is documented
in the Subversion book:
http://svnbook.red-bean.com/en/1.7/svn.branchmerge.advanced.html#svn.branchmerge.advanced.reintegratetwice
I would still recommend using this approach for the time being.
However, in Subversion 1.8, the --reintegrate option is going away so you
will be able to just run 'svn merge' to merge in either direction.
See here for detail:
http://subversion.apache.org/docs/release-notes/1.8.html#auto-mergeo
And here for more (probably too much) detail:
http://wiki.apache.org/subversion/SymmetricMerge
(There is no fixed release date for 1.8 yet, in case you're wondering.
Nobody knows yet, thanks for asking :)
Re: svn conflict, svn info message incorrect?
Posted by Kiren Pillay <ki...@gmail.com>.
Hi Stefan,
You are correct, it was not a reintegrate merge, and it was from our QA
branch back into trunk. What I found out was that my colleague had already
merged the code in that I was merging. So I assumed that the mergeinfo
would have hinted that this was already merged and no conflict would occur.
"--reintegrate" merge has worked like a charm for us so far, however the
reason I didn't do a reintegrate merge was that this was our QA branch, so
if I reintegrated, I would have to delete the QA branch and recreate it,
since after the merge the QA branch would not allow further commits. (I
guess this would be safe to do if my merge was done correctly).
What do you suggest is the best approach for this from your experience?
Regards
Kiren
On Fri, Nov 9, 2012 at 1:02 AM, Stefan Sperling <st...@elego.de> wrote:
> On Thu, Nov 08, 2012 at 05:52:07PM +0200, Kiren Pillay wrote:
> > Hi
> >
> > I've notices a change in the svn info output when I have a tree conflict.
>
> What change did you notice? You're only showing one instance of output.
> What has changed? And which releases of Subversion are you comparing?
>
> > The left and right are from the same branch. Is this correct? (svn 1.7
> > client to 1.6 server).
> >
> > kiren@Pillay2:~/Documents/workspace-TRUNK/newServer$ svn info
> >
> business_services/pams-bs-subscriber-account/src/main/java/za/co/vodacom/pams/bs/subscriber/SubscriberProfileQueryServiceImpl.java
> > Path:
> >
> business_services/pams-bs-subscriber-account/src/main/java/za/co/vodacom/pams/bs/subscriber/SubscriberProfileQueryServiceImpl.java
> > Name: SubscriberProfileQueryServiceImpl.java
> > Working Copy Root Path: /home/kiren/Documents/workspace-TRUNK/newServer
> > URL: svn://bcx-svn/
> >
> vodacom.za/pams/newServer/trunk/business_services/pams-bs-subscriber-account/src/main/java/za/co/vodacom/pams/bs/subscriber/SubscriberProfileQueryServiceImpl.java
> > Repository Root: svn://bcx-svn/vodacom.za
> > Repository UUID: 5545304e-a938-48f1-8c5a-7cf7c6df13d1
> > Revision: 10708
> > Node Kind: file
> > Schedule: normal
> > Last Changed Author: aaronm
> > Last Changed Rev: 10610
> > Last Changed Date: 2012-10-29 09:11:10 +0200 (Mon, 29 Oct 2012)
> > Text Last Updated: 2012-11-07 16:18:50 +0200 (Wed, 07 Nov 2012)
> > Checksum: e26a87463a2fb2509c669d6cc1f7e584a50ce5a5
> > Tree conflict: local add, incoming add upon merge
> > Source left: (file)
> >
> ^/pams/newServer/branches/v2-0-0-QA/business_services/pams-bs-subscriber-account/src/main/java/za/co/vodacom/pams/bs/subscriber/SubscriberProfileQueryServiceImpl.java@10569
> > Source right: (file)
> >
> ^/pams/newServer/branches/v2-0-0-QA/business_services/pams-bs-subscriber-account/src/main/java/za/co/vodacom/pams/bs/subscriber/SubscriberProfileQueryServiceImpl.java@10701
> >
> >
> > Regards
> > Kiren
>
> I think this is how it is supposed to be.
> These fields describe the "merge left" and "merge right" sides of the
> incoming delta which produced the incoming addition (in the merge
> "source").
> They do not describe the two conflicting addition operations which led
> to the tree conflict. You'll need to figure out the conflicting addition
> on the merge target branch by looking at the log of the merge target
> branch.
> Does that make sense?
>
> Did you use the --reintegrate option to run the merge which produced this
> conflict? It seems you're merging a branch back into trunk, and forgetting
> to pass the --reintegrate option is a common cause of unnecessary tree
> conflicts during such merges. Just mentioning this in case you forgot
> about using the ---reintegrate option.
>
> By the way, I agree that Subversion should in general do a better job at
> explaining the root cause of tree conflicts. It should also guide users
> through conflict resolution interactively to make these conflicts easier
> to resolve. Subversion would benefit a lot from improvements in this area.
>
Re: svn conflict, svn info message incorrect?
Posted by Stefan Sperling <st...@elego.de>.
On Thu, Nov 08, 2012 at 05:52:07PM +0200, Kiren Pillay wrote:
> Hi
>
> I've notices a change in the svn info output when I have a tree conflict.
What change did you notice? You're only showing one instance of output.
What has changed? And which releases of Subversion are you comparing?
> The left and right are from the same branch. Is this correct? (svn 1.7
> client to 1.6 server).
>
> kiren@Pillay2:~/Documents/workspace-TRUNK/newServer$ svn info
> business_services/pams-bs-subscriber-account/src/main/java/za/co/vodacom/pams/bs/subscriber/SubscriberProfileQueryServiceImpl.java
> Path:
> business_services/pams-bs-subscriber-account/src/main/java/za/co/vodacom/pams/bs/subscriber/SubscriberProfileQueryServiceImpl.java
> Name: SubscriberProfileQueryServiceImpl.java
> Working Copy Root Path: /home/kiren/Documents/workspace-TRUNK/newServer
> URL: svn://bcx-svn/
> vodacom.za/pams/newServer/trunk/business_services/pams-bs-subscriber-account/src/main/java/za/co/vodacom/pams/bs/subscriber/SubscriberProfileQueryServiceImpl.java
> Repository Root: svn://bcx-svn/vodacom.za
> Repository UUID: 5545304e-a938-48f1-8c5a-7cf7c6df13d1
> Revision: 10708
> Node Kind: file
> Schedule: normal
> Last Changed Author: aaronm
> Last Changed Rev: 10610
> Last Changed Date: 2012-10-29 09:11:10 +0200 (Mon, 29 Oct 2012)
> Text Last Updated: 2012-11-07 16:18:50 +0200 (Wed, 07 Nov 2012)
> Checksum: e26a87463a2fb2509c669d6cc1f7e584a50ce5a5
> Tree conflict: local add, incoming add upon merge
> Source left: (file)
> ^/pams/newServer/branches/v2-0-0-QA/business_services/pams-bs-subscriber-account/src/main/java/za/co/vodacom/pams/bs/subscriber/SubscriberProfileQueryServiceImpl.java@10569
> Source right: (file)
> ^/pams/newServer/branches/v2-0-0-QA/business_services/pams-bs-subscriber-account/src/main/java/za/co/vodacom/pams/bs/subscriber/SubscriberProfileQueryServiceImpl.java@10701
>
>
> Regards
> Kiren
I think this is how it is supposed to be.
These fields describe the "merge left" and "merge right" sides of the
incoming delta which produced the incoming addition (in the merge "source").
They do not describe the two conflicting addition operations which led
to the tree conflict. You'll need to figure out the conflicting addition
on the merge target branch by looking at the log of the merge target branch.
Does that make sense?
Did you use the --reintegrate option to run the merge which produced this
conflict? It seems you're merging a branch back into trunk, and forgetting
to pass the --reintegrate option is a common cause of unnecessary tree
conflicts during such merges. Just mentioning this in case you forgot
about using the ---reintegrate option.
By the way, I agree that Subversion should in general do a better job at
explaining the root cause of tree conflicts. It should also guide users
through conflict resolution interactively to make these conflicts easier
to resolve. Subversion would benefit a lot from improvements in this area.