Best Approach For Revision Ctl given my requirements????

[marc christensen]

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?