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.
>
> 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).
I'd argue to flag a tree conflict whenever the
copyfrom info does not match and path AND rev.
When path and rev do match, then we can treat it
as a text conflict, that's fine. But I don't know
whether users will really find this more consistent
in practice. I guess which is better really depends
on how large the text conflict will be -- e.g. if you
got two files that didn't match at all, then it would
probably be more convenient to flag a tree conflict.
OTOH, if the files were very similar, a text conflict
would be more appropriate.
It's not easy to draw a line here.
Stefan
---------------------------------------------------------------------
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-13 15:52:39 CEST