On Sat, Sep 28, 2002 at 06:06:59PM -0700, Kevin Pilch-Bisson wrote:
> Perforce is not the filesystem. Maybe you are thinking of clearcase. Here's
> how perforce works.
Indeed, I was confused. =) Sorry, they all run together.
> 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.
Which is what you have to introduce to work around the fact that
the version control system can't control the working copy. When
it is exposed as a file system, it's much easier to handle.
(Indeed, I'd imagine complete DAV-based file systems would operate
like this - flipping write attr on gets a LOCK.)
And, since this would be optional in SVN (see below), the failure
mode is a lot easier to hit. Perhaps, you could add an
--advisory-edit option to checkout, which would enforce that the WC
is checked-out read-only and you can use 'svn edit' to flip it to
write access just for that file. But, if you sustain the current
model of write-access checkouts and then using 'svn edit,' you're
going to screw up more often that not.
The problem is that if we introduce advisory edit functionality
(or an interface that does), that same interface is what is going to
*have* to implement advisory server-level locking. If you want to
suggest that we have to do:
svn local-edit foo or svn edit foo
svn server-edit foo svn lock foo
Ugh. So, while you might think the server isn't involved now, it's
going to *have* to be when we introduce advisory locking. I think
the options (from the user perspective) mean the same thing - that
I intend to modify this file - hence, we should do whatever we
have to for this file. In most cases, the user doesn't care where
that happens - client-side or server-side or both.
So, that can mean that we locally note that this file is going to be
modified, but on a RA that supports locking, that also means that
the lock has to be taken out. As a side-effect of holding the
advisory lock, the client can be smart and skip the stat() calls
for those files that don't have a lock.
Yes, you could attempt to add a "--no-server" option to edit
which won't grab the advisory lock on the server, but I'd argue
that's not what the user wants - if the WC is by default read-only,
then the repository should require locks to modify. 'svn lock foo'
could also run 'svn edit foo' if needed, but that's ugly, too. So,
I think these items are incredibly intertwined.
> Yes there are failure modes, but I don't see why they are troublesome.
Because we're going to have to offer both models - the CVS model and
the Perforce model. You're going to miss the point of SVN if we
decide to abandon the CVS model and enforce everyone to do 'svn edit'
before letting them modify the file. So, it must be an alternative
and one that can't mix with checkouts using the CVS model. -- 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 03:43:39 2002