> This is issue 2507
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=2507
>
> Commit does not remove locks, lock removal is a separate step after
> commit. However that doesn't work well when a commit removes a locked
> item, after such a commit the remaining lock is invalid and should not
> apply.
This is another issue. My initial post is about a bug in FSFS that could lead
to unexpected behavior of svn_fs_get_locks() function. What I'm talking about
is:
> However, the walk_digest_files() function wasn't updated to reflect the
> changes from [1] and still iterates the locks in a 'recursive' way. I
> suggest removing recursion from this function, since it can produce
> unexpected results for the caller. I've attached a patch with the test
> and the fix for this issue.
To reproduce this bug in test, I've emulated nested locks by creating a file
('/A'), locking it and then replacing by directory with same name. This looks
like a 'directory lock', and I am trying to say that if this happens in real
life, the FS API would behave incorrectly.
> What happens if you remove /A and resinstate /A as a file, does the lock
> come back?
Yes.
