On 6/26/06, Lieven Govaerts <lgo@mobsol.be> wrote:
> Hi,
>
> this issue is now known as issue #2576:
> http://subversion.tigris.org/issues/show_bug.cgi?id=2576.
>
> I think what happens is this:
>
> example: svn ci -m "log msg" -N commit_tests-35 commit_tests-35\iota
> commit_tests-35\A.
>
> Normally (without -N) svn will calculate the shared base folder
> (commit_tests-35), lock that folder and automatically lock all subfolders. A
> and iota are considered as relative paths, and svn just checks if there need
> to be other locks set.
>
> With the -N option, that calculation of the shared base folder is not
> executed, so svn will see three 'relative' paths:
> commit_tests-35, commit_tests-35\iota and commit_tests-35\A. svn will add
> both commit_tests-35 and commit_tests-35\A to the list of to-be-locked
> folders. Problem is that folder commit_tests-35 is already locked (because
> it's the base folder) and then locked again because it's in the list
> dirs_to_lock. Locking a folder twice fails.
>
> To make it worse, the safety measure that aborts the while loop to find the
> parent folders doesn't work on Windows, because the root folder '/' is not
> recognized. So on Linux this code just aborts, on Windows it will loop until
> we get a stack overflow:
> if (target[0] == '/' && target[1] == '\0')
> abort();
>
> Attached is a patch that solves this issue. Please review thoroughly,
> because I'm not familiar with this code.
Seems fine to me. Applied in r20276. Thanks!
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jun 28 16:08:16 2006