The problem isn't necessarily a large group all committing to the same
file in the repository. I try to simulate a large group, all
committing to their own area of a project, but all in the same
repository. In other words, there is only one committer per
subdirectory tree in the repository.
This does not succeed under Windows. A single committer, committing
100 files per iteration, has run over 80,000 iterations for me so far.
I have never gotten as far as 2,000 iterations with four committers.
The problem I see isn't starvation but corruption (checksum mismatch).
It's completely repeatable ("unavoidable") but may take a couple of
hours for one of the "users" to fail.
I haven't tried this test under unix since I don't have a uniprocessor
unix box handy, and since Berkeley DB is rumored to have problems in
multiprocessor environments. I'm beginning to wonder if
*multitasking* environments aren't sufficient to induce failure, or if
perhaps BDB locking isn't working under Windows.
I use a local file repository (file://repos) to minimize variables.
I've put an infinite loop around the MoveFileEx () call to get around
the file rename bug in Windows for now.
Date: Fri, 10 Oct 2003 13:53:12 -0400
From: mark benedetto king
On Fri, Oct 10, 2003 at 10:49:01AM -0500, C. Michael Pilato wrote:
> Yes, part of our testing will involve concurrency. I should note,
> though, that if all 120 of your developers are committing at the same
> time -- well, you might consider blanket pay raises for the
> Engineering department! :-)
>
One potential issue is the "up to date" check at commit time. If your
120 people are banging in lots of commits, there is a potential for some
amount of starvation; if you're never up to date, you can never commit.
I think that in practice this is reasonably unlikely; you'd have to
be crazy to have 120 people working on the same files at the same time.
However, the bubble-up nature of directory versioning may exacerbate
this problem.
It would certainly be interesting to hear how well the *model* scales,
as opposed to the *software*.
For Very Large Software Projects, features like ClearCase's "winking"
of derived objects and it's notion of "LATEST" configurations may
justify the enormous software and management expense.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Oct 10 22:39:04 2003