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********@netscape.net> wrote in message news:<d0**********@news5.zwoll1.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********@netscape.net> wrote in message news:<d0**********@news5.zwoll1.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

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.com 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.washington.edu
(replace 'x' with 'u' to respond)

[IANAL_VISTA]

DA Morgan <da******@x.washington.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.

[DA Morgan]

IANAL_VISTA wrote:

DA Morgan <da******@x.washington.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.

And you do this with users connected? ;-)

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

[Ed Prochak]

Who change the package on the server? If it wasn't you then someone is
not using source control.

You are missing a development process. Well, no actually, you have an
ADHOC development process. Having VSS or CVS, doesn't do you a bit of
good if developers don't use it. As others point out, until ALL your
developers agree to never edit code unless they have it checked out,
then you have merely the illusion of code control.
You have a choice: continue as a team of cowboy coders,
or change to work as a team of software engineers.

Good luck. You are going to need it.
Ed

[Galen Boyer]

On Fri, 04 Mar 2005, li*****@iol.ie 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?

Yes, give each developer his own schema and have him deploy the code
from source control to that schema. When he is done fixing his code, he
checks in. Then, only deploy code to QA, Staging, IDE's and Production
from Source Control.

--
Galen deForest Boyer

[glimmertwinfan]

Yes, give each developer his own schema and have him deploy the code
from source control to that schema. When he is done fixing his code, he checks in. Then, only deploy code to QA, Staging, IDE's and Production from Source Control.

--
Galen deForest Boyer

That's exactly how we do it and it works great.