Re: "svn: Invalid tree conflict data"

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

>>
>> Stefan "volunteered" to look/think about it over Subconf, but documenting
>> here for the benefit of those who aren't passing their Sundays on
>> #svn-dev. :)
>
> There are two issues here.
>
> 1) We are creating tree conflict data in the entries
> file which we can't print human-readable descriptions
> for (hence the error you are seeing).
>
> This is most definitely a bug. We should check
> all places where we generate tree conflict info
> structs and make sure they can all be printed.
> I'll open an issue for this.
>
> 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?

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.

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.

If you disagree, how, exactly, would you define an add on top of an add?
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?

Still, fixing 1) above is compulsory...

~Neels

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