Re: Tree conflict detection in 'svn merge'

Quoting Julian Foad <julianfoad_at_btopenworld.com>:

> Stephen Butler wrote:
>> For use cases 4 & 6,
>> where the file has been deleted in the working copy's branch, there's
>> no victim in the working copy.
>
> Let's look at use case 4. Change 50 (Foo.c to Foo.c') is being merged
> onto urlB. In urlB, Foo.c has already been moved to Bar.c. In the
> working copy, the victim is Bar.c. Yes?
>
> I think this may be an example of what I wrote in the other email just
> now. Here, as yet I only understand the top-down view of the situation,
> in which there is a "victim" file, but you were writing from the point
> of view of one particular place in the implementation where the
> destination file 'Bar.c' is not known about.
>
> Is that the case?

We don't track renames in tree conflict detection. Our heuristics
involve only editing and deletion. For update, the victim file is the
working-copy file that has been locally edited or scheduled for
deletion. For merge, there's the extra twist that the victim might no
longer exist in the working copy's branch.

In the future we hope to have the benefit of explicit rename-tracking
in the repository ("true renames"). Then it would be straightforward
to implement those aspects of the use cases where the rename-destination
file is used. For example, automatically merging text changes from the
new version of the rename-source file.

See our tree conflict detection notes for an entertaining rant about
the lack of true rename support:

   /branches/tree-conflicts/notes/tree-conflicts/detection.txt

Browser link:

    
http://svn.collab.net/viewvc/svn/branches/tree-conflicts/notes/tree-conflicts/detection.txt?revision=28923&view=markup

>> Whoops, my comment was incorrect. The same_repos field is TRUE if the
>> source URLs (of the diff) and the target URL (of the working copy) are
>> in the same repo. Sorry for the confusion.
>>
>> Anyway, I think tree conflict detection is still valid only if
>> same_repos == TRUE. I.e., only the comment was wrong.
>
> Same sort of difficulty here.
>
> I think being able to correlate source items to target items is the
> fundamental criterion for whether we can detect conflicts.
>
> I agree that the source and target must be in the same repository
> (unless ancestry is being ignored), but only because we currently have
> no way to trace the ancestry across repositories. I don't see why this
> same_repos condition flag exists or should be considered independently
> from asking whether we can find a common ancestor.
>
> But this seems to be just an implementation detail, so not too
> important at this stage.

AFAIK, merge tracking is done only if the merge source and target are in
the same repository. See mergeinfo_behavior() in libsvn_client/merge.c.
So I took it as given that tree conflict detection should have the same
restriction.

Regards,
Steve

-- 
Stephen Butler | Software Developer
elego Software Solutions GmbH
Gustav-Meyer-Allee 25 | 13355 Berlin | Germany
fon: +49 30 2345 8696 | mobile: +49 163 25 45 015
fax: +49 30 2345 8695 | http://www.elegosoft.com
Geschäftsführer: Olaf Wagner | Sitz der Gesellschaft: Berlin
Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org