Julian Foad <julianfoad_at_btopenworld.com> wrote on 03/27/2008 11:25:48 PM:
> Stefan Sperling wrote:
> > Hello Steve, Julian, Nico, and others interested,
> >
> > One of the failing tests on the tree-conflicts branch shows that
> > we have a gap in the design.
> >
> > Namely, we have not yet defined how svn should behave if a file
> > is obstructed by an unversioned item of the same name during
> > update/switch and merge.
> >
> > See http://subversion.tigris.org/issues/show_bug.cgi?id=3139
> >
> > Currently, during update and switch obstructions cause the operation
> > to fail:
> > svn: Failed to add file 'b': object of the same name already exists
> >
> > I think this behaviour suits us fairly well already.
>
> I think that behaviour satisfies the goal of the current tree-conflicts
work
> (to ensure conflicts are noticed), but it would be more useful and more
> consistent if it would now raise a tree conflict and carry on rather
than
> bailing out with an error.
>
> > But obstructed files are currently silently skipped during merge!
I don't know what obstructed files are: are these (versioned?) files
that are in the place of a file that has been scheduled for deletion?
What use cases lead to such obstructions?
>
> Oops, that's bad! Definitely we should flag them as a tree conflict.
I agree: there should be sufficient warning whenever the WC is
about to wind up in a state that would constitute an "incomplete"
or "inconsistent" merge.
>
> > I suppose we should flag obstructed files as tree conflict
> > victims during merge, except when their name appears in the
> > svn:ignore property on the containing directory.
>
> And what would you suggest we do if they're "ignored"? I would
> suggest we still
> flag this as a tree conflict.
>
Agreed: the ignored status should not allow the WC to wind up in
a different state than "expected" without warning.
- Nico
Received on 2008-03-28 07:54:15 CET