Thomas, Daniel,

Thanks a lot for sharing your experiences, this will help me a lot.
I'll share my own experiences back to this list once the big work
done !


On Apr 4, 10:21 pm, Daniel <> wrote:
> 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
> latest code, full history, just committed with larger, more stable
> chunks. CVS is still the one, only, mandatory and main repo for
> "latest" code. I'd say forget about "branches" in CVS by now. Just
> pile up milestones in there from "wild" Git. If you still think Git is
> worthy, read this:
> This is one of the best SHORT write ups on organization in Git, but
> the guy is wrong in 2 places:
> - Wherever he says "develop branch" you read "master branch"
> - Wherever he says "master branch" you read "'this is in production'
> branch"
> Short for this two mental lapses on his part, the writer is right on
> the money.
> This is your time to shine as a leader. You need to press structure
> similar to that one in the article into "wild" Git repo. Make the
> "deployment" people involved and ask them to help maintain "this is in
> production right now" branch in "wild" git. They can still ship
> patches to their sheltered baby from which they actually deploy, but
> they must maintain the branch in "wild" repo, cycling the commits per
> mentioned article. Once "sort of done" (cause you are never done)
> pressing the structure into "wild" make "wild" public Git repo main,
> one, only, mandatory repo. CVS is now, optional, backup, whatever....
> 4. Move "deployment" team into "wild" public Git repo.
> Instead of moving patches to "this is in produciton right now" repo,
> make them do it off "wild" public Git repo's "this is in production
> right now" branch.
> 5. Maybe, just maybe, you will reorganize the tree.
> This is where you contemplate submodules.
> Submodules are separate repos. Instead of "one repo, multiple
> branches", you will multiple repos, multiple branches, dependency
> rules, build system alterations to accommodate that, a special repo
> management system (selfish plug:
> Postpone it.
> People think "my libraries are changed separately" and "i can maintain
> my top-level apps seprately from libs", hence "i am ready for Git
> submodules" That first part is often wrong. Postpone all contemplation
> of submodules until later as that is a pain of a complication in
> process. Moving to Git alone is good enough.
> Daniel.
> On Apr 2, 12:55 pm, FredJ <> wrote:
> > Hi,
> > I'm looking to replace my team's old and clumsy CVS server, as a GIT
> > user for personal projects I'm wondering what would be the best way to
> > achieve this using GIT. I've googled the subject a few times and read
> > books but I still have a handfull of questions
> > Our team is composed of 10 developers.
> > A common developer workspace takes about 1Go of space and contains
> > about 50 modules (up to 100 if the developer is working on satellite
> > applications/modules) - we're maintaining a large java-based
> > healthcare system.
> > Each module is a CVS project.
> > Our use of CVS is.. well..clumsy too (don't ask me why we do things
> > like this, those were decided about 10 years ago before I started
> > working in this company).
> > Features to be delivered in the next release are committed directly on
> > the head.
> > The project leader cherry picks the commits on his local working copy
> > within a dedicated workspace.
> > I first thought of creating a single project in order to group the
> > 100+ modules and to ease the creation of maintenance branches.
> > Each developer would clone the full workspace from a "blessed"
> > repository.
> > The "blessed" repository would be managed by the project leader which
> > would simply pull changes from each developer pubic repository.
> > I tested this scenario but, as the workspace is really big, each
> > operation is really slow.
> > What could I do then ?
> > - Use submodules ?
> > - Create a blessed per-project repository and instead of a public
> > repository for each developer create a per-project public and shared
> > repository ?
> > ...I'm a bit lost
> > Thanks for your help
> > Fred

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To post to this group, send email to
To unsubscribe from this group, send email to
For more options, visit this group at

Reply via email to