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 !
Fred
On Apr 4, 10:21 pm, Daniel <dvdotse...@gmail.com> 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:
>
> http://nvie.com/posts/a-successful-git-branching-model/
>
> 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:https://github.com/dvdotsenko/ges).
> 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 <frederic.jec...@gmail.com> 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 git-users@googlegroups.com.
To unsubscribe from this group, send email to
git-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/git-users?hl=en.
