On Sat, Sep 28, 2002 at 08:31:58PM -0400, Garrett Rooney wrote:
> but he's not asking for reserved checkouts, he's just asking for some
> model where the client already knows what files you are editing, so it
> doesn't have to stat everything to check when you want to diff or
> commit or whatever.
And, that can't work, either. You have to prevent anyone from
circumventing the process. And, the only way to do is to take
perforce's model of becoming the file system or enforce components
of the development environment. (Some work is being done here on
adding development tools for precisely this level of awareness.)
> this information /might/ be kept server side (like in perforce), but
> that doesn't mean that the fact that i'm editing a file means nobody
> else can. knowledge of what i'm working on != locks.
Any model based on pro-active usage of 'svn edit' is going to
be prone to failure conditions where modified files will not be
detected. Therefore, the only way to correctly identify if a file
is changed is to do a diff/crc/etc of the on-disk file with what we
already know about the file. Since SVN isn't the file system, we
must admit that we will have no knowledge of when a file changed.
This failure mode is more troublesome than any speed improvements.
Entry caching, of course, makes SVN way faster than it has been
before. So, I don't buy that large project WCs can't scale now.
If you want to tout this based on doing reserved checkouts, fine,
but as far as 'speed improvements' - it's a bad idea. And, as
I stated, I don't believe reserved checkouts scale. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Sep 29 02:47:31 2002