On Wed, Jul 23, 2008 at 10:15:11AM +0100, Julian Foad wrote:
> Hi, tree-conflicts fans, and Stephen in particular.
>
> I'm pleased to see this recent update to
> notes/tree-conflicts/detection.txt.
>
> I'm a bit confused about what is being documented here: the intention or
> the current implementation?
Oh, you're right, we mixed that up a bit.
Everything we've added documents our intentions.
> > This file describes how tree conflicts described in use-cases.txt
> > can be detected. It documents how detection currently works in the
> > actual code, and also explains the limits of tree conflict detection
> > imposed by Subversion's current design.
>
> But many of the subsequent parts are written like a statement of intent.
Yes, you're right. We should adjust the first paragraph for the time
being.
> > +The current implementation has imperfect tree conflict detection,
> > +but it is still better than not handling tree conflicts at all.
> > +Once Subversion has been taught about true renames, tree conflict
> > +detection can be changed to make use of this and become extremely
> > +precise. See below for further explanation.
>
> Yes. But also, there is a lot more that we can do without true renames.
I would not mind removing that paragraph altogether. It's not that
informative, and you're right that it might be worded a bit too broadly.
> > ==========
> > 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?
This paragraph definitely needs fixing either way, it is not
precise enough to serve as a spec to work from.
> > ==========
> > USE CASE 2
> > ==========
> >
> > +Files:
> > +
> > If 'svn update' deletes a file that has local modifications, the file
> > is a tree conflict victim.
> >
> > +Directories:
> > +
> > +If 'svn update' deletes a directory that has local modifications
> > +(including items scheduled to be added or deleted), each locally
> > +modified item is a tree conflict victim. The conflict data will be
> > +stored in the metadata of the parent of the directory deleted by the
> > +update.
>
> Same again.
ACK.
> > ==========
> > 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 ;)
> > ==========
> > 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.
> > +=======================================
> > +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.
Steve mentioned to me that the example still had errors he was
going to fix. I will refrain from commenting until his fixes
are in.
Thanks for your feedback, Julian!
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-07-23 13:23:08 CEST