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.
Received on 2011-04-20 13:55:41 CEST