Re: Tree conflicts detection.txt

Quoting Stefan Sperling <stsp_at_elego.de>:

> On Wed, Jul 23, 2008 at 10:15:11AM +0100, Julian Foad wrote:

[...]

>> > ==========
>> > USE CASE 1
>> > ==========
>> >
>> > +Files:
>> > +
>> > If 'svn update' modifies a file that has been scheduled for deletion
>> > in the working copy, the file is a tree conflict victim.
>> >
>> > +Directories:
>> > +
>> > +If 'svn update' modifies any item (including adding or deleting a file
>> > +or directory) in a directory that has been scheduled for deletion in
>> > +the working copy, each item modified by the update is a tree conflict
>> > +victim. The conflict data will be stored in the metadata of the parent
>> > +of the directory scheduled for deletion.
>>
>> That would put the metadata two (or more?) levels away from the victims,
>> which isn't a possibility I had imagined or seen mentioned.
>>
>> The way I see it is that there is only one victim, and that is the
>> directory scheduled for deletion. As soon as the "update" tries to
>> "open" a schedule-delete directory in order to make changes in it, a
>> conflict should be raised with this directory as the victim (and
>> metadata stored in its parent), and no further processing of the changes
>> within this directory should be attempted. If the user then wants to get
>> at those changes, he would look up the incoming revisions in the
>> conflict description, and get those changes directly from the
>> repository.
>
> Hmmm. I'm not sure if what we meant to say is exactly what you describe.
> I don't think we were really going to separately store the victim status
> of each item in the subtree being deleted, at least I can't remember a
> good reason for doing so. Steve, do you remember why we wrote this the
> way we did?

Interrupting the update, as Julian suggests, would be simpler.
There would be less for the user to read. Sometimes less info
is better! In my example of a deep tree conflict, there are five
conflict description like this one:

   The update attempted to edit 'A/B/E/alpha'.
   You have deleted or renamed 'A/B' locally.

By interrupting the update, these are reduced to one description:

   The update wants to modify something inside 'A/B'.
   You have deleted or renamed 'A/B' locally.

Also, the interruption avoids awkward aspects of the current 1.5
behavior. For instance, the inconsistent 'svn status' output for
items added by update in a tree scheduled for deletion.

So far, we've avoided interrupting the update, because update is
a one-way operation. In general, a working copy contains mixed
revisions, so the update operation is applied to each item
individually. There's no holistic diff-and-apply. If an update
is interrupted, there's no revert command to restore the working
copy to what it was before. An interruption would leave the
working copy in a state where the revisions are even more
mixed-up than usual.

But maybe that argument is outweighed by the simplicity argument.

[...]

>> > ==========
>> > USE CASE 4
>> > ==========
>> >
>> > We skip tree conflict detection if the record_only field of the
>> > merge-command baton is TRUE. A record-only merge operation updates
>> > mergeinfo without touching files.
>> >
>> > +Files:
>> > +
>> > If 'svn merge' tries to modify a file that does not exist in the
>> > target working copy, then the target file is a tree conflict victim.
>>
>> [...]
>>
>> > +Directories:
>> > +
>> > +If 'svn merge' tries to modify a directory that does not exist in the
>> > +target working copy, then the target directory is a tree conflict victim.
>>
>> Yes. (Why would you want to treat case 1 differently from this case 4?)
>
> Merge behaves differently than update when faced with deleted
> directories. I keep forgetting the details about this, even
> though Steve has explained them to me a couple of times already.
>
> Steve, has this got to do with the difference between update and
> merge when deleting? Can you explain the details again? We should
> probably add such a detailed description to the file itself so I
> don't keep forgetting them ;)

The difference is that in use case 1, the directory tree is in the
working copy (scheduled for deletion, but still there), while in
use case 4 the directory tree is simply not there.

>
>> > ==========
>> > USE CASE 5
>> > ==========
>> >
>> > We skip tree conflict detection if the record_only field of the
>> > merge-command baton is TRUE. A record-only merge operation updates
>> > mergeinfo without touching files.
>>
>> You didn't recently change that text, but I don't really understand the
>> first sentence. What's the high-level meaning? Is there a special reason
>> why it appears here under use case 5 but nowhere else?
>
> AFAIK the high-level meaning is that a --record-only merge is being done.

Yes. The three copies of this text in the document ought to be demoted
to a footnote.

>
>> > +=======================================
>> > +Deep tree conflict example (use case 1)
>> > +=======================================
>
>> > +* The newly-added G and gamma are not scheduled for deletion, but will
>> > + be deleted if the user commits the deletion of B.
>>
>> Don't you think that either they should be scheduled for deletion and
>> then deleted by a commit, or not scheduled for deletion and not deleted
>> by a commit?
>
>> > +* Any commit of A (including any commit in a parent directory or
>> > + subdirectory of A) will be blocked by the tree conflicts.
>>
>> But a commit of B won't be blocked? That's not good. An attempt to
>> commit anything inside A should be blocked too, in my opinion.

By "subdirectory of A", I meant A/B, A/B/E, etc. I'll rewrite that
sentence to make that more obvious.

Thanks for all the feedback!

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