[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Feature Ideas

From: Kumaran Santhanam <kumaran_at_tigris.org>
Date: 2003-08-28 16:37:00 CEST

> 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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.