Re: pl/sql code maintenance

Karsten Farrell wrote:
>
> "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).

Not having worked with CVS I will have to take your word for this. Inother environments (e.g., Clearcase) labels are easier. You create different views of the code and build/develop from there.

>
> 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.

And my suggestion is to put some of this in the code. In PL/SQL packages, simply include a WHOAMI() function that returns the version string value. That way a simple
 SELECT package.whoami FROM DUAL;
tells you exactly what version got compiled in Production.
>
> > 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

Tim,
Any help we can provide, let us know.
Ed

--
Ed Prochak
Magic Interface, Ltd.
440-498-3700(office)
Computer consulting, database and web services.