All,
We bought PL/SQL Developer for a fraction of TOADs price and love it so far! We use version 6.0.5.931 with the 1.2 version of the VCS plugin, and are using Jalini Igloo to connect to CVS. I have the project set-up and everything looks fine so far, but I wanted to request help in figuring out the usage pattern for the CVS plugin.
Our team of 5 developers shares a database development schema called "DEV" to do all db development. Previously, whenever a developer wanted to change a stored procedure etc, he would edit the source directly on the DEV instance using Developer, and at the same time send a "Database Change Request" to a person-in-charge saying "I have changed xyx.bdy's abc stored proc,please get it from DEV". This person would compile all such requests, get the proper versions of every package/body/individual procedure and then create a SQL script to create the Release Package that would be applied to the TEST and PROD database instances. As you can see, this is highly error-prone.
I am thinking of the following using the VCS Plugin:
1)Disable Version Control over source Objects, ask user to save changes to DB packages, and disable compilation of read-only source files. These three options will force every developer to get the latest version of the Stored Procedure he wants to edit ,make changes to it, recompile those and commit them to the database.
Is this how people on this board are using the VCS plugin. I feel it might get too retrictive and developers might ask for Version Control over Source Objects. If i enable this, how should my team go about using it.
I know its a long post, but will sincerely appreciate any help on this. Thanks!
vik,
We bought PL/SQL Developer for a fraction of TOADs price and love it so far! We use version 6.0.5.931 with the 1.2 version of the VCS plugin, and are using Jalini Igloo to connect to CVS. I have the project set-up and everything looks fine so far, but I wanted to request help in figuring out the usage pattern for the CVS plugin.
Our team of 5 developers shares a database development schema called "DEV" to do all db development. Previously, whenever a developer wanted to change a stored procedure etc, he would edit the source directly on the DEV instance using Developer, and at the same time send a "Database Change Request" to a person-in-charge saying "I have changed xyx.bdy's abc stored proc,please get it from DEV". This person would compile all such requests, get the proper versions of every package/body/individual procedure and then create a SQL script to create the Release Package that would be applied to the TEST and PROD database instances. As you can see, this is highly error-prone.
I am thinking of the following using the VCS Plugin:
1)Disable Version Control over source Objects, ask user to save changes to DB packages, and disable compilation of read-only source files. These three options will force every developer to get the latest version of the Stored Procedure he wants to edit ,make changes to it, recompile those and commit them to the database.
Is this how people on this board are using the VCS plugin. I feel it might get too retrictive and developers might ask for Version Control over Source Objects. If i enable this, how should my team go about using it.
I know its a long post, but will sincerely appreciate any help on this. Thanks!
vik,
