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" <gstein@lyra.org>
To: "Brian Behlendorf" <brian@collab.net>
Cc: <dev@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
Received on Fri Aug 2 03:11:58 2002