Lieven Govaerts wrote:
> Malcolm Rowe wrote:
>> On Wed, Nov 08, 2006 at 11:40:28PM +0100, Lieven Govaerts wrote:
>>
>>> FYI: I get this issue with trunk when I'm running basic_tests parallel
>>> in 10 processes over ra_dav (on windows):
>>>
>>> ..\..\..\subversion\libsvn_client\commit.c:866: (apr_err=160044)
>>> svn: Commit failed (details follow):
>>> ..\..\..\subversion\libsvn_ra_dav\util.c:895: (apr_err=160044)
>>> svn: MERGE request failed on '/svn-test-work/repositories/basic_tests-3/A'
>>> ..\..\..\subversion\libsvn_ra_dav\util.c:385: (apr_err=160044)
>>> svn: Cannot write to the prototype revision file of transaction '1-1'
>>> because a previous representation is currently being written by this process
>>> FAIL: basic_tests.py 3: basic commit command
>>>
>>> This issue didn't show up during ra_local testing. I'll see if making
>>> the UUID unique per test repository solves it.
>>>
>>>
>> It will - the intraprocess txn serialisation is keyed on (UUID, txn id),
>> so this an expected failure mode for the case where we attempt to access
>> two different filesystems that have the same UUID.
>>
>> You'll also see serialisation in commits across all the filesystems
>> as the write-lock is keyed on UUID alone :-)
>>
>> One thing I'd like to do is make it an error to open a filesystem with
>> the same UUID as another (different) filesystem opened in the same library
>> context. But that rather requires us to fix the test suite first.
>>
> To fix the test suite I need to roll back the hotcopy/checkout/copy
> method of setting up the sandbox, back to the original (slower) svnadmin
> dump|load/checkout method.
>
> I'll do that tomorrow.
Do we have a general need for an 'svnadmin reset-uuid'? I've had to
hack in such a thing for CollabNet's deployments, but there's nothing
particularly unique about CollabNet's needs, and here's another
opportunity to make use of such a thing.
--
C. Michael Pilato <cmpilato@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on Thu Nov 9 15:48:33 2006