Re: [TCLUG-DEVEL:270] CVS questions

["John R. Sheets" <dusk@ravendusk.org>]

On Jun 20, 2000, Bill Gladen <nobody170@yahoo.com> wrote:
> 
> --- "John R. Sheets" <dusk@ravendusk.org> wrote:
> </snip> 
> > What do you want to do version tracking on?  Source code or
> > distributed
> > binaries?  If you want to make the checks during compile-time, then
> 
> Source code and non-distributed binaries.

CVS is good at tracking versions of source code, so yes, you should
definitely look into using CVS.

> We have a bunch of java servlet apps.
> 
> Some of the classes and packages are architectural, and used by a
> number of other classes and packages.  (DB connection pooling, html
> generation, etc.)  They are generally well packaged, but crufty.
> 
> Some of the classes are not as architectural, but are used by multiple
> apps.  We're working on packaging them better.

Automake has some basic support for Java (not sure how much, or what the
future will look like).  That might help with your packaging problems.
Automake does quite a bit of makefile magic; in a nutshell, you maintain
a simplified template, which automake expands into a fleshed out
makefile.

> As things change, some of the newer apps need more/different services
> from the base layers.  Sometimes the changes break older apps that are
> still running and necessary.
> 
> Currently, the management of this environment is done via spaghetti
> classpaths, and cruft creation.
> 
> We need to be able to set up the architectural packages with multiple
> versions, so that we can link the correct versions of the various
> packages in when we are compiling the apps.  

It sounds like CVS will help you.  You can tag versions of the source
tree and retrieve it as a snapshot later on.  CVS also has good support
for branches and maintaining (and merging) those branches.  With some
careful tagging, you can set things up so that you can check out an
entire self-consistent snapshot of code, from the same tag, e.g., 

  cvs checkout -r VERSION_1_3 projectname

You can then import later versions on top of that one and tag them,
e.g. as VERSION_1_4, and just check out whichever version you need into
a fresh directory.  Thus, you might have the checked-out version 1.3
tree sitting in its entirety next to the version 1.4 tree.  It might
take a bit of trial and error to get the importing and tagging process
down, but it'll be worth it, IMHO.

Then later, if you find a bug in 1.3, you just create a branch at the
VERSION_1_3 tag point and start committing changes to that, without
affecting the mainline trunk or any of the other versions.

(I apologize if I'm repeating things you already know.)

> Also, we need better access to the versioned source of the packages, so
> we can debug the production/test/demo version without trying to roll
> back the development to the time when it was compiled.

With CVS, you check out a fresh tree for each different snapshot, even
though they correspond to different states of a single repository.

Coriolis has an excellent book on CVS.  I recommend you give it a read.
And feel free to ask more questions here.

John

-- 
dusk@ravendusk.org                            http://www.gnome.org
jsheets@codeweavers.com                  http://www.worldforge.org
               http://advogato.org/person/jsheets