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

Re: bug in recording fs 'changes'

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2005-02-11 18:30:17 CET

On Feb 11, 2005, at 5:59 AM, Philip Martin wrote:

> Greg Hudson <ghudson@MIT.EDU> writes:
>> If the object deleted was a directory, then it
>> wants to check recursively for locks underneath the pathname in
>> question; if the object deleted was a file, it wants to check only for
>> a lock at the specific pathname.
> I'm not sure that's correct.
> A recent thread confirmed that it's possible to lock schedule add
> files before the path to the file is present in the repository.
> Suppose a schedule delete file were replaced by a schedule add
> directory, then there could be schedule add files within that
> directory. Is it possible to lock such file? If so then there may be
> locks below any given repository object whether that object is a file
> or a directory.
> The current command line client cannot create such a working copy, but
> I think that's just a libsvn_wc limitation.

Sorry to be slow. I need to go revisit the locking fs code to verify
what's going on.

Philip is right, though. The following scenario is possible:

1. svn client: deletes a file in a txn
2. svn client: adds a directory by the same name
3. non-svn DAV client: locks ("reserves") an imaginary path under the
4. svn client: tries to commit

svn_fs_commit_txn() needs to do a recursive lock-check below the added
directory. Which I believe it does.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Feb 11 18:31:57 2005

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.