[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: How to get "edit -c" working
From: |
Eric Siegerman |
Subject: |
Re: How to get "edit -c" working |
Date: |
Fri, 2 Mar 2001 22:21:05 -0500 |
User-agent: |
Mutt/1.2.5i |
On Fri, Mar 02, 2001 at 10:54:59AM -0800, Chris Chambers wrote:
> The DB developers have fancy tools to allow them to edit, run, and debug
> their code directly in the (single, shared) database. But no tools to keep
> versions of the code. They need to keep using those fancy tools.
>
> But when one person is fancily editing the code directly in the DB, we want
> to have a portion of the development process inform others that they're not
> allowed to edit that piece of code. I had been thinking, export all the DB
> code as text, and use exclusive locking.
If locking's the crucial part, and you're willing to dispense
with versioning (which I wouldn't be, but your situation -- aka
desperation level -- may be different), you could implement the
lock as a table in the database that's being worked on. (You'll
end up with a small bit of the schema that has nothing to do with
the application itself, but it shouldn't be too intrusive -- a
single table is all this should take.)
Presumably the "fancy tools" are fancy enough to have
user-definable triggers; so make them:
- check and set the lock
- do the editing/installing/testing
- unlock
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont. address@hidden
| | /
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea.
- RFC 1925 (quoting an unnamed source)