[git-users] Re: Git enterprise setup on a large project
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
[git-users] Re: Fwd: Available consultant's for your requirement.
And not a single Git consultant. Tsk, tsk! Akshay Korgaonkar wrote: -- Forwarded message -- From: Akshay Korgaonkar akshay.korgaon...@wisdominfotech.us Date: Wed, Apr 6, 2011 at 12:23 AM Subject: Available consultant's for your requirement. To: recruiter.aks...@gmail.com HI, Mentioned below are the list of candidates available for your requirement. Kindly let me know if you have any requirement for them. *Name* *Position* *Yrs of Exp* *Skills* *Availability* *Preferred location* Venkata Kallagunta Sr.JavaDev/Tech Lead 10 yrs Spring, MVC, Struts, Jsp, Jsf, OOAD, GoF, OOPS, Agile Immediately Anywhere in US Sujata Asokan SAS Developer 10 yrs SAS/BASE, SAS/FSP, SAS/STAT, SAS/GRAPH, SAS/AF, Macros May Bay Area, CA Nitin Jhanwar Sr Developer/ Embedded System Architect 9 yrs OMAP (medium proficiency), TMS320C54/55X(high proficiency). Visual Basic 6.0, Microsoft C/C++, Assembly, MATLAB, Simulink. Speech, Audio and Image Processing, Speech Recognition, Speaker Recognition, mp3 codec, ILBC codec, Architecture Design, Project planning and execution, Stability checking, Test Plans development. Multithreading, TCP/IP. Immediately Anywhere in US Sreerama Moorthi Java/J2ee Developer 6 yrs OOA,OOD, Jakarta Struts Framework, JavaServer Faces, Spring Framework, Spring MVC, Hibernate, IBM WebSphere, Oracle Weblogic, Apache HTTP April Anywhere in US Sheetal Zatakia Data Tester 12 yrs ASP, .Net, HTML, XML, MS-Office Suite, Java, Oracle PL/SQL, Toad, Edit Plus, Quick Test Pro, Quality Center Immediately L.A Vikram Guduru Business Analyst 7+ yrs RUP, MS Project, SQL Server 2005/2008, .Net (ASP C#), MS Office, Oracle, UNIX, HP (Mercury) Quality Control, Remedy, Lotus Notes. April L.A, Bay area, CA Prashanth Dandamundi QA / Test Lead 10+ yrs ad-hoc product testing, reporting bugs and reporting tester status, writing test scripts, test automation using diverse testing tools like HP LoadRunner, HP QuickTest Professional (QTP) 11.0/10.0/9.x, HP Quality Center (formerly Test Director 9/8/7.6), WinRunner. C, C# , Java, C++, ASP, Visual Basic, SQL, PL/SQL, JavaScript, VBScript, HTML, CSS, Rational Clearcase, TFS, VSS etc. SQL Server 2005/2000/7.0/6.5, Oracle 10g/9i/8i, Sybase, DB2, MS Access, MySQL, Windows 7, Vista, XP, Win 2003, NT, Win 2k Server, Unix, Linux, DOS, Immediately Anywhere in US Srinath Kamatam ETL / Informatica Developer 7+ yrs Power Center 8.6/8.1/7.1/6.2/5.1, INFORMATICA Power Mart 5.1, Mapping Designer, Server Manager and Repository Manager, Power Connect. CrystalReports10.0, Cognos 8.1/7 (Impromptu), Business Objects 3.1 XIR2*/* 6.5. Oracle 10g/9i/8i, SQL Server 2005/2000, DB2 UDB7.2, COBOL, SQL Loader, MS Access 97/2000 UNIX shell scripts, SQL, PL/SQL, Perl, C/C++, Dimensional modeling, Star schema, Snowflake schema, Kimball methodology, code pages, DBCS UNIX (IBM-AIX), Windows 2003/2000/98/95 Immediately Anywhere US Thanks Regard’s * * *Akshay Korgaonkar* Wisdom InfoTech Direct: 650-488-7828 *akshay.korgaon...@wisdominfotech.us* -- 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.
