[prev in list] [next in list] [prev in thread] [next in thread] 

List:       subversion-dev
Subject:    Re: tree conflicts and obstructions
From:       Julian Foad <julianfoad () btopenworld ! com>
Date:       2008-03-28 12:35:28
Message-ID: 47ECE610.6030400 () btopenworld ! com
[Download RAW message or body]

Nico Schellingerhout wrote:
> 
> Julian Foad <julianfoad@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

[prev in list] [next in list] [prev in thread] [next in thread]