Ahh, I see the problem. You need some way to tell everyone that the database
stuff is being worked on. You're thinking of using CVS as the mechanism to do
so. I think I would use the "cvs edit -c" patch for this situation.
Noel
[EMAIL PROTECTED] on 2001.03.02 13:54:59
(see below)
[EMAIL
[EMAIL PROTECTED] on 2001.02.28 12:30:31
Some things can't be easily versioned under CVS. For example, PL/SQL or
other code that lives in the database. Since it's a shared resource, we need
to do exclusive locking to version it.
Is there a way to export/import these files as text? If so,
(see below)
[EMAIL PROTECTED] on 2001.02.28 12:30:31
Some things can't be easily versioned under CVS. For example, PL/SQL or
other code that lives in the database. Since it's a shared
resource, we need
to do exclusive locking to version it.
Is there a way to export/import these files as
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
Some things can't be easily versioned under CVS. For example, PL/SQL or
other code that lives in the database. Since it's a shared resource, we need
to do exclusive locking to version it.
My first thought was to use "cvs admin -l". That looked like it would work
well enough for our database
