Stefan Sperling <stsp@elego.de> writes:
> For the use cases described it does not even punt, it just behaves
> misleadingly. So the current behaviour seems to conflict with the
> working copy library design goals.
>
> Usually it offers more detail than that, too. In addition to the
> overall out-of-whackness message, it can say "Directory foo was
> renamed to bar, conflicting with your new file bar; file blah was
> deleted, conflicting with your local change to file blah, ..." and so
> on. The important thing is that these are informational only -- they
> tell the user what's wrong, but they don't try to fix it
> automatically.
>
> Interesting, I've never seen svn explain conflicts to me this way.
> But this is very interesting because we need exactly that to
> report tree conflicts to the user in a comprehensible way.
>
> Is this an idea that has been sitting in the README all this
> time or is there actually code somewhere that implements this?
> I will search libsvn_wc later today, but I thought I might ask
> about it here as well because in case this hasn't been implemented
> it would interesting to know why.
I think this is an idea that's been sitting in README for a while but
was never actually implemented. My apologies -- the README should be
clearer about what's real and what's vapor!
Since you probably know better than anyone what's accurate and what's
not in README's discussion of tree conflicts, feel free to rewrite the
section according to what you've observed. We'd happily apply that
patch.
> (Also, I guess we will need to partially track renames on the
> server side as well for some use cases, but more on that later.
Yep, http://subversion.tigris.org/issues/show_bug.cgi?id=898
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Nov 1 20:23:03 2007