> 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.
But remember, the operations that take a lot of time have nothing to do
with the SVN model. Only one of my tests involved editing a file.
Everything else was adding new files, checking out from the database,
etc. A Perforce edit call recursively on the tree is lightning fast and
would only add approximately 2 seconds to the p4 sync numbers compared
to svn co.
> 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
You still have to scan the directory tree to find the read only files,
and that operation takes as long (on Windows) as scanning the tree for
timestamps (in fact, the operation is one and the same).
Josh
---------------------------------------------------------------------
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:35:02 2002