Quoting "C. Michael Pilato" <cmpilato@collab.net>:
> C. Michael Pilato wrote:
> > 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.
> >
>
> Doh! I shoulda read the rest of the thread first. Okay. Count this as
> "+1 for "svnadmin setuuid [--generate]".
>
> By the way, in the CollabNet patch, I basically just made
> svn_fs_set_uuid() able to accept a NULL value which means, "I don't have
> a UUID to suggest; go generate one for me."
(Re)setting the UUID doesn't help the test suite anything. Ok, we can use
hotcopy +reset UUID instead of svnadmin dump|load, but the majority of the
performance increase we get is from checking out only one working copy, and
then copy+relocate that for each sandbox working copy.
That relocate only works when the uuid of the sandbox repo is identical as the
pristine repo.
Lieven
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Nov 9 16:01:15 2006