RE: CVS best practice

[Jim.Hyslop]

Rick Genter wrote:
> The system I work on consists of a number components. Each 
> component is
> a separately built Java application, all referencing portions of a
> common database. Different components use different tables; 
> some tables
> are shared by many components, while some are used by a single
> component. Over the life of the system, schema changes on the 
> same table
> may have been required by different applications for 
> different purposes.
> 
> We script all of our database changes and store the scripts in our
> repository, but this has led to some "spirited" debate about 
> repository
> structure. Our DBA wants to have a database-centric 
> repository hierarchy
> where all database scripts are stored in a CVS module named for the
> database to which the script applies. There would be submodules for
> Tables, Stored Procedures, Indexes, etc. I, on the other hand, want
> scripts associated with a particular application to be stored in "SQL"
> or "Schema" submodule under the module for that application.
In this case, you can have your cake and eat it, too!

Follow the DBA's suggestion: create a completely independent CVS module that
contains all the schema scripts. This keeps all the scripts in one place,
and ensures that the schema is consistent. Whether you go to the extent of
having a subdirectory for Tables, another for Stored Procs, etc. is between
you and your DBA.

In each of the projects that uses the database, add an "ampersand module"
that points to the schema module to each project in CVSROOT/modules file
that needs it. See the documentation for more details:
https://www.cvshome.org/docs/manual/cvs-1.11.17/cvs_18.html#SEC159

End result: The DBA gets to see all the files in one location, and you get
to see the schema files with each project. If one project changes the
schema, the other projects automatically inherit it. Everyone goes home a
winner!

-- 
Jim Hyslop
Senior Software Designer
Leitch Technology International Inc. (http://www.leitch.com)
Columnist, C/C++ Users Journal (http://www.cuj.com/experts)