You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Stefan Sperling <st...@elego.de> on 2008/03/27 11:46:04 UTC
tree conflicts and obstructions
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.
But obstructed files are currently silently skipped during 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.
Opinions?
Julian has already expressed implicit consent in
http://subversion.tigris.org/servlets/ReadMsg?list=dev&&msgNo=136402 ,
but I want to make sure everyone agrees with us here.
We should update detection.txt accordingly, and possibly also
use-cases.txt.
--
Stefan Sperling <st...@elego.de> Software Developer
elego Software Solutions GmbH HRB 77719
Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96
13355 Berlin Fax: +49 30 23 45 86 95
http://www.elego.de Geschaeftsfuehrer: Olaf Wagner
Re: tree conflicts and obstructions
Posted by Julian Foad <ju...@btopenworld.com>.
Nico Schellingerhout wrote:
>
> Julian Foad <ju...@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?
Here, we're talking about when the addition of a file is obstructed by an
unversioned item of the same name that exists in the WC.
We could invent some plausible use cases:
(1) The user first obtained an unversioned copy of the file to try it out, and
then attempted the merge that involves adding this file, forgetting to remove
the unversioned file.
(2) The user tried the merge before and then reverted it, then tried the merge
again. If I recall correctly, Subversion's "revert" doesn't remove the local
copy of a file that was added with history. (I consider this to be wrong
behaviour, but that's the way it is at the moment.)
Similar use cases could involve an update or switch instead of merge.
- Julian
> > 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
--
http://www.foad.me.uk/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: tree conflicts and obstructions
Posted by Nico Schellingerhout <ni...@philips.com>.
Julian Foad <ju...@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
Re: tree conflicts and obstructions
Posted by Julian Foad <ju...@btopenworld.com>.
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!
Oops, that's bad! Definitely we should flag them as a tree conflict.
> 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.
> Opinions?
>
> Julian has already expressed implicit consent in
> http://subversion.tigris.org/servlets/ReadMsg?list=dev&&msgNo=136402 ,
> but I want to make sure everyone agrees with us here.
>
> We should update detection.txt accordingly, and possibly also
> use-cases.txt.
Yes. Some extra use cases for these cases would be good.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org