Re: "svn: Invalid tree conflict data"

Daniel Shahaf wrote:
> Neels J. Hofmeyr wrote on Wed, 15 Oct 2008 at 16:36 +0200:
>> Stefan Sperling wrote:

[...] (asking why a tree-conflict is raised when the exact same changes are
made.)

> 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")

Actually, I agree with that. I simply sort of had accepted that a delete on
top of the same delete is a conflict, simply because it was part of the use
cases presented to me for fixing tree conflicts...

It never really made sense to me, though, so I'm glad this discussion is
(finally) coming up. Julian, Stefan, Steve, Nico, what can you guys tell us
about this? (Also see Daniel's detailed descriptions below.)

~Neels

>
> 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
>

-- 
Neels Hofmeyr -- elego Software Solutions GmbH
Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
phone: +49 30 23458696  mobile: +49 177 2345869  fax: +49 30 23458695
http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin
Handelsreg: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194