[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Subversion/Perforce timing statistics

From: Mark C. Chu-Carroll <mcc_at_watson.ibm.com>
Date: 2002-05-25 20:54:41 CEST

> On Sat, 2002-05-25 at 12:49, Nathan Fiedler wrote:
>> Perforce stores the depot files in a database on the server. The
>> client's working copy is stored directly to their disk, with no meta
>> information. Perforce has no control over the file system operations
>> performed on the client. In fact, you could do "p4 sync" followed by
>> "rm -rf *" followed by "p4 have" and Perforce will happily tell you
>> that you have all of the latest changes. Perforce pays no attention at
>> all to the contents of your wc. It knows what you are up to only
>> because you explicitly told it so. This makes it incredibly fast at
>> operations such as "p4 opened", "p4 have", and "p4 sync".
> Okay, that's rather different than what I thought. But it's still a
> significant departure from the SVN model, in that I have to tell
> Perforce what files I have edited (or am going to edit). I only have
> to tell SVN what files I'm going to add or remove or copy or move. So
> we can't reasonably expect Subversion performance to equal Perforce
> performance.

That does make a huge difference. The Stellation checkin timings are in the
same ballpark as the Subversion ones... I think it has a lot to do
with the fact that we both need to spend some significant time looking
at the workspace to try to figure out what changed.

> In an ideal world, it might be nice to have a Subversion mode of
> operation where files are checked out read-only and you do have to tell
> it what you're going to edit. Then there would be no need to do
> complete walks of working directories. A simple C-x C-q in emacs
> vc-mode would take care of the "svn i-am-about-to-edit" operation. But
> really, that would be a lot of hair, given that our normal mode of
> operation is (deliberately) like CVS's.

We'll be doing something like that for our Eclipse integration mode.
When programmers are working inside of an environment like Eclipse,
the environment knows what's being changed. So it gives the same
effect as reserved-checkin systems like Perforce or ClearCase. (By
the way, I think ClearCase is the one you were thinking of... It's
fully NFS based, and files in the workspace are readonly until you
specifically inform the system that you want to change them. Then, in
effect, a space is created inside the repository, and workspace
is letting you edit the working copy *directly* inside the workspace. So
effectively, checkin is free.)

As a result, I expdect that for our Eclipse integration mode, I expect
to see rather dramatically different checkin timings, because there'll be
absolutely no time spent analyzing the workspace to locate the
changes. When we've got that working, if you're interested, I can
try sending you guys timing comparisons of checkin with workspace
analysis and without. (Given the similarities in performance between
our systems, I think we can give you a pretty good ballpark estimate of
how much time reserved checkouts will save.)


*** Mark Craig Chu-Carroll,  <mcc@watson.ibm.com>
*** IBM T.J. Watson Research Center
*** The Stellation project:
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat May 25 20:55:44 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.