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 <stsp_at_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_at_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_at_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_at_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.
>
Received on 2012-11-09 09:45:36 CET