On Tue, 2008-09-09 at 02:03 +0200, Neels Hofmeyr wrote:
>
> Julian Foad wrote:
> > Yes, we decided that we should handle "obstructions" (all cases where
> > the disk is inconsistent with the metadata, including where the disk
> > file or directory is missing), as an error condition, first, and after
> > that proceed to checking for tree conflicts once we know that the WC
> > state is sane in itself.
>
> So, a local file edit is *not* an obstruction (something done without
> explicitly telling svn about it), but removing a directory *is* an
> obstruction (unless svn is explicitly told about it). Right?
Correct.
> Intuitively, I assumed that just removing a directory (`rm -rf D1`, not
> using svn) also counts sort of as a valid local edit...
No. You have to use Subversion commands for all tree changes (making and
deleting files and directories). The only kind of change that you don't
have to tell it about is changing a file's content.
- Julian
>
> >
> >>> Index: subversion/libsvn_wc/update_editor.c
> >>> ===================================================================
> >>> --- subversion/libsvn_wc/update_editor.c (revision 32658)
> >>> +++ subversion/libsvn_wc/update_editor.c (working copy)
> >>> @@ -1198,31 +1198,47 @@
> >>> else
> >>> {
> >>> svn_boolean_t modified;
> >>> + svn_node_kind_t kind;
> >>>
> >>> - /* If we are about to delete a path that has local mods,
> >>> + /* If we are about to delete a path that is locally missing,
> >>> * mark the containing directory as tree conflicted.
> >>> - * This is tree conflict use case 2 as described in the
> >>> - * paper attached to issue #2282
> >>> + * This is tree conflict use case 3.
> >>> * See also notes/tree-conflicts/detection.txt
> >> detection.txt says:
> >>
> >> If 'svn update' deletes a file that has been scheduled for deletion in
> >> the working copy, the file is a tree conflict victim
> >>
> >> But the file has not been scheduled for deletion in this case.
> >>
> >> I'd suggest simply stating:
> >>
> >> /* If we are about to delete a path that is missing from disk
> >> * but present in meta data, raise a tree conflict.
> >> * The merge cannot succeed because the working copy is broken.
> >> */
> >>
> >> Essentially, this is the inverse of our 'obstructed' tree conflict
> >> cases, which happen when a path is present on disk which meta data
> >> says should not be there (yet).
> >
> > We ought to tweak that comment.
>
> Yes, looks good.
>
> ~Neels
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-09-09 12:13:46 CEST