Quoting "C. Michael Pilato" <cmpilato@collab.net>:
> Lieven Govaerts wrote:
> > 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.
>
> Eww. That's an entirely different matter, huh?
>
> How nasty do we wanna get here? It's certainly within our
> Python-wielding powers to not use 'svn switch --relocate', and just
> write a custom WC crawler that can tweak both URL and UUID. (Yep, we've
> done *that* for CollabNet too.)
Hm, I prefer that the python tests only use 'official' svn operations and don't
touch the admin entries.
The reason why the tests now have problems with the uuid's not being unique is
because I'm changing the framework to run tests in parallel. Running the tests
in parallel gives a performance increase of x2.5, so I have no problem rolling
back to the original sandbox method (create repos+checkout).
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:28:53 2006