Based on attempts to move from a similar humongous tree of code in
SourceSafe to git here are my personal lessons: (this are my own
notes, so i did not type this just for you)
1. Divide and conquer. - this pertains to the problem, not the code.
You problems are actually separate issues:
a) How do you control what gets deployed (following review by
designated person) is somewhat agnostic to your code organization once
you get to git. Leave changed to this steps for last.
b) What version control tool you use.
c) How you organize the source tree.
d) How do you move devs and processes to the new structure.
Here is what worked:
Train, Parallel, Optimize.
1. Before you leave CVS, make sure ALL affected personnel is
intimately familiar with git workflow specifically as it applies to
your production code manipulation by:
a) Do NOT switch to GIT. Use CVS and git concurrently by: Dev checks
pulls and pushes to/from centralized CVS. On their hard drive the
checked out folder structure is ONE and the same git repo (set ignore
in git on all the CVS support stuff). CVS should NOT know about GIT.
Trying to import all micro-level commits from GIT will muddy the
water, process. Just large, occasional, stable diffs go up CVS.
b) Cultivate the culture of local micro-revisions and branching,
global clean commits At this stage, code is pushed vertically to CVS
and laterally between devs by git format patches (in cases of
shared branches) and plain patches.
c) (At this stage) Don't break up the CVS structure into submodules
or do anything that removes the parallel between the two.
d) Don't try to make devs to push to centralized Git repo. Because
of constant rebasing and history rewriting will not work. If devs
don't do constant local rebasing, history rewriting, they are not
using GIT well. Lack of centralized GIT structure allows devs freedom
to learn GIT most efficiently.
c) CVS is still you main, one and central repo. In case of fire, this
is what you save and this is where you make all devs commit (albeit
less regularly).
Once you have a core of devs happy and familiar with micro revisions
and branching and start to beg for centralized, formalized GIT repo,
make sure that FIRST these champions of GIT work with others to get
them on happy local micro-revisions board.
Once everyone is ready undo my 1.d. rule (no centralized mainline
Git repo) and make the devs maintain absolute parity (in code, not
commits) between (still main) CVS and (convenience) GIT central,
mainline repos.
IMPORTANT NOTE: This is where your future Git repo starts. Start it
right by importing CVS history into clean Git repo and making that
wild public Git mirror of CVS. If devs mess up this wild public
Git repo, you can always toss it restart this again and again by
importing CVS history. However, if wild public Git repo has settled
already, it's unsightly to rebase git history on top of new CVS
import, as all hashes change.
By this time, you will see that CVS is committed to, maybe, once in
2-3 days. Most of the group projects exchange format patches for
group mainline branches in git. Most of the stupid commits will
stay in local repos and your CVS will be in manageable state of
somewhat stable. You will have A LOT of parallel efficiency gains by
this time as semaphoring the code changes will not be a chore.
2. Change processes. Break down the chains.
At this stable point, start changing your control process. Work out
for yourself how you keep track of two - the only two - important
things: what's in production right now and where can I see the
latest state of all dev's 'semi-stable' work
Again, divide the problem into smaller issues.
I suggest to branch off this is in production now into a separate
public GIT repo shared between people trusting each other to deploy
production. It's the same 'tree' structure as the the one in (by now
wild) CVS, mirroring dev Git repos. The flow of code goes ONLY ONE
WAY: wild CVS/Git this is in production now Git. However, it
allows deployment team to forget about commit parity, importing, and
instead work on large, tested elsewhere patch levels.
Do NOT EVER change code directly in this is in production now repo,
even compile. ALL code changes to go CVS (percolate to Dev Git) and
cycle back to this is in production repo as gargantuan patches, or,
if deployment people are up to this, do a public clone of of wild
Git repo and constantly do only pulls/merges at critical times, of
specific commit / branches in wild Git.
The reason you would not care about commit-level partity and tracking
for this is in produciton right now repo is that you will throw it
away once the wild Git repo becomes main and you move the this is
in production now branch there.
Once you gain procedural structure and control over the this is where
most recent, semistable work is and this is in production right now
Git workflow...
3. Finally, move to Git. Reapply the chains.
At any point before here, you can revert back to CVS. It has your
