|
From: | marc christensen |
Subject: | Best Approach For Revision Ctl given my requirements???? |
Date: | Tue, 23 Dec 2003 12:22:46 -0700 |
I need to fix our current change management
"system".
First an overview.
The systems are Windows 2000 based.
I need to manage changes in an Oracle Forms
/ Reports development system.
The "Source" for oracle forms and reports are for
all intents and purposes a binary file and "merging" changes is not
really an option.
I'm currently using PVCS version
manager.
The system is in production with daily fixes and
tweaks and has several larger revisions in the works as well.
Our development methodology is regulated (Yes as in
LEGALY) and based on written procedures.
They can be changed but it's expensive and
time-consuming.
We have a change/issue tracking system which will
interface with several Revision Ctl. Systems including PVCS and
CVS.
I have been able to get it to work with wincvs,
this allows a specific 'fix' to be associated with the files changes to
implement that fix.
Currently ALL code checkout/in is done by a single
gatekeeper.
This has become a major problem and something we
are looking to address. (see legal issues above).
We don't have enough PVCS Licenses to do this. The
pile of money required to get them will be a huge roadblock to fixing this
process
and switching to CVS will prevent
that.
In general, What I want to do is this:
(My wording may be funny, but I'm trying to avoid
terms which limit or define a specific approach, like Branch or Tag, I'm open to
any ideas at this point)
#1 Allow developers to check in/out from
a specific 'set' of code
#2 Prevent developers from checking code into
"Sets" of files classed as "In Test" "In Production"
#3 Allow a specific version say "foo-form 1.5" to
"Progress" thru development, testing, and into production phases using some sort
of tracking mechanism.
"State" from RCS appears
unused in the the CVS implementations I've seen.
#4 We currently "Lock" files when "Checked out"
That Lock is held until the code have passed all testing and implemented to
production.
This concept is counter to
and deprecated in CVS, but "Merging" changes at check-in is not really an
option.
I really need to warn
developers "Foo-Form 1.5" has not been approved for move to production, and MAY
get bit-bucketed. Building Version 1.6 based
on 1.5 may mean they will
have to go get 1.4 and start over if 1.5 ends up being rejected. Note, 1.5 may
have been checked in weeks ago, so rather
than physical contention
for the file it's more a logical contention for the changes themselves and the
fact they are being rolled into your new code.
"Removing" those changes
from your new changes is not an option. you will really need to get the previous
version start over with your modifications.
#5 we have both changes that must immediately go to
production and developemnt slated for the next release.
Those Immediate changes
must also be included in the "Next Release" code and I'd like a way to enforce
that rule.
Some of the tools or approaches I see as being
possible are: "Promotion Groups", Tagging, Branching, seperate CVS trees with
some sort of "move" mechanism.
An external database which tracks code states and
approvals and manipulates the CVS tree. I'm sure ther are
other options I'm missing.
I also can't help but think I'm reinventing the
wheel here, but no approach I've seen addresses all our issues.
The "Just Tag" each "Release" would become an
incredible pain in the butt, as we do dozens of changes per week.
This system does not follow the "Classic" build
process either. We change a single form and deploy it.
The production system as a whole contains hundreds
of them as given version at a specific point in time but
they are seldom rebuilt as a whole.
Ideas?
|
[Prev in Thread] | Current Thread | [Next in Thread] |