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.
