Quoting Justin Erenkrantz <jerenkrantz@apache.org>:
> 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.)
Perforce is not the filesystem. Maybe you are thinking of clearcase. Here's
how perforce works.
You checkout a working copy. This works similarly to svn, except that all the
files are marked read-only, and there is no metadata dir. You then p4 edit
each file you want to edit, and the server records that, and makes the file
writable.
If you forget (hard to do with the read-only thing), there is a command which
will look at your working copy and check for any files that have been changed
to be writable, and decide that you wanted to edit them.
The suggestion is to due the same thing with svn, except keep the metadata
client side instead of server side.
Thus the svn edit command, would copy a file to its text-base location, and
make the source writable. There would have to be a way to recover from times
when you forgot to "svn edit" the file, which would probably mean going to the
server to grab the text-base.
>
> > 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
Yes there are failure modes, but I don't see why they are troublesome.
"svn scan" could check for any files in the working copy which don't match the
stored checksum, and see whether there was a corresponding text-base file or
not. If not then it grabs one from the server.
Having worked with perforce, the failure mode is possible, but easily
understood, and not that difficult to recover from.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson
kevin@pilch-bisson.net
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Sep 29 03:07:32 2002