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.
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