Code Migration by using tags (CVS)-Part_I-Help

[Ravi]

I have been asked to be the buildmaster for my group and have been 
spending the past week learning CVS and reading various message boards. 
Our old source control system was VSS and we recently migrated to CVS 
for our new projects . I need to put together a proposal for a code 
migration process. It seems that CVS is a barebones version control 
system and customizations will need to be made to enforce the 
requirements that I will be proposing. Any help provided by forum 
members will be deeply appreciated.  This forum has been a tremendous 
help to me in learning all the nuances of CVS.


My old team had only 3 developers.  There will be approximately 30 
developers across two development teams submitting code on this project 
and they will be located in Asia, Europe and the USA. There will be two 
separate CVS repositories.  One repository will be used by the core 
infrastructure team and the other will be by a set of business 
developers

How do we migrate code from development to QA?  
We will be segmenting the codebase into modules by using the CVS module 
admin file.  We have a configuration management system that developers 
will submit build request for QA builds.

Sample CVS structure

Project
        source
                A-subdir 
                B-subdir
                C-subdir
                D-subdir
                E-subdir
                etc...

A-subdir will be a module defined in the modules file, B-subdir will 
also be defined and so on....

1. The developers will mark the revisions they want to be built with a 
unique tag based on Username_date_time.  The developers will be tagging 
a module defined in the modules file and not tagging per file.  Since 
this is a new project there will be lots of changes across the entire 
repository tree. I wanted to use a single tag called NEW_REVISIONS and 
the developers would move their required changes for the QA build to 
this tag.  However, if someone tagged an entire directory root 
accidentally, how would you back out his changes.  Also, if they are a 
dozen individuals submitting changes for a QA build how would they 
determine their changeset for the build.  How would I be able to back 
out one developers set of changes if we don't use unique tags?  I 
couldn't answer that question when confronted by the developers.

2. The buildmaster will query the configuration management system and 
grab the list of tags that need to be built for QA.
3. The buildmaster will checkout the last successful QA build and apply 
the list of submitted tags to QA_LAST and create a new tag called 
QA_BuildNumber (Is it possible to do this with rtag instead of checking 
out everything into a sandbox and than tagging QA_BuildNumber).  What's 
the best way to generate a unique build number? How do I deal with 
files that are removed by developers from within their module?  Since I 
am overlaying the list of tags submitted with the last successful QA 
build, would I have to remove files manually?

The reason why I have to overlay the last QA build with the new 
revisions being submitted is because I need to be able to do an end to 
end QA build with every release.

4. After a successful build I would take the QA_BuildNumber tag and 
move it to the QA_CURRENT tag.

5. I need to generate a changelog between the QA_CURRENT and QA_LAST.  
Essentially a delta between the last QA and current QA.  Are there any 
sample scripts available for this?  It would be nice producing a report 
with the changeset by developer.  This would be extremely useful for 
our nightly builds as well.  

6. I need to ensure that only the buildmaster can tag a QA build or 
move QA_CURRENT tag.  Is this possible by using the taginfo hook 
provided by CVS?

7. Tomorrow, I will start trying to workout RELEASE tags and how to 
deal with branching and merging. I have to have this proposal done by 
Friday evening. Ugggh.