[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: "svn: Invalid tree conflict data"

From: Stefan Sperling <stsp_at_elego.de>
Date: Mon, 13 Oct 2008 14:51:41 +0100

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.


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

This is an archived mail posted to the Subversion Dev mailing list.