On Sat, 2002-09-28 at 19:28, Justin Erenkrantz wrote:
> On Sat, Sep 28, 2002 at 05:11:53PM -0700, Jon Watte wrote:
> > I'm sure you understand and agree that Subversion will NOT be useful to a
> > large organization/project until it implements this mode of operation. On
> > the flip side, I entirely understand that the CVS model is initially much
> > more convenient for programmers in small to medium sized projects, and
> > the transition is just one of many you have to go through in order to be
> > able to work on a larger scale.
>
Jon's worried about scaling in terms of files in the repository. That
at least is his problem if I understand it correctly. He will have his
problems if he is on the only user of the CVS. It'll still take 10
minutes to do the stat(). I have a hard time believing even the crappy
filesystems under windows take that long, but I can believe 10 minutes
waiting on CVS. Maybe over a network fs, but that's still a really long
time. I can stat all 250K files on my Linux box in under 2 minutes w/ a
crappy IDE drive.
He'd like it if he has on line changes 5 files in 4 different
directories, he'd like to not have to pay a penalty because there are
20K files in it. It's only 5 edits. It'd be great if commit time was
proportional to the number of files edited, not proportional to the
number of files in the repository.
> I think you have your models reversed. A reserved checkout model has
> horrible scaling problems - people end up tripping over themselves
> because they are doing parallel development. User K in Chicago
> 'reserved' a file and didn't finish his changes or went on vacation,
> but User G in SF wants to do another change in that same file while
> User K holds the lock. Oops. So, you force User G to break the lock.
>
You are discussing the number of people in the who have access to the
project. Yes if 100 people are all working on a single file, resevered
check-outs is very bad. It's a problem even if there are only a handful
of files. But that's not the problem Jon's discussing.
> Reserved checkouts may make more sense in smaller projects (where
> ownership is well-defined), but almost certainly has no place in
> large projects where ownership isn't as well-defined or
> enforced. -- justin
>
Presumably, you'd like a solution that scales in both directions. That
or a solution that will let the user choose which direction they need to
scale in more. For Jon, clearly he needs something that will scale in
terms of file count. Where as large development groups will need
something that will scale in terms of number of concurrent writers to a
file.
If a user is willing to take reponsibility for doing "svn edit" before
they change a file why do you tell them it won't work. If that were
true, Perforce wouldn't be a viable product. Clearly people can and do
get use to it. I'd hate it, but I'd get over it, if it saved me 10
minutes everytime I did an svn diff/commit.
Thanks,
Kirby
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
--
Real Programmers view electronic multimedia files with a hex editor.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Sep 29 23:41:52 2002