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

[Gavin "Beau" Baumanis]

Hi Everyone,

I am having some issues understanding tree conflicts.

I attempted the following;
svn merge -r1:head trunk/com/palcare/listsServices/ branches/production/com/palcare/listsServices/ --accept="theirs-full"

and got this;
Skipped 'branches/production/com/palcare/listsServices/ListsService.cfc'
--- Merging r15942 through r20669 into 'branches/production/com/palcare/listsServices':
C branches/production/com/palcare/listsServices/listsentries.cfc
C branches/production/com/palcare/listsServices/lists.cfc
C branches/production/com/palcare/listsServices/listsService.cfc
Skipped 'branches/production/com/palcare/listsServices/ListsService.cfc'
U branches/production/com/palcare/listsServices
Summary of conflicts:
Tree conflicts: 3
Skipped paths: 2

I have read the svn-book and;
Using everyone's good friend Mr google I found these;
http://stackoverflow.com/questions/738367/why-am-i-getting-tree-conflicts-in-subversion
http://blogs.collab.net/subversion/2009/03/subversion-160-and-tree-conflicts/

But I must be missing something...
They all seem to be about having local edits in a file that has subsequently been deleted in the repository - prior to me getting my edits committed.

I'm not sure how to transpose that into my case.
I have no local edit of the destination path/files.
They are up to date.(svn update)
(In fact I even went to far as to use the OS to delete the path and run svn update to restore them to the current version in the repo)

Ultimately I simply want my production branch to match exactly what is in the trunk for the specified path.

I "thought";
Surely accept="theirs-full" should be saying I don't care about my working copy's destination path - simply make it look like the source path?

I could simply replace with an os file copy and then commit the branch - but that just seems wrong.

Can anyone can shed some light on the matter for me, please?

Beau.

[Stefan Sperling]

Hi Gavin,

the --accept option only works for text and property conflicts at the
moment. There are plans to extend this to handle tree conflicts, too.
This depends on wc-ng though so we'll pick up this up again some time
after the 1.7.0 release.

Local changes in the working copy can cause tree conflicts during updates
and merges. But during merges, "local" edits are considered local to
the merge target _branch_ rather than just the working copy.
E.g. if you rename a file on a branch and commit this rename and then
merge an edit for the file at its old location from trunk you'll get a tree
conflict even though the "local" change (rename) has already been committed.

Also, the way you are invoking svn merge seems dubious.
You are doing a 2-URL merge across the entire revision range.
If you use merge-tracking you'd usually avoid 2-URL merges if at all
possible. The way you've run this merge may cause Subversion to apply
changes that were already merged between these branches again which can
lead to spurious conflicts.

You might want to take a look at the merge patterns described in the
new help text for svn merge (e.g. posted here:
http://svn.haxx.se/users/archive-2011-04/0209.shtml).
If you stick to those patterns chances are your merges will mostly
be conflict-free expect for obvious conflicts.

[Gavin "Beau" Baumanis]

Hi Stefan,

That is awesome thinks....
I have had a quick scan, but it is getting let here and I have been up since very early.
So I'll wait until tomorrow until trying to digest it all, properly.

I'll post back with what I have tried and what did / didn't work.

I really appreciate the assistance.

Beau.

[Gavin "Beau" Baumanis]

Hi Stefan,

I have finally managed t get some tie to devote to my lack of understanding of merge conflicts.

I have read the post you mentioned in your reply;

http://svn.haxx.se/users/archive-2011-04/0209.shtml

And I have also gone back and re-read the svn-book, too.

I can't say that it has helped me out any, really.

I don't have any idea as to what the technical explanation is about merging.

But I can certainly accept the advice to perform all merges at the root and to use the following syntax;

svn merge ^/trunk

I have to say - that since taking on this process, I have not  encountered the issue again - it has worked quite well for us.

But I find that I have managed to create a tree conflict again and need some help in resolving it.

There is a directory at;

/trunk/nz/shared that we are making redundant.

we have copied it to;

/trunk/shared

But unfortunately it needs to remain at /trunk/nz/shared in the short-term.

When constructing the branch, I deleted the /branches/myFeature/shared/ directory

and set up an external mapping with;

shared http://192.168.10.95/svn/repo/trunk/shared/

In the physical "real" /trunk/nz/shared/myFile - and edit was made.

The edit was replicated at /trunk/shared/myFile too.

and so now I get this when I try to do a merge....

I understand why I have a conflict....

I have an external that is a duplicate of a "real" location and there was an edit at the external path too.

so now I get;

--- Merging r21837 through r21844 into '.':

   C shared

U    patient/eDiagnostics.cfm

U    patient/meetdate.cfm

U    patient/qry_unreadDiagnosticsSELECT.cfm

U    patient/dsp_unreadDiagnosticsReviewList.cfm

Summary of conflicts:

  Tree conflicts: 1

While I am happy why I have the conflict;

How do I resolve it?

As always  - a big thanks for all your help.

Gavin.

On 20/04/2011, at 8:49 PM, Stefan Sperling wrote:

[Stefan Sperling]

On Thu, Jul 14, 2011 at 01:15:29AM +1000, Gavin "Beau" Baumanis wrote:
> and so now I get this when I try to do a merge....
> I understand why I have a conflict....
> I have an external that is a duplicate of a "real" location and there was an edit at the external path too.
>
> so now I get;
>
> --- Merging r21837 through r21844 into '.':
> C shared
> U patient/eDiagnostics.cfm
> U patient/meetdate.cfm
> U patient/qry_unreadDiagnosticsSELECT.cfm
> U patient/dsp_unreadDiagnosticsReviewList.cfm
> Summary of conflicts:
> Tree conflicts: 1
>
>
> While I am happy why I have the conflict;
> How do I resolve it?

There is no general rule you can apply to resolve any given tree conflict.
It depends on the situation and the desired merge result.

So let's start with getting more information about this conflict
so we can understand it better.

What do these commands print?

svn status shared
svn info shared

[Gavin "Beau" Baumanis]

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) http://192.168.10.95/svn/repo/trunk/nz/shared@2
Source right: (dir) http://192.168.10.95/svn/repo/trunk/nz/shared@21844

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

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.

Gavin,

[Stefan Sperling]

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) http://192.168.10.95/svn/repo/trunk/nz/shared@2
> Source right: (dir) http://192.168.10.95/svn/repo/trunk/nz/shared@21844

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.

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

[Gavin "Beau" Baumanis]

Hi again Stefan - and thanks for the help.

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
• shared

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

Gavin.