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) 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.
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.
Received on 2011-07-13 18:44:40 CEST