[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Tree Conflicts after merging a directory with --accept="theirs-full"

From: Gavin \ <gavin.baumanis_at_palcare.com.au>
Date: Thu, 14 Jul 2011 02:43:51 +1000

Hi again Stefan - and thanks for the help.

On 14/07/2011, at 2:04 AM, Stefan Sperling wrote:

> On Thu, Jul 14, 2011 at 01:43:11AM +1000, Gavin "Beau" Baumanis wrote:
>> Hi Stefan,
>> Here is the information you requested;
>> svn status shared;
>> C shared
>>> local delete, incoming edit upon merge
>> svn info shared;
>> Tree conflict: local delete, incoming edit upon merge
>> Source left: (dir)
>> Source right: (dir)
> So the source-right tells us that the incoming edit was originally
> made within trunk/nz/shared. The merge wants to apply this edit to
> trunk/nz/shared, but finds it missing from your working copy.
> This matches your original explanation of why you got the conflict.
>> As for the result,
>> I'd like my local copy to discard the change made at /trunk/nz/shared
>> since the exact same difference is present at; /trunk/shared
> That should be easy. You already have the desired state in your
> working copy:
> - you are happy with what is at /trunk/shared
> - you are happy with the incoming edit to /trunk/nz/shared being discarded
> Hence, just run 'svn resolve --acccept working nz/shared'.
> This will remove the conflict marker and allow you to commit the
> working state you've got.

I actually have some notes here - (from my googling / reading the SVN book) that stated that was the command to use to resolve the conflict.
And the command is straight forward in that accept working is indeed what I wanted... (accept the working copy to the be true representation of the WC state.)
My issue was - a misunderstadning, I suppose about the conflict marker.

I have read the book a few times and it might certainly be there - but it isn't in my memory - as to whether or not the merge operation has in fact been completed and marked as being in conflict
or the merge failed, so nothing has actually been done (at the marker) - and so the working copy is "intact" - and "marked" as being in conflict.

So I wasn't totally convinced that simply accepting my working copy version would actually give me the results I wanted to see in the the WC.

> Because merge-tracking has recorded the edit to /trunk/nz/shared as
> having been merged Subversion will not try to ever merge it again.
> So you should not see this same conflict on subsequent merges.
>> Upon reflection it seems like a pretty silly idea to be had from the start...
>> Replicate a hard path with an external from another path - and somehow expect it to behave correctly.
>> But since I used the following;
>> cd /trunk/nz
>> svn up --set-depth exclude shared
>> so as to ignore the /trunk/nz/shared directory intitally - it seemed ok to proceed with the external at the same location.
> Tree-conflict detection is not that smart.
> It only sees that an incoming change wants to modify something
> within /trunk/nz/shared, and that this directory does not exist in
> your working copy for some reason. The best guess is that you've deleted
> /trunk/nz/shared in the history of your branch so an "incoming edit vs.
> local delete" conflict is flagged.
> If the real reason this directory is missing from your working copy is
> that you used update --set-depth exclude, you should instead delete nz/shared
> before committing the external definition. Otherwise new checkouts will

I did indeed do this;

@21536 : branches/nzmed (copied from trunk/nz)
@21724 : 1 removed branches/nzmed/shared

and then to stop from reappearing in future merges from trunk I used set depth exclude on the shared directory.

then, setup the external definition.
@21751 : branches/nzmed Property svn:externals set to
So - as a result of doing it (delete and the exclude) previously, I "thought" what SVN "saw" in my branch was;
There is no such directory as /branches/myFeature/shared at all.
Ignore THAT directory and anything that tries to update / add / remove anything from / into that path.

And then the external - while at the same path "in name" I assumed was simply a SVN symlink.

> run into a problem -- they will have a versioned directory and an external
> at the same location (the depth setting is local to your working copy).
> If you run Linux or a similar system, have you considered using a symlink
> instead of an external?

As above, thats what I assumed that the external was... a svn symlink.
The reasoning behind the external, was - while I have no intention of altering code in the trunk/shared location,
Because my eclipse workspace is set up for /branches/myFeatiure - if I did need to do something in the shared directory - I could still do it within my eclipse workspace and have that change reflected back to the authoritative /trunk/shared location.

Having re-read the emails in the latest part of this thread.... seems like I did an awful lot of "assuming"...

As always - thanks for the help Stefan. I am certainly wiser for the discussion / assistance....

Received on 2011-07-13 18:44:40 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.