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.
Received on 2011-07-13 17:16:14 CEST