Re: pl/sql code maintenance

"Tim X" <timx_at_spamto.devnul.com> wrote in message news:87r8c2mtt7.fsf_at_tiger.rapttech.com.au...
> Ed Prochak <ed.prochak_at_magicinterface.com> writes:
>
> > Tim X wrote:
> > >
>
> > So if you want to avoid complicated processes, why three branches? Does
> > CVS not support some form of version labels? Development usually works
> > on the latest code or checked out copies, QA works on versions labeled
> > for a particular test release, and code promoted to production is
> > labelled as such first. If you can't use labels, then a tracking table
> > of source files and release versions that can be used to extract those
> > versions of the code is easy enough.
> >
>
> I tend to agree. The 3 branch solution was not my preferred approach,
> but rather one proposed by another developer who had used a similar
> setup with his previous employer.
>

Unfortunately, branches are the easiest way to separate development, qa, and production. Labels let you back off to a previous "build" or something like that; it's really not easy to use labels to separate code into dev, qa, prod. With branches, I just have to have a separate directory on my PC for each branch. For example, we've added an additional branch so that our prod branch is split into a deploy branch (the real prod, if you will) and a quick-fix branch (immediate work-stoppage bug fixes).

There are add-ons to CVS that make things a little easier to handle. For those who like a GUI front-end, there's WinCVS. Some of the people at my work (I'm not included) use a web-based front-end that makes branches really simple. The main thing that makes CVS difficult is that its focus is just the opposite of products like MS VSS. VSS is repository-centric (you check out / check in code) whereas CVS is developer-centric (you just start editing code in your personal directory and then commit - and perhaps resolve - differences when you're done).

> > Does CVS have any way to have embedded version ID's in the code itself?
> > (SCCS does this.) this is helpful in PL/SQL packages (and compiled
> > executables) to include a revision ID routine which returns the package
> > ID (name) and revision number.
> >

What we do is supply comments in the code that CVS recognizes and replaces with the current version. For example each of my pl/sql programs start with something like (can't remember exactly since I'm not at work at the moment to look):

• $Source: $
• $Version: $
• $Date: $
• $Author: $

CVS will replace these labels with version info whenever you get the latest from the repository.

> I have a tough road ahead trying to change the habits of the last 7
> years, but a good challenge always makes work more interesting and the
> days/years go faster!
>
> Tim
Received on Sat Dec 28 2002 - 10:24:32 CST