Return-Path: X-Original-To: apmail-subversion-users-archive@minotaur.apache.org Delivered-To: apmail-subversion-users-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id EB25BD116 for ; Fri, 9 Nov 2012 08:45:28 +0000 (UTC) Received: (qmail 66975 invoked by uid 500); 9 Nov 2012 08:45:28 -0000 Delivered-To: apmail-subversion-users-archive@subversion.apache.org Received: (qmail 66943 invoked by uid 500); 9 Nov 2012 08:45:27 -0000 Mailing-List: contact users-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list users@subversion.apache.org Received: (qmail 66886 invoked by uid 99); 9 Nov 2012 08:45:24 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 09 Nov 2012 08:45:24 +0000 X-ASF-Spam-Status: No, hits=1.7 required=5.0 tests=FREEMAIL_ENVFROM_END_DIGIT,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of kirenpillay1@gmail.com designates 74.125.82.171 as permitted sender) Received: from [74.125.82.171] (HELO mail-we0-f171.google.com) (74.125.82.171) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 09 Nov 2012 08:45:18 +0000 Received: by mail-we0-f171.google.com with SMTP id s43so2058212wey.16 for ; Fri, 09 Nov 2012 00:44:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=wdJ4+s2c47E/jNjQMqmoK+SfGnG1fgSsFEw/c2A2z1U=; b=0eqpToeBNFwOKagg3e+lZp4nwifmOW0mVwrWPGbPJ0c1usN2J67Zx94x2Tp/MeFQfc CwILjqDCc38r/w1Vbu+luyyCc5c2iRieYK/Ry2Mfvv2KyrBimQ/6YvyB4MAKufHV1u1u akpybxC0oOt0zQ83uzy9snU0SBgTv8ZwLp1b0GxLOs3JxevAzbO4LoyfuTpT+SgIA5au ejHXF7HIN0rf180T/DTfMOPNyM9sGxzyA30J4PYlQbgzXwssuWkophZpNhbEkFHE//2I Qe95SCqa0yiYTL44NnG/4g1qQolKhHqBT4NxjrRm1dgbYtyVdp9UOx8BohT0V/l8hzHS x9uA== MIME-Version: 1.0 Received: by 10.180.84.227 with SMTP id c3mr1327029wiz.18.1352450697911; Fri, 09 Nov 2012 00:44:57 -0800 (PST) Received: by 10.180.94.194 with HTTP; Fri, 9 Nov 2012 00:44:57 -0800 (PST) In-Reply-To: <20121108230234.GA30609@ted.stsp.name> References: <20121108230234.GA30609@ted.stsp.name> Date: Fri, 9 Nov 2012 10:44:57 +0200 Message-ID: Subject: Re: svn conflict, svn info message incorrect? From: Kiren Pillay To: Kiren Pillay , users@subversion.apache.org Content-Type: multipart/alternative; boundary=f46d044287666cdceb04ce0bf71d X-Virus-Checked: Checked by ClamAV on apache.org --f46d044287666cdceb04ce0bf71d Content-Type: text/plain; charset=ISO-8859-1 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 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. > --f46d044287666cdceb04ce0bf71d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Stefan,

You are correct, it was not a reintegrate merge, and it w= as from our QA branch back into trunk. What I found out was that my colleag= ue had already merged the code in that I was merging.=A0 So I assumed that = the mergeinfo would have hinted that this was already merged and no conflic= t 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 ou= r 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 c= ommits. (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@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 co= nflict.

What change did you notice? You're only showing one instance of o= utput.
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/vodac= om/pams/bs/subscriber/SubscriberProfileQueryServiceImpl.java
> Path:
> business_services/pams-bs-subscriber-account/src/main/java/za/co/vodac= om/pams/bs/subscriber/SubscriberProfileQueryServiceImpl.java
> Name: SubscriberProfileQueryServiceImpl.java
> Working Copy Root Path: /home/kiren/Documents/workspace-TRUNK/newServe= r
> URL: svn://bcx-svn/
> vodacom.za/pams/newS= erver/trunk/business_services/pams-bs-subscriber-account/src/main/java/za/c= o/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
> =A0 Source =A0left: (file)
> ^/pams/newServer/branches/v2-0-0-QA/business_services/pams-bs-subscrib= er-account/src/main/java/za/co/vodacom/pams/bs/subscriber/SubscriberProfile= QueryServiceImpl.java@10569
> =A0 Source right: (file)
> ^/pams/newServer/branches/v2-0-0-QA/business_services/pams-bs-subscrib= er-account/src/main/java/za/co/vodacom/pams/bs/subscriber/SubscriberProfile= QueryServiceImpl.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 "sou= rce").
They do not describe the two conflicting addition operations which led
to the tree conflict. You'll need to figure out the conflicting additio= n
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 forgett= ing
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.<= br>

--f46d044287666cdceb04ce0bf71d--