Neels J. Hofmeyr wrote on Wed, 15 Oct 2008 at 16:36 +0200:
> Stefan Sperling wrote:
> > On Mon, Oct 13, 2008 at 12:37:22AM +0200, Daniel Shahaf wrote:
> >> I'm getting the above error when I make the same wc-to-wc copy in two
> >> wc's, commit in one of them, and update the other. A reproduction script
> >> for Unix is attached[1]. Its output is pasted at [2].
> >>
> >> I think this situation shouldn't raise a tree conflict in the first place
> >> (at most, it should be a text conflict), since the same tree modification
> >> (copy 'iota' to 'iota2', which hadn't existed before) was done in the wc
> >> and in the incoming change.
>
> I beg to differ, see below...
>
...
> > 2) We need to decide whether we want to flag a tree
> > conflict when an add-with-history hits a target
> > that's already present in the WC, and which has
> > the same copy-from info (i.e. same rev and path).
>
> If an addition of a node hits a node that is already there, it has to
> be a tree-conflict, reason obstructed, right? So you are suggesting
> that *if* one finds that the obstructing file is somehow added in just
> the same way as the incoming file, we should instead *not* mark a tree
> conflict?
>
Yes. In general, regardless of the nature of a change, if I make it
(the *same* change) in two wc's, why should it ever raise a conflict?
(For a sufficiently strict interpretation of "same")
For text mods, we do this already:
### case #1
% echo foo >> wc1/iota
% svn ci wc1
% echo foo >> wc2/iota
% svn up wc2
G wc2/iota
% svn st wc2
%
Compare the behaviour for renames:
### case #2
% svn cp wc1/iota wc1/iota2
% svn ci wc1
% svn cp wc2/iota wc2/iota2
% svn up wc2
E iota2
C .
% svn st wc2
C .
+ C iota2
%
*What* exactly is the conflict here? What are you trying to save me from?
That's for *identical* changes. If the texts aren't the same (but the
tree change is the same; i.e., same copyfrom path and pegrev), I'd
expect to be asked to resolve only the textual differences -- not the
tree mods -- since there is no disagreement about the latter ones.
> That would also sort of collide with the case of a delete coming down onto a
> delete (nevermind the contents or props), which *is* a tree-conflict. This
> is an add on top of an add, nevermind the contents or props.
>
Yes, it's an add on top of an add. So we agree about the tree mod that
should be done. And again only the possible textual differences need to
be addressed. (independently of how it's called)
> IMHO all of the cases discussed here should be tree-conflicts. Or, if an add
> on top of an add is not a tree-conflict, then a delete on top of a delete
> can't be, either.
>
Does this conflict ---
% svn rm wc1/iota; svn ci
% svn rm wc2/iota; svn up
? If so, why? How do the two changes disagree?
> If you disagree, how, exactly, would you define an add on top of an add?
Having the same copyfrom path and rev sounds a sane criterion and was
suggested before.
> Must the added file have been added in the most recent revision? Isn't this
> rather complicated and rare? Wouldn't it be better to prompt the user?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-10-15 19:42:48 CEST