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".
n
On Sat, 2002-05-25 at 08:30, Greg Hudson wrote:
> If my understanding is correct, Perforce clients see their working
> directories as NFS mounts, so that the Perforce server has control over
> all filesystem operations (e.g. it can keep track of which files have
> been modified so it never has to do a scan), and so that the working
> directory and repository data are all in the same place.
>
> It's not surprising that this would yield speed advantages, but it also
> limits Perforce's ability to be used in some environments.
>
> (Which is not to say that Subversion doesn't have performance overhead
> issues. The import performance and database size are particularly
> worrisome, and the checkout time isn't stellar either. 2-3 seconds for
> update/commit probably isn't too bad; it depends on how well it scales
> up.)
---------------------------------------------------------------------
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:50:23 2002