On Tue, Jan 13, 2009 at 03:24:21PM -0500, Mark Phippard wrote:
> On Tue, Jan 13, 2009 at 3:14 PM, Stefan Sperling <stsp_at_elego.de> wrote:
> > Copy improvements...
> >
> > a) ... are known to only work when an update carries out operations
> > in a certain order. More precisely, if the update happens to carry
> > out the deletion of the file before the corresponding add,
> > local changes are *not* moved over to the new location.
> > Users have reported that they see no effect from the improvements made,
> > see comment by Yann FOUBERT in issue #503
> > http://subversion.tigris.org/issues/show_bug.cgi?id=503
> > Effectively the feature is non-deterministic from the user's
> > point of view.
>
> When I am testing tree conflict scenarios, I seem to see this feature
> in action a lot more than I thought I used to. Is it possible that
> since the old behavior would "unversion" the file and we now preserve
> it as a tree conflict that this actually is working more often now?
Yes, quite likely. I noticed that, too.
> > b) ... are a bit redundant now that we flag this situation as
> > a tree conflict anyway. Then again, they save users from
> > manually moving local changes over to a moved file.
>
> While I am not against removing the feature for 1.6, I am not sure I'd
> say it is redundant. If it was, we would not have this on the
> wishlist for a "ultimate" tree conflicts solution.
Yes. What I meant was that the problem of local modifications being
"lost" in an unversioned file is addressed by both tree conflicts and
copy improvements, hence "a bit redundant". The features solve the
problem in entirely diffferent ways though. They might turn out to
complement each other quite nicely if only this nasty bug we're blocking
on was fixed.
> > c) ... are planned to be re-worked in a reliably way eventually
> > as part of the tree-conflicts effort. But note that this is a
> > plan, or rather, and idea. There are no concrete design proposals
> > yet. We may want to consider this vapour-ware for now, rather
> > than a serious alternative to the current copy improvements
> > implementation.
> >
> > Copy improvements involved many public API modifications, and
> > RA protocol modifications (mostly adding "copyfrom args").
> > These would need to stay until 2.0 at least, but operations
> > involving this API could probably be turned into no-ops.
> > Depending on how 2c) will eventually look like, we might end
> > up reusing this API or parts of it.
>
> Was there actually any new API created specifically for this? I am
> not sure adding copyfrom args really qualifies. I see that as more
> "enabling" the feature than defining it. There is no reason that
> information could have not always existed in the API before this
> change. In fact, ISTR there was some API where it was already present
> and others where it was not. I guess my point is that if we decide to
> stop using this information for a release, I am not sure we need to
> really think about deprecating anything right away because of it.
Sure, I am not entirely aware of how the feature grew into the code base.
And I did not envision us ripping bits out of public API either.
We would just somehow need to accomodate for a change in advertised
behaviour that is documented in public API.
Since the feature is non-deterministic, we might however get away entirely
with just leaving it alone and using the diff I already sent :) </joke>
> If we cannot figure out this specific problem, I'd say we should
> consider disabling the feature for 1.6 but otherwise leaving the code
> and API in place. I do think that the bulk of our users will not
> really consider tree conflicts "solved" until our code is doing this
> part reliably. Perhaps that will ultimately require first-class
> rename support to get there, but I think people really want this
> feature to work.
Yes, I would entirely agree with that.
I'm still hoping to get more eyes on trying to spot the real
bug though. Ideally, we'd keep the feature, as a part of tree
conflict handling, and look into ways to make it 100% reliable
for 1.7 (if tree conflicts don't already have this effect, which
is possible, but I don't know for sure yet).
Stefan
Received on 2009-01-13 21:46:07 CET