Version control of Oracle Stored Objects.

[Lig]

We have an implementation of Oracle 9i database. We have a team of 20
developers working on a project. We use PL/SQL DEVELOPER and Visual
Source Safe to cotrol the source.

The problem we have at the moment is one of version control.For the
moment, 2 developers can edit and compile a package.Because the package
is compiled on the DB Server,It is possible that a source being edited
by a developer could be overwritten by another.There is nothing in
PL/SQL that forces a user to check out and edit. We have Visual Source
safe fully integrated into PL/SQL Developer.But that's only as much as
it gets.VSS is not ORacle aware.
Are there any products out there that can be used for Version
controlling Oracle Stored Objects that are Oracle Aware?

Is there a better way of doing this?

TIA
Lig

Pl reply to
lignite AT iol DOT ie

[Frank van Bortel]

Lig wrote:

We have an implementation of Oracle 9i database. We have a team of 20
developers working on a project. We use PL/SQL DEVELOPER and Visual
Source Safe to cotrol the source.

The problem we have at the moment is one of version control.For the
moment, 2 developers can edit and compile a package.Because the package
is compiled on the DB Server,It is possible that a source being edited
by a developer could be overwritten by another.There is nothing in
PL/SQL that forces a user to check out and edit. We have Visual Source
safe fully integrated into PL/SQL Developer.But that's only as much as
it gets.VSS is not ORacle aware.
Are there any products out there that can be used for Version
controlling Oracle Stored Objects that are Oracle Aware?

Is there a better way of doing this?

TIA
Lig

Pl reply to
lignite AT iol DOT ie

install the CVS interface in PL/SQL Developer:
http://www.allroundautomations.nl/plsvcs.html

--
Regards,
Frank van Bortel

[Frank van Bortel]

Frank van Bortel wrote:

Lig wrote:

We have an implementation of Oracle 9i database. We have a team of 20
developers working on a project. We use PL/SQL DEVELOPER and Visual
Source Safe to cotrol the source.

The problem we have at the moment is one of version control.For the
moment, 2 developers can edit and compile a package.Because the
package is compiled on the DB Server,It is possible that a source
being edited by a developer could be overwritten by another.There is
nothing in PL/SQL that forces a user to check out and edit. We have
Visual Source safe fully integrated into PL/SQL Developer.But that's
only as much as it gets.VSS is not ORacle aware.
Are there any products out there that can be used for Version
controlling Oracle Stored Objects that are Oracle Aware?

Is there a better way of doing this?

TIA
Lig

Pl reply to
lignite AT iol DOT ie

install the CVS interface in PL/SQL Developer:
http://www.allroundautomations.nl/plsvcs.html

Just realize you (probably) have that (fully integrated...)

There will always be ways to go around it - you can still
use SQL*Plus, or whatever to make changes.

The only way is to let your developers know you are serious
about source safe. Threaten to fire them if not used, surprise
them with a clean database on a Monday morning, whatever it takes.
--
Regards,
Frank van Bortel

[Andy]

Frank van Bortel <fv********@net scape.net> wrote in message news:<d0******* ***@news5.zwoll 1.ov.home.nl>.. .

Lig wrote:

We have an implementation of Oracle 9i database. We have a team of 20
developers working on a project. We use PL/SQL DEVELOPER and Visual
Source Safe to cotrol the source.

The problem we have at the moment is one of version control.For the
moment, 2 developers can edit and compile a package.Because the package
is compiled on the DB Server,It is possible that a source being edited
by a developer could be overwritten by another.There is nothing in
PL/SQL that forces a user to check out and edit. We have Visual Source
safe fully integrated into PL/SQL Developer.But that's only as much as
it gets.VSS is not ORacle aware.
Are there any products out there that can be used for Version
controlling Oracle Stored Objects that are Oracle Aware?

Is there a better way of doing this?

TIA
Lig

Pl reply to
lignite AT iol DOT ie

install the CVS interface in PL/SQL Developer:
http://www.allroundautomations.nl/plsvcs.html

How can 2 developers edit a package when VSS is (supposedly) being
used? This sounds like developers not using source control properly
and editing PL/SQL on the fly. Prehaps you should get your DBA to
revoke the CREATE PACKAGE/FUNCTION/PROCEDURE privilige from the
developers and only let your DBA perform releases to the appropriate
environments

Andy

[Lig]

Andy :

- VSS Integration only has copy locally; The compilation of the code
takes place on the Server.

- Developers can check in and check out code.But f they dont do it,who
am I to blame for incorrect code creeping in?

Instead , if I can force them to use VersionControl, then I can audit
changes.

Imagine a situation where I checkout a package and start to edit it. In
the process, if the package on the server is changed, I try to get the
version again from the server, will this version not be newer to the one
I have?

Correct me if I am wrong.Am I missing something here ?

Cheers
Lig

[fitzjarrell]

Lig wrote:

Andy :

- VSS Integration only has copy locally; The compilation of the code takes place on the Server.

- Developers can check in and check out code.But f they dont do it,who am I to blame for incorrect code creeping in?

Instead , if I can force them to use VersionControl, then I can audit
changes.

Imagine a situation where I checkout a package and start to edit it. In the process, if the package on the server is changed, I try to get the version again from the server, will this version not be newer to the one I have?

Correct me if I am wrong.Am I missing something here ?

Cheers
Lig

It has been my understanding that Visual Source Safe should disallow
more than one copy of a file to be checked out, local copy or not.
That being the case how on earth do you end up with two or more
editable copies of a file?

I'd investigate why this occurs and put a stop to it at once, by
ensuring all developers use VSS as it's intended. Several good
suggestions to ensure compliance have been given you; use any or all of
them to help fix this mess.
David Fitzjarrell

[Frank van Bortel]

Andy wrote:

Frank van Bortel <fv********@net scape.net> wrote in message news:<d0******* ***@news5.zwoll 1.ov.home.nl>.. .

Lig wrote:

We have an implementation of Oracle 9i database. We have a team of 20
developers working on a project. We use PL/SQL DEVELOPER and Visual
Source Safe to cotrol the source.

The problem we have at the moment is one of version control.For the
moment, 2 developers can edit and compile a package.Because the package
is compiled on the DB Server,It is possible that a source being edited
by a developer could be overwritten by another.There is nothing in
PL/SQL that forces a user to check out and edit. We have Visual Source
safe fully integrated into PL/SQL Developer.But that's only as much as
it gets.VSS is not ORacle aware.
Are there any products out there that can be used for Version
controllin g Oracle Stored Objects that are Oracle Aware?

Is there a better way of doing this?

TIA
Lig

Pl reply to
lignite AT iol DOT ie

install the CVS interface in PL/SQL Developer:
http://www.allroundautomations.nl/plsvcs.html

How can 2 developers edit a package when VSS is (supposedly) being
used? This sounds like developers not using source control properly
and editing PL/SQL on the fly. Prehaps you should get your DBA to
revoke the CREATE PACKAGE/FUNCTION/PROCEDURE privilige from the
developers and only let your DBA perform releases to the appropriate
environments

Andy

Well, when it is *not* used...
The dilemma is how to enforce that it *is* used; there
are numerous options to change the code, without using VSS,
thus compromising the project.
But surprising the developers with an empty database
does help, occasionally :)
"Hey, just restore from VSS <g>".
--
Regards,
Frank van Bortel

[bdbafh]

this post does not directly answer your question, but I think that its
worth considering.

In addition to whatever source control your developers use ... a
bastard dba from hell would log all changes to all source for each of
the app_owner schemas via database triggers. This would not log
developer's changes to code in their own schemas - only those applied
to the app_owner schemas in development.

You could do the same thing in your qa and prod dbs, but you don't
allow developers to make changes to the packages there directly ... do
you? They're not supposed to ... until that urgent issue or emergency
comes along and policies get tossed.

Log the source changes and you'll have both an audit trail (nice for
SarbOx) and the source to restore without having to go to dump files,
etc.

setup a specific account for this, give it its own tablespace, prevent
DML upon the logging table by other users.

-bdbafh

[DA Morgan]

bd****@gmail.co m wrote:

this post does not directly answer your question, but I think that its
worth considering.

In addition to whatever source control your developers use ... a
bastard dba from hell would log all changes to all source for each of
the app_owner schemas via database triggers. This would not log
developer's changes to code in their own schemas - only those applied
to the app_owner schemas in development.

You could do the same thing in your qa and prod dbs, but you don't
allow developers to make changes to the packages there directly ... do
you? They're not supposed to ... until that urgent issue or emergency
comes along and policies get tossed.

Log the source changes and you'll have both an audit trail (nice for
SarbOx) and the source to restore without having to go to dump files,
etc.

setup a specific account for this, give it its own tablespace, prevent
DML upon the logging table by other users.

-bdbafh

The real BDFH builds a DDL trigger that raises an exception with all DDL
on the database and another that audits it. He/she then disables the
first trigger whenever making changes leaving the second one to create
the audit trail.

--
Daniel A. Morgan
University of Washington
da******@x.wash ington.edu
(replace 'x' with 'u' to respond)

[IANAL_VISTA]

DA Morgan <da******@x.was hington.edu> wrote in
news:1110065133 .857196@yasure:

The real BDFH builds a DDL trigger that raises an exception with all DDL
on the database and another that audits it. He/she then disables the
first trigger whenever making changes leaving the second one to create
the audit trail.

Alternatively, just nightly extract the current production code from the
repository and install it into the database. Any and all ad hoc, on the
fly or unapproved changes just get summarily overwritten.