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

Re: [Locking] commit and unlock

From: Benjamin Pflugmann <benjamin-svn-dev_at_pflugmann.de>
Date: 2004-12-17 10:27:16 CET

On Fri 2004-12-17 at 01:27:11 +0000, Julian Foad wrote:
> >As a project administrator, I often put locks on files that I don't want
> >people to edit, even if I'm not actively working on it. I want to lock
> >it and leave it, knowing that it will be preserved in that state until
> >I'm ready for it.
> That sounds like a bit of a crude way of implementing access control. You
> are free to do that if it works for you, but I don't think that this
> discussion should by influenced by a desire to facilitate that usage.

I understand locking to be mainly for serializing access, while
authorization is mainly for controlling access. Please correct me, if
I am wrong.

So while freezing a branch in preparation for and during rolling a
release could be implemented via authorization (or pre-commit hook),
locking it seems the easier choice to me. Maybe Ben Reser likes that
idea. ;)

Similar for the case, when I want to show the current prototype to the
customer using the staging server and simply want prevent anyone
messing with me for the time in question (without having to disable
the post-commit hook that auto-updates the staging server). Seems a
clear case of serializing access to the resource to me. :)

I don't mean, that any emphasis should be put on the that. I just
wanted to point out that while this is a bit in-between, this was not
about misusing locking to implement authorization.



To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Dec 17 10:28:44 2004

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.