You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Peter Davis <pe...@pdavis.cx> on 2002/08/01 15:25:15 UTC
Re: [Issue 533] New - implement reserved checkouts
On Thursday 01 August 2002 08:03, issues@subversion.tigris.org wrote:
> + $ svn lock foo.c
> +
> + sets the `svn:locked' property on foo.c, with prop value of the user's
> + name (perhaps
> + email address too, whatever other information can be gathered from the
> + config files and elsewhere), and automatically commits. Thus, if
> + foo.c is out of date, you can't take out a lock on it, which seems right.
I really like this. I'm what one of the other comments would call an "early
adopter", and I generally believe that locking is Evil. But this would be
really attractive, for all the reasons you describe.
I don't think it goes against Subversion theory, since it's just a property
that can be removed. It's useful because it lets you easily see who the
locker is.
Hopefully this can make it past the "idea" stage; if not for me or for the
beauty of it, then do it for the poor helpless minions whose project managers
won't switch until they see VSS-style locking.
pdavis$ svn lock foo.c
foo.c locked by "pdavis <pe...@pdavis.cx>"
joeschmoe$ svn ci foo.c
ERROR! foo.c has been locked by "pdavis <pe...@pdavis.cx>".
<joeschmoe contacts pdavis, but pdavis is a jerk and won't release the lock
(even though he's not editing foo.c)>
joeschmoe$ svn unlock foo.c
ERROR! Only "pdavis <pe...@pdavis.cx>" can unlock foo.c. Use --force to
override.
joeschmoe$ svn unlock --force foo.c
joeschmoe$ svn ci foo.c
Committed revision 314159.
Or maybe even have just "svn ci --force" to get around the locking, so that
you don't have to have a working copy if you are doing URL-based operations.
This could apply to directories too: it would prevent from changing, adding,
or deleting any file in the locked directory.
--
Peter Davis
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Issue 533] New - implement reserved checkouts
Posted by "Glenn A. Thompson" <gt...@cdr.net>.
hey
Karl Fogel wrote:
> brane@xbc.nu writes:
> > I think it's a total waste of time to hack up some sort of locking, only to
> > throw it away when we do it for real. Any locking scheme would have to be
> > understood by the filesystem -- a locked item should not be added to a commit
> > txn -- and that support would be the major part of the effort, and
> > must be done correctly the first time.
>
> That locking should be understood at the libsvn_repos layer I totally
> agree. But should it be all the way down in libsvn_fs?
>
My .000002
To me it seems it belongs at the FS level. When/how to use locks "may" be a repo
level function. The lock itself does seem to belong in the FS. It feels like
maybe it needs to be managed at the dir entry level as opposed to the file level.
You should still be able to commit to a branch even if head is locked. Right?
gat
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Issue 533] New - implement reserved checkouts
Posted by br...@xbc.nu.
Karl Fogel wrote:
>brane@xbc.nu writes:
>
>
>>I think it's a total waste of time to hack up some sort of locking, only to
>>throw it away when we do it for real. Any locking scheme would have to be
>>understood by the filesystem -- a locked item should not be added to a commit
>>txn -- and that support would be the major part of the effort, and
>>must be done correctly the first time.
>>
>>
>
>That locking should be understood at the libsvn_repos layer I totally
>agree. But should it be all the way down in libsvn_fs?
>
>Maybe you wouldn't mind a pre-1.0 implementation so much if it avoided
>touching the fs itself, Brane...
>
>
Heh, maybe yes, but I can't imagine such an imlementation. The
filesystem must know about locks, how else do you prevent adding a
locked object to a commit txn? Of course, you could put an explicit
check outsude the FS, but that seems like an excruciatingly painful hack.
I can handle pain, but not that much pain. :-)
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Issue 533] New - implement reserved checkouts
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
brane@xbc.nu writes:
> I think it's a total waste of time to hack up some sort of locking, only to
> throw it away when we do it for real. Any locking scheme would have to be
> understood by the filesystem -- a locked item should not be added to a commit
> txn -- and that support would be the major part of the effort, and
> must be done correctly the first time.
That locking should be understood at the libsvn_repos layer I totally
agree. But should it be all the way down in libsvn_fs?
Maybe you wouldn't mind a pre-1.0 implementation so much if it avoided
touching the fs itself, Brane...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Issue 533] New - implement reserved checkouts
Posted by Jim Blandy <ji...@red-bean.com>.
brane@xbc.nu writes:
> Also, -1 on the idea of a svn:locked property: Locking a file must
> not result in a version bump, that would IMHO violate the DAV spec,
> and we want our locking implementation to be compatible with DAV.
Commenting just on the "compatible with DAV" issue, not on the
"locking with properties" issue:
I think it's more important for the locking system be helpful to
developers than to be compatible with DAV. I don't like the idea of
justifying our application's behavior on the basis of how compatible
it is with our network protocol. I think Subversion should be a
version control system first, and a DAV implementation second, or
fifth, or something.
This is not an anti-DAV post. I have no idea what semantics DAV's
locking methods have. Even if they're great, that doesn't change my
point.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Issue 533] New - implement reserved checkouts
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Aug 02, 2002 at 01:24:12PM +0200, brane@xbc.nu wrote:
> Quoting "Jay Freeman (saurik)" <sa...@saurik.com>:
> > How would something like this interact with possible, future support for
> > WebDAV's LOCK and UNLOCK methods?
Not one bit.
My suggestion was for a system that was completely orthogonal to the 1.0
development track. It can exist wholly and completely separate from SVN 1.0.
> > It seems silly to go to the effort of
> > building some complex seperate system (involving seperate applications and
> > seperate scripts, talking to a seperate database, that might end up with
> > slightly different portability than the actual svn client, and then on top
> > of that shoving the responsibility for coding the lock support into every
> > GUI that wants to support it) for keeping track of locks and then find out
> > that the way it was done didn't end up helping to implement LOCK and
> > UNLOCK.
>
> I must say I agree.
>
> I think it's a total waste of time to hack up some sort of locking, only to
> throw it away when we do it for real. Any locking scheme would have to be
You guys aren't getting where I was going.
1) given: SVN 1.0 won't have reserved checkouts
2) therefore, you must design a system that lives *outside* of SVN
3) therefore, you end up with something like I described
'nuf said
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Re: [Issue 533] New - implement reserved checkouts
Posted by Jeff Putsch <pu...@mxim.com>.
On Fri, Aug 02, 2002 at 10:46:13AM -0700, Bill Tutt wrote:
> If it's not pointless then they can branch it. :)
>
> Bill
> ----
> > From: Karl Fogel [mailto:kfogel@newton.ch.collab.net]
> >
> > "Bill Tutt" <ra...@lyra.org> writes:
> > > Well, if you can't diff/merge the sucker than having two people make
> > > changes at the same time is pretty pointless.
> >
> > If they're both aware that they're doing it, but they keep doing it
> > anyway, then it's probably not pointless. They could be each making
> > alternate versions of the file, to be chosen between later, for
> > example.
There are some reasonable uses for systems like Subversion where having
people be able to make changes at the same time to a given binary file
not desired. If they really want/need to do this (e.g. alternate versions)
then a branch or a copy is required.
In my particular case we are evaluating Subversion for use as a revision
system for CAE software (Cadence in particular) when used in a distributed
design environment -- multiple sites across the world. In this case having
the locks/reservations on binary files would be very useful. We really do
not want two users to be making changes to the same schematic or layout
at the same time. Yes we can handle the collision later, but preventing
it with locks is much more desirable.
Jeff.
--
Jeff Putsch Email: putsch@mxim.com
Maxim Integrated Products Office: (503)547-2037
High Frequency CAD Engineering
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Issue 533] New - implement reserved checkouts
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
"Bill Tutt" <ra...@lyra.org> writes:
> If it's not pointless then they can branch it. :)
:-)
What I'm getting at is:
> > If they're both aware that they're doing it, but they keep doing it
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
That is, if there is an advisory lock, telling them that they're both
modifying the same file, and they persist, they must be persisting for
reason. And those who don't have a reason to persist can just make a
branch at that point.
All I'm saying is, no reason to have two kinds of locks here. One
kind of lock is fine, and it's okay for it to be stealable
(overrideable, whatever you want to call it). Because if someone
overrides, then they chose that course consciously.
Maybe I'm confused about terminology? I thought:
- "advisory lock": a lock that can be overridden or stolen.
- "firm lock": only the locker, or an admin, can undo this.
And I'm advocating that we have only advisory locks.
But maybe there is a richer tradition in locking schemes, that I'm not
aware of? It would be good if someone could describe that, if so...
Thanks,
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Re: [Issue 533] New - implement reserved checkouts
Posted by Bill Tutt <ra...@lyra.org>.
If it's not pointless then they can branch it. :)
Bill
----
Do you want a dangerous fugitive staying in your flat?
No.
Well, don't upset him and he'll be a nice fugitive staying in your flat.
> From: Karl Fogel [mailto:kfogel@newton.ch.collab.net]
>
> "Bill Tutt" <ra...@lyra.org> writes:
> > Well, if you can't diff/merge the sucker than having two people make
> > changes at the same time is pretty pointless.
>
> If they're both aware that they're doing it, but they keep doing it
> anyway, then it's probably not pointless. They could be each making
> alternate versions of the file, to be chosen between later, for
> example.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Issue 533] New - implement reserved checkouts
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
"Bill Tutt" <ra...@lyra.org> writes:
> Well, if you can't diff/merge the sucker than having two people make
> changes at the same time is pretty pointless.
If they're both aware that they're doing it, but they keep doing it
anyway, then it's probably not pointless. They could be each making
alternate versions of the file, to be chosen between later, for
example.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Re: [Issue 533] New - implement reserved checkouts
Posted by Bill Tutt <ra...@lyra.org>.
> From: Karl Fogel [mailto:kfogel@newton.ch.collab.net]
>
> "Bill Tutt" <ra...@lyra.org> writes:
> > * If the file can't be diffed and merged (text files of course can
> > always be diffed and merged) then a reserved LOCK occurs.
>
> Are diffability and mergeability so important? It's not like any
> information is actually going to be lost...
>
Well, if you can't diff/merge the sucker than having two people make
changes at the same time is pretty pointless. Thus upgrading from a soft
lock to a hard lock. VSS takes the cheesy way out and decrees that all
binary files always get hard reserved checkout locks. Normal files in
VSS are checked out on an advisory or reserved basis depending on a
repository configuration option, IIRC.
FYI,
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Issue 533] New - implement reserved checkouts
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
"Bill Tutt" <ra...@lyra.org> writes:
> * If the file can't be diffed and merged (text files of course can
> always be diffed and merged) then a reserved LOCK occurs.
Are diffability and mergeability so important? It's not like any
information is actually going to be lost...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Issue 533] New - implement reserved checkouts
Posted by br...@xbc.nu.
Bill Tutt wrote:
>Btw, I totally agree with Brane here. If I had my way, I'd recommend the
>following approach for handling "locking" with respect to how Subversion
>operates. This is based on a tweak of how VSS works btw, and it works
>fairly well.
>
>* Support whatever DAV LOCK/UNLOCK semantics necessary for
>non-Subversion clients.
>
+1. Obviously.
>* Implement the pluggable diff/merge mechanism based on MIME type we've
>been talking about for ages.
>
This has nothing to do with locking, even given what you say below.
>* If the file can be diffed and merged then we can create an advisory
>lock. i.e. clients can display who else (and possibly more than one
>person) is modifying a file.
>* If the file can't be diffed and merged (text files of course can
>always be diffed and merged) then a reserved LOCK occurs.
>
I'm leaning against having two kinds of locks, and would prefer to have
mandatory locks only.
>Obviously, this isn't a cooked design. I'm not quite so thrilled about
>non-historic properties on things for keeping track of locks. I don't
>think locks are going to be quite that simple.
>
>What happens to a lock when a file undergoes various copy/move
>operations?
>
You can copy a locked file, in which case the destination is a new
object, and obviously not locked. You just can't commit a change to a
locked file (unless you're the lock owner, of course). Therefore, you
can't move/rename a locked file.
(Yes, I know that internally we have a unix-like implementation, where a
rename is really a modification of the parent directory. IMHO locking
should work more like renames, deletes, etc. in a Windows filesystem,
where these are operations on the objct itself, and controlled by the
object's ACL.)
> Does the lock apply to a NodeRevision that has been cheaply
>branched but hasn't yet been modified? etc....
>
A lock refers to a certain revision/path combination. The revision can
either be explicit (e.g., you can lock an old version of a file, thereby
forbidding branching from that version --- and I realise this is in
direct contradiction to what I said about copying above), or implicitly
HEAD.
>I also agree with Brane that cooked in support into Subversion for this
>just shouldn't happen for 1.0.
>
>Your friendly schema helper taking a stab at the requirement list,
>
Thanks!
Come to think of it, here's how ClearCase implements reserved checkouts.
When you check out an element, it actually creates a _new_ version of
that element on the branch, and locks access to _that_. This prevents
other people from checking out on the same branch, but allows them to
create new branches from the last checked-in version. (This would
correspond to the implicit-HEAD revision I mentioned above, _and_ it
would imply that creating a lock means creating a long-lived txn on the
server. But I digress). In ClearCase, you can also lock an old version;
you can't create branches from that version. This is all consistent,
because nobody but the lock owner acutally sees the "virtual"
checked-out version.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Re: [Issue 533] New - implement reserved checkouts
Posted by Bill Tutt <ra...@lyra.org>.
Btw, I totally agree with Brane here. If I had my way, I'd recommend the
following approach for handling "locking" with respect to how Subversion
operates. This is based on a tweak of how VSS works btw, and it works
fairly well.
* Support whatever DAV LOCK/UNLOCK semantics necessary for
non-Subversion clients.
* Implement the pluggable diff/merge mechanism based on MIME type we've
been talking about for ages.
* If the file can be diffed and merged then we can create an advisory
lock. i.e. clients can display who else (and possibly more than one
person) is modifying a file.
* If the file can't be diffed and merged (text files of course can
always be diffed and merged) then a reserved LOCK occurs.
Obviously, this isn't a cooked design. I'm not quite so thrilled about
non-historic properties on things for keeping track of locks. I don't
think locks are going to be quite that simple.
What happens to a lock when a file undergoes various copy/move
operations? Does the lock apply to a NodeRevision that has been cheaply
branched but hasn't yet been modified? etc....
I also agree with Brane that cooked in support into Subversion for this
just shouldn't happen for 1.0.
Your friendly schema helper taking a stab at the requirement list,
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Issue 533] New - implement reserved checkouts
Posted by br...@xbc.nu.
Quoting Mark <cm...@yahoo.com>:
>
> I have been looking over this thread and have a few questions regarding
> the
> idea of reserved checkouts. I am sure I don't fully understand the SVN
> implemetation being discussed.
>
> Will all the SVN clients know, in real time, that file.doc has just been
> locked in SVN workarea ABC?
Locking a resource won't send notifications to clients, if that's what you're
asking. It will, though, prevent other clients from locking the same resource.
> If a main benefit of having reserved checkouts is to be able to prevent
> two people (or more approprately, two workareas) from modifying
> the same non-mergeable file at the same time (because enforcing locks at
> commit
> time is to late, work already has been done on the non-mergable file in
> both
> workareas), will svn be able to handle reserved checkouts in this
> manner?
Note that we haven't discussed the semantics in depth yet. So I can't really
answer your questions. "cvs edit"-like functionality has been discussed, as has
the idea that whether checkouts should be reserved by default or not would be a
property of the resource.
> If not, then what is the goal/functionality/purpose of the reserved
> checkout/lock functionality being proposed here with SVN?
>
> Are we talking about SVN providing readonly workareas, requiring a 'cvs edit'
> like functionality to make files writeable? Maybe that could work, but if it is
> possible to break a lock in one workarea from another workarea or non-workarea
> (SVN will know which workarea has the lock on the file, right?), how will SVN
> notify the SVN workarea
As I said, there won't be any dynamic notifications, at least for a long time.
> that had the lock, that the lock has been broken (so
> the client can report that the file is now unlocked and is now readonly in that
> workarea)? Okay, in this situation, what happens to local edits on that file in
> that SVN workarea that got unreserved ('cvs unedit' reversion of the file)?
>
> If a workable reserved checkout implementaion is worked out, can it be made
> required for certain file types, while allowing CVS style concurrency on
> mergable files?
I can see that happening, yes.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Issue 533] New - implement reserved checkouts
Posted by Mark <cm...@yahoo.com>.
I have been looking over this thread and have a few questions regarding the
idea of reserved checkouts. I am sure I don't fully understand the SVN
implemetation being discussed.
Will all the SVN clients know, in real time, that file.doc has just been locked
in SVN workarea ABC? If a main benefit of having reserved checkouts is to be
able to prevent two people (or more approprately, two workareas) from modifying
the same non-mergeable file at the same time (because enforcing locks at commit
time is to late, work already has been done on the non-mergable file in both
workareas), will svn be able to handle reserved checkouts in this manner? If
not, then what is the goal/functionality/purpose of the reserved checkout/lock
functionality being proposed here with SVN?
Are we talking about SVN providing readonly workareas, requiring a 'cvs edit'
like functionality to make files writeable? Maybe that could work, but if it is
possible to break a lock in one workarea from another workarea or non-workarea
(SVN will know which workarea has the lock on the file, right?), how will SVN
notify the SVN workarea that had the lock, that the lock has been broken (so
the client can report that the file is now unlocked and is now readonly in that
workarea)? Okay, in this situation, what happens to local edits on that file in
that SVN workarea that got unreserved ('cvs unedit' reversion of the file)?
If a workable reserved checkout implementaion is worked out, can it be made
required for certain file types, while allowing CVS style concurrency on
mergable files?
Thanks,
Mark
__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Issue 533] New - implement reserved checkouts
Posted by br...@xbc.nu.
Quoting "Jay Freeman (saurik)" <sa...@saurik.com>:
> How would something like this interact with possible, future support for
> WebDAV's LOCK and UNLOCK methods? It seems silly to go to the effort of
> building some complex seperate system (involving seperate applications and
> seperate scripts, talking to a seperate database, that might end up with
> slightly different portability than the actual svn client, and then on top
> of that shoving the responsibility for coding the lock support into every
> GUI that wants to support it) for keeping track of locks and then find out
> that the way it was done didn't end up helping to implement LOCK and
> UNLOCK.
I must say I agree.
I think it's a total waste of time to hack up some sort of locking, only to
throw it away when we do it for real. Any locking scheme would have to be
understood by the filesystem -- a locked item should not be added to a commit
txn -- and that support would be the major part of the effort, and must be done
correctly the first time.
Also, -1 on the idea of a svn:locked property: Locking a file must not result in
a version bump, that would IMHO violate the DAV spec, and we want our locking
implementation to be compatible with DAV.
The first prerequisite for locks is the same as for ACLs -- non-historic
properties. Of course, the semantics required for locks are simpler than for
ACLs, as locks don't require property inheritance or DAV access to principals.
But most of the infrastructure would be the same.
Here's what needs to be done:
1) Design non-historic properties, keeping in mind a two-stage implementatino
(first only the semantics required for locking, then for full ACL support).
2) Design and implement locking support in the filesystem, RA layer and client
libraries.
3) Design and implement "svn lock/unlock".
Adding support for DAV auto-versioning to mod_dav_svn can run in parallel, at
least for the non-locking case.
Looking at this list, it's immediately obvious to methat it can't be done before
1.0. There are simply not enough knowledgable people around with time on their
hands to do this.
I would be willing to work on this (I would very mich like to have both locking
and auto-versioning), but then I wouldn't be able to work on Beta issues, which
I believe are more important.
You know, I'd much rather work on new features than bug fixes, and so I suspect
would most people. :-) But then we'd never get 1.0 out the door. :-( So, much as
I would love to see reserved checkouts in Subversion 1.0, I recognize that the
schedule won't allow it. I'll even go as far as to predict that any patch to add
locking before 1.0 has a strong chance of getting a veto from me, because a)
it's likely to touch a lot of code and would therefore be too risky at this
stage, and b) there simply isn't time for a thorough discussion of the design
before 1.0.
Please don't get me wrong: I'm not saying we shouldn't discuss it, or that we
shouldn't create a branch for playing around with prototypes. Volunteers' time
is our own, and all that. But none of this should distract us from our main
purpose at this point, which is concentrating on 1.0.
O.K., taking my project manager's hat off now.
Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Issue 533] New - implement reserved checkouts
Posted by "Jay Freeman (saurik)" <sa...@saurik.com>.
How would something like this interact with possible, future support for
WebDAV's LOCK and UNLOCK methods? It seems silly to go to the effort of
building some complex seperate system (involving seperate applications and
seperate scripts, talking to a seperate database, that might end up with
slightly different portability than the actual svn client, and then on top
of that shoving the responsibility for coding the lock support into every
GUI that wants to support it) for keeping track of locks and then find out
that the way it was done didn't end up helping to implement LOCK and UNLOCK.
Sincerely,
Jay Freeman (saurik)
saurik@saurik.com
----- Original Message -----
From: "Greg Stein" <gs...@lyra.org>
To: "Brian Behlendorf" <br...@collab.net>
Cc: <de...@subversion.tigris.org>
Sent: Thursday, August 01, 2002 8:00 PM
Subject: Re: [Issue 533] New - implement reserved checkouts
...
> Not at all. The *lock mgmt* needs to run via a web server. You could still
> commit locally, while your locks are being managed via your client tool
and
> the commit hooks.
>
> But if you stop and think about it: it doesn't *have* to go via a web
> server. I just proposed the client tool talk to the server via HTTP. If
the
> client tool talks to a local DB of locks... fine! No problem at all.
>
> > I don't see how one could lock it if running local.
>
> The tool talks to the local DB of locks. The hooks check the DB just like
> normal. What's the problem? :-)
>
> > Personally I like the idea of making it a property; the only downside is
> > the revision bump, and having it trigger a commit email seems like a
> > positive thing.
>
> The 'svnres lock' could also issue an email. Not a problem there. (and I
> would expect it to)
>
> Cheers,
> -g
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Issue 533] New - implement reserved checkouts
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Aug 01, 2002 at 05:37:25PM -0700, Brian Behlendorf wrote:
> On Thu, 1 Aug 2002, Peter Davis wrote:
> > On Thursday 01 August 2002 14:44, you wrote:
> > > I'm not a fan of creating a new revision simply
> > > because somebody took out a lock on something they *might* change (they
> > > could revert and cancel their lock).
> >
> > You're right -- as soon as I started thinking about how to do this, that
> > popped out like a sore thumb. At least it would force people to submit a log
> > message saying why they took out the lock. But yes, that would pollute the
> > repository far too much.
>
> I dunno. Greg's proposal requires you to be running your svn repos behind
> a web server;
Not at all. The *lock mgmt* needs to run via a web server. You could still
commit locally, while your locks are being managed via your client tool and
the commit hooks.
But if you stop and think about it: it doesn't *have* to go via a web
server. I just proposed the client tool talk to the server via HTTP. If the
client tool talks to a local DB of locks... fine! No problem at all.
> I don't see how one could lock it if running local.
The tool talks to the local DB of locks. The hooks check the DB just like
normal. What's the problem? :-)
> Personally I like the idea of making it a property; the only downside is
> the revision bump, and having it trigger a commit email seems like a
> positive thing.
The 'svnres lock' could also issue an email. Not a problem there. (and I
would expect it to)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Issue 533] New - implement reserved checkouts
Posted by Brian Behlendorf <br...@collab.net>.
On Thu, 1 Aug 2002, Peter Davis wrote:
> On Thursday 01 August 2002 14:44, you wrote:
> > I'm not a fan of creating a new revision simply
> > because somebody took out a lock on something they *might* change (they
> > could revert and cancel their lock).
>
> You're right -- as soon as I started thinking about how to do this, that
> popped out like a sore thumb. At least it would force people to submit a log
> message saying why they took out the lock. But yes, that would pollute the
> repository far too much.
I dunno. Greg's proposal requires you to be running your svn repos behind
a web server; I don't see how one could lock it if running local.
Personally I like the idea of making it a property; the only downside is
the revision bump, and having it trigger a commit email seems like a
positive thing.
Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Issue 533] New - implement reserved checkouts
Posted by Peter Davis <pe...@pdavis.cx>.
On Thursday 01 August 2002 14:44, you wrote:
> I'm not a fan of creating a new revision simply
> because somebody took out a lock on something they *might* change (they
> could revert and cancel their lock).
You're right -- as soon as I started thinking about how to do this, that
popped out like a sore thumb. At least it would force people to submit a log
message saying why they took out the lock. But yes, that would pollute the
repository far too much.
Your idea of having a separate CGI program seems like it would work better,
but it sounds like the scope of a separate project. I'm already in the
process of starting two of my own projects (one is the Subissue project I
posted about earlier), not to mention my "real" job, so I can't really devote
any effort to a whole new project, as fun as it would be.
--
Peter Davis
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Issue 533] New - implement reserved checkouts
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Aug 01, 2002 at 03:24:51PM -0700, Peter Davis wrote:
> On Thursday 01 August 2002 15:05, you wrote:
> > And if you are taking a poll, tally me as neutral. I like the
> > simplicity of my original proposal, but the spurious revisions thing
> > really is a bit of a problem. The CGI and pre-commit hook solution
> > has some advantages too.
>
> I completely agree. I was excited enough to want to build it myself, but then
> I realized that shortcoming. I like the CGI too, but I don't have time to
> start up a new project (since it should probably be separate from the
> Subversion base -- if you think otherwise, then let me know).
If somebody were to start this coding (I'm certainly not; I've just been
*thinking* about the problem :-), then I would highly recommend that the
code goes right into /trunk/tools/reserved/. We've got other stuff in tools/
which are used with Subversion, and this would be one of them.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Issue 533] New - implement reserved checkouts
Posted by Peter Davis <pe...@pdavis.cx>.
On Thursday 01 August 2002 15:05, you wrote:
> And if you are taking a poll, tally me as neutral. I like the
> simplicity of my original proposal, but the spurious revisions thing
> really is a bit of a problem. The CGI and pre-commit hook solution
> has some advantages too.
I completely agree. I was excited enough to want to build it myself, but then
I realized that shortcoming. I like the CGI too, but I don't have time to
start up a new project (since it should probably be separate from the
Subversion base -- if you think otherwise, then let me know).
--
Peter Davis
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Issue 533] New - implement reserved checkouts
Posted by Kieran <ki...@esperi.demon.co.uk>.
On 1 Aug 2002, Karl Fogel wrote:
> Peter Davis <pe...@pdavis.cx> writes:
> > I think it's an integral part of the proposal. Unfortunately, I'd hate to
> > wade through the repository logs when most of the revisions are just lock
> > requests.
>
> Hmmm, yeah. You guys have a point -- I wouldn't want to wade through
> those logs either! :-)
>
I see a great need for "svn log -q" ...
Oh wait, that was the other thread :)
Regards
Kieran
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Issue 533] New - implement reserved checkouts
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Peter Davis <pe...@pdavis.cx> writes:
> I think it's an integral part of the proposal. Unfortunately, I'd hate to
> wade through the repository logs when most of the revisions are just lock
> requests.
Hmmm, yeah. You guys have a point -- I wouldn't want to wade through
those logs either! :-)
> Does tigris.org allow you to take polls? Maybe a poll should be set up
> somewhere, or a thread started on the users list (ooh, flamewar), to see how
> people feel about locking, and (more importantly) whether creating a new
> revision for each lock and unlock would be a turnoff. If enough people
> aren't turned off, then maybe I'll give a go at building it anyway.
We haven't really "activated" the users list yet, thinking it better
to keep all discussion focused here so everyone can see everything.
We're afraid of ghetto-izing various parts of the community (e.g.,
developers from users, repos admins from client-only users, etc).
But you could take a poll here.
And if you are taking a poll, tally me as neutral. I like the
simplicity of my original proposal, but the spurious revisions thing
really is a bit of a problem. The CGI and pre-commit hook solution
has some advantages too.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Issue 533] New - implement reserved checkouts
Posted by Peter Davis <pe...@pdavis.cx>.
On Thursday 01 August 2002 14:42, you wrote:
> I'm not understanding how the second sentence above is incompatible
> with the proposal...
I think it's an integral part of the proposal. Unfortunately, I'd hate to
wade through the repository logs when most of the revisions are just lock
requests.
The proposal would probably still be useful to a lot of people. However, I'm
not sure I'd want to build it if I would never want use it myself.
Does tigris.org allow you to take polls? Maybe a poll should be set up
somewhere, or a thread started on the users list (ooh, flamewar), to see how
people feel about locking, and (more importantly) whether creating a new
revision for each lock and unlock would be a turnoff. If enough people
aren't turned off, then maybe I'll give a go at building it anyway.
--
Peter Davis
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Issue 533] New - implement reserved checkouts
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Greg Stein <gs...@lyra.org> writes:
> Personally, I don't :-) I'm not a fan of creating a new revision simply
> because somebody took out a lock on something they *might* change (they
> could revert and cancel their lock). Also, I believe the typical pattern of
> behavior is that a person will incrementally take out their advisory locks
> as they discover they need to change <whatever> files.
I'm not understanding how the second sentence above is incompatible
with the proposal...
> Locking is evil *only* when you have documents that can easily be merged.
> Locking is an absolute must for things like .doc or .xls files. Two people
> cannot work on those at the same time, and merge their changes later. Thus,
> it is a requirement to have a lock.
Why? For non-mergeables, it's still *communication* that's the
necessity. After all, neither set of changes need be lost in case of
a conflict. And one set of changes could simply never be started, if
they have communication.
I don't see the requirement for a lock at all here.
Put it this way: you say
"Two people cannot work on those at the same time"
...so Subversion should make it easy for them to avoid working on
those two things at the same time. Locks are not the only way to do
that.
> My thinking has been along this line:
>
> * the server has a CGI script that manages a DB of locks
> * a start-commit hook tosses anybody that doesn't hold a lock
> * a pre-commit hooks tosses commits to items that are not locked by the
> commiter (read: you must lock everything before committing)
> * a post-commit hook clears locks on items which were committed
> * a client-side tool interacts with the CGI to:
> - establish a lock
> - remove a lock
> - list existing locks
> - break locks
> * the CGI is also responsible for sending emails
That would work too. Not sure which is more complex internally; but
the need for a separate client side tool is a bit of devel overhead...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Issue 533] New - implement reserved checkouts
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Aug 01, 2002 at 08:25:15AM -0700, Peter Davis wrote:
> On Thursday 01 August 2002 08:03, issues@subversion.tigris.org wrote:
> > + $ svn lock foo.c
> > +
> > + sets the `svn:locked' property on foo.c, with prop value of the user's
> > + name (perhaps
> > + email address too, whatever other information can be gathered from the
> > + config files and elsewhere), and automatically commits. Thus, if
> > + foo.c is out of date, you can't take out a lock on it, which seems right.
>
> I really like this. I'm what one of the other comments would call an "early
Personally, I don't :-) I'm not a fan of creating a new revision simply
because somebody took out a lock on something they *might* change (they
could revert and cancel their lock). Also, I believe the typical pattern of
behavior is that a person will incrementally take out their advisory locks
as they discover they need to change <whatever> files.
> adopter", and I generally believe that locking is Evil. But this would be
Locking is evil *only* when you have documents that can easily be merged.
Locking is an absolute must for things like .doc or .xls files. Two people
cannot work on those at the same time, and merge their changes later. Thus,
it is a requirement to have a lock.
My thinking has been along this line:
* the server has a CGI script that manages a DB of locks
* a start-commit hook tosses anybody that doesn't hold a lock
* a pre-commit hooks tosses commits to items that are not locked by the
commiter (read: you must lock everything before committing)
* a post-commit hook clears locks on items which were committed
* a client-side tool interacts with the CGI to:
- establish a lock
- remove a lock
- list existing locks
- break locks
* the CGI is also responsible for sending emails
Thus, a typical operation will be something like:
$ svn up
...
$ svnres lock foo.c # svnres == "svn reserved checkout tool"
foo.c has been locked.
$ jed foo.c
$ svn commit
...
$ svnres lock bar.c
bar.c is locked by "C. Mike Pilato <cm...@collab.net>"
$ svnres break bar.c
bar.c has been unlocked.
"C. Mike Pilato <cm...@collab.net>" has been notified.
$ svnres lock bar.c
bar.c has been locked.
...
$ svnres list
bar.c is locked by you.
baz.c is locked by you.
gloo.h is locked by "Ben Collins-Sussman <su...@collab.net>"
subdir/fnord.c is locked by "Illuminati <fn...@fnord.net>"
...
$ jed foo.c
$ svn commit
ERROR: foo.c is locked by "Karl Fogel <kf...@collab.net>"
[ that error msg comes rom the pre-commit script; we do have an issue about
returning the error text, but take it as a hypothetical error msg ]
Note that you could perform some lock operations interactively in your web
browser via the CGI script.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Issue 533] New - implement reserved checkouts
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Peter Davis <pe...@pdavis.cx> writes:
> It would be my first attempt at hacking Subversion, and really I've lost
> fluency in C over the past couple years, but I could give it a shot. No
> promises on what my schedule will be, though.
>
> Any tips on how to get started (besides the obligatory "Read the
> HACKING file" :->)?
That's pretty much it. If you have a question not answered in the
HACKING file, just ask here...
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Issue 533] New - implement reserved checkouts
Posted by Peter Davis <pe...@pdavis.cx>.
On Thursday 01 August 2002 12:03, Karl Fogel wrote:
> Peter Davis <pe...@pdavis.cx> writes:
> > I really like this. I'm what one of the other comments would call an
> > "early adopter", and I generally believe that locking is Evil. But this
> > would be really attractive, for all the reasons you describe.
> >
> > I don't think it goes against Subversion theory, since it's just a
> > property that can be removed. It's useful because it lets you easily see
> > who the locker is.
> >
> > Hopefully this can make it past the "idea" stage; if not for me or for
> > the beauty of it, then do it for the poor helpless minions whose project
> > managers won't switch until they see VSS-style locking.
>
> Glad you like it! Would you want to accept the issue and start a
> patch?
>
> -K
It would be my first attempt at hacking Subversion, and really I've lost
fluency in C over the past couple years, but I could give it a shot. No
promises on what my schedule will be, though.
Any tips on how to get started (besides the obligatory "Read the HACKING file"
:->)?
--
Peter Davis
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Issue 533] New - implement reserved checkouts
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Peter Davis <pe...@pdavis.cx> writes:
> I really like this. I'm what one of the other comments would call an "early
> adopter", and I generally believe that locking is Evil. But this would be
> really attractive, for all the reasons you describe.
>
> I don't think it goes against Subversion theory, since it's just a property
> that can be removed. It's useful because it lets you easily see who the
> locker is.
>
> Hopefully this can make it past the "idea" stage; if not for me or for the
> beauty of it, then do it for the poor helpless minions whose project
> managers won't switch until they see VSS-style locking.
Glad you like it! Would you want to accept the issue and start a
patch?
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org