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