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?
Received on 2011-07-13 18:04:52 CEST