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

Re: bug in update -N hoses wc (issue #3039 )

From: David Glasser <glasser_at_davidglasser.net>
Date: 2007-12-07 02:27:32 CET

On Dec 7, 2007 1:24 AM, Karl Fogel <kfogel@red-bean.com> wrote:
> "David Glasser" <glasser@davidglasser.net> writes:
> > This bug does appear to exist on trunk. I think the basic problem is
> > that we attempt to use the requested depth of the operation to tell us
> > how deep we have to lock the working copy (ie, only lock the top if
> > it's a shallow update), but if we're deleting a directory we need to
> > have the whole directory locked.
> >
> > We could solve this by always locking all the way down, or by
> > extending the lock when it is time to delete. (Man, I want a WC where
> > all locks are deep because there's only one place where you need to
> > lock them.) Karl, opinions?
> We should lock all the way down when it's time to delete, I think.

Oh, and just to make sure: if we're doing an update at a depth that
should affect a directory A but ordinarily would not affect its
children (or its non-file children), and we get a delete for A, we
really should be doing a recursive delete anyway, right?

(ie, the problem here is that the test cases fail, not that they fail
with an unintelligible error, right?)


David Glasser | glasser_at_davidglasser.net | http://www.davidglasser.net/
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Dec 7 02:27:45 2007

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.