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: > On Wed, Apr 20, 2011 at 03:43:06PM +1000, Gavin "Beau" Baumanis wrote: >> 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? > > 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.
