> I am interested to know why explicit editing is useful and
> important to you.
>
> You appear to be describing the sort of interface that would be
> used with an exclusive locking mechanism, but not proposing to
> design or implement the actual locking (which needs to involve
> the server) yet. Please could you say what benefit this will
> give on its own. It looks to me like it will give the illusion
Actually, explicit edit and locking are actually orthogonal.
Explicit edit is a client-side feature which manages the user's
file permissions. It also may or may not inform the server if
somebody is editing a file.
There are commercial SCMs which implement this, mostly for two
reasons: 1) Prevent accidental editing by the user (using the
read-only attribute) 2) Allow others to see what files are being
worked on.
Locking is a server-side enforcement (with client-side support,
of course) which prevents another user from committing a file
that is locked. In a sense, it is really an exposure of the
database locking mechanism that is already used during the commit
phase.
Here's a scenario which I have used in the past:
User A:
$ svn edit file.c
[success: file.c -> rw]
$ svn lock file.c
[success: file.c -> locked]
$ EDITOR file.c
User B:
$ svn edit file.c
[success: file.c -> rw]
$ svn lock file.c
[failure: file.c locked by User A]
$ EDITOR file.c
$ svn commit file.c
[failure: file.c locked by User A]
Now, User A decides to unlock (commit automatically unlocks the
file):
User A:
$ svn commit file.c
[success: file.c committed and unlocked]
User B:
$ svn commit file.c
[failure: update and merge required]
$ svn update
$ svn merge
$ svn commit file.c
[success: file.c committed to the repository]
As you can see, User B could still edit the file while User A had
it locked. It just prevents User B from committing before User
A. This is how some other commercial SCM locking mechanism
works, and in my experience it is pretty effective.
> I feel that exclusive locking is an essential feature for
> Subversion to aquire, but that creating the user interface
> before designing the feature is a bad way to start.
In proposing features, I am simply drawing on my experience of
what has worked for me in the past. I don't wish to propose a
radical departure from the world of standard SCM tools - that is
best saved for well after v1.0.
Kumaran
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 28 16:37:52 2003