On Sun, Mar 21, 2010 at 09:40:30AM +0100, Johan Corveleyn wrote:
> On Sat, Mar 20, 2010 at 10:44 PM, Stefan Sperling <stsp_at_elego.de> wrote:
> > The only way to "fix" this self-inflicted tree conflict would
> > be to require an update of the *entire* working copy before any changes
> > can be committed.
>
> You mean: "before you do any change", not "before any changes can be
> committed", no? The problem happens at "svn mv"-time, not at commit
> time.
Yes. I really meant to say "update right after committing before making
any further local changes to the working copy".
> > This is simply not possible to do because it is so
> > fundamentally different from the current, intended, behaviour.
> > Busy repositories would become very hard to work with.
> > As long as Subversion continues providing mixed-revision working
> > copies (possibly forever) it will not automatically bump the revision
> > of paths at commit time which aren't part of the commit.
>
> Ok, I think I'm beginning to understand that the out-of-dateness is
> really unavoidable with the mixed-revision working copy.
>
> But is there no way that this tree conflict can be avoided? That's the
> real difficulty for users now. In this case the "incoming edit" is
> just bumping the revision number of the directory. Everything else is
> already up to date AFAICS. Or is this incorrect?
It needs to bump the revision number of every path within the subtree,
not just the directory itself.
But I hope that once we've improved handling of local renames,
this particular situation should not cause a tree conflict anymore.
It will only flag a conflict if you actually delete the parent
directory, rather than renaming it. Not because we stop using
mixed-revision working copies, but because we'll be able to update
the directory at its renamed location.
Right now, svn cannot do that, because it has no good way of knowing
where in the working copy the added directory corresponding to the
deleted (renamed) directory exists. As far as svn is concerned, you
have deleted the directory before updating (even if you did a rename,
the update just sees a delete). The deletion is not based on the HEAD
revision but revision X, and more changes have been made within the directory
between rX and HEAD. Coincidentally, you made these changes from that
same working copy, but that doesn't matter. If you haven't updated the
directory before deleting it, with limited knowledge about renames svn
has to assume a tree conflict between your local delete and whatever
rX did to the directory.
> Maybe this is one of the TC cases for which an automatic resolution
> can be defined and implemented for 1.7?
This depends on what the update really does.
But I agree that we need to make it smarter in some cases.
One problem with the current TC detection code is that it flags
conflicts rather soon, upon being told that the server wants to
change a path, but without being aware of what kinds of edits
the server is really about to send for that path.
I think this is what's causing the "svn lock" TC problem you have found.
> > If you have users who really don't want to know about the details,
> > tell them to update their entire working copy before and after each
> > commit they make. That should avoid this problem, and is easy enough
> > to explain and understand.
>
> Yes, I know. But up until now this is totally unrealistic because
> update is way too slow (windows, wc-1 locking, ... it takes over 4
> minutes to perform an update of an average-size WC in our company on
> an average client pc, even when there are no incoming changes; having
> an SSD on the client machine brings this down to 45 seconds, which is
> better but still a lot IMHO). Maybe with wc-ng this will become a more
> realistic usage pattern...
Some people have already done performance benchmarks that look very
promising. See:
1) http://svn.haxx.se/dev/archive-2010-02/0457.shtml
2) http://svn.haxx.se/dev/archive-2010-02/0239.shtml
and http://svn.haxx.se/dev/archive-2010-02/0241.shtml
> Maybe a pragmatic way to avoid hitting this out-of-date + TC on
> moving/renaming a directory is just to update the dir that you're
> going to move before you move it. That's more or less manageable I
> think, as long as you don't forget it.
Yes. You are less likely to encounter tree conflicts when renaming
paths that are up-to-date. This holds true for self-inflicted tree
conflicts (you avoid the mixed-revision working copy problem) as well
as real tree conflicts (you narrow the time window in which conflicting
tree changes can be made by other people).
Stefan
Received on 2010-03-21 11:19:27 CET