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.
Received on 2011-04-20 12:49:45 CEST