[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: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2002-05-25 18:55:59 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

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.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat May 25 18:57:00 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.