this issue is now known as issue #2576:
I think what happens is this:
example: svn ci -m "log msg" -N commit_tests-35 commit_tests-35\iota
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 == '/' && target == '\0')
Attached is a patch that solves this issue. Please review thoroughly,
because I'm not familiar with this code.
Fix for issue 2576: Don't lock the base folder twice when
committing overlapping targets non-recursively.
(svn_client_commit3): add extra checks to avoid adding the
base folder to dirs_to_lock.
Catch a potential stack overflow on Windows, abort()
(commit_same_folder_in_targets): New test
(test_list): Run the new commit test.
> -----Original Message-----
> From: Lieven Govaerts [mailto:firstname.lastname@example.org]
> Sent: zondag 25 juni 2006 8:49
> To: email@example.com
> Cc: 'Nicolás Lichtmaier'
> Subject: [BUG] regression: 'svn commit -N folder folder' will
> crash svn 1.4 and trunk (was: Crash in 1.4 with "svn commit
> -N . something")
> a few days ago Nicolás reported a bug on this list
> (http://svn.haxx.se/dev/archive-2006-06/0689.shtml) that
> seems to be a regression compared to 1.3. I'm reposting it to
> make sure we solve it in 1.4.
> The problem:
> 1. checkout a branch in /tmp/trunk
> 2. alter a file test in the trunk wc
> 3. svn commit -N /tmp/trunk /tmp/trunk/test
> On my machine (windows xp) with svn 1.4_RC1 and trunk, the
> svn process will start using huge amounts of memory
> (increasing 100MB per sec) before it crashes. Server is
> apache 2.0.55 with svn trunk modules.
> Attached is a python test that triggers this problem. Please
> do not commit this to the repository before the issue is
> solved! The original mail from Nicolás also contains a short
> analysis of the problem and a patch.
> Nicolás, can you report this in the issue tracker? Otherwise
> I'll do it.
> Test committing two overlapping targets non-recursively.
> * subversion/tests/cmdline/commit_tests.py
> (commit_same_folder_in_targets): New test
> (test_list): Run the new commit test.
Received on Mon Jun 26 23:22:45 2006
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com