We have an Enterprise Java project with roughly 500,000-lines of code. It goes without saying that such a project needs good version control. But what should such a project use?
Subversion has worked for us up until now on the project, but it is falling short of meeting our process and productivity needs. Without effective merging, branches won’t be used no matter how cheap they are to create. The only Subversion branches we have ever created have rarely stayed in sync with upstream and always led to dramatic merging ceremonies, worries about regression and code loss. To make a long story short, Subversion supports parallel development, but makes it so difficult to use effectively that you are better off avoiding it altogether.
Git handles our roughly 500,000-line Enterprise Java code base with ease. It is faster for one developer to git svn clone and then have his peers git clone than it is for each developer to checkout simultaneously from Subversion. Once done it gives every developer on the team offline access to the entire project history. The offline access allows developers to do complex historical comparisons that would be slow enough in Subversion to discourage developers from doing them. Git not only makes certain reporting operations fast, it makes them practical and productive to use.
In terms of support for multi-tasking, I am up to four features in my single Eclipse project now and none of them interact or interfere. Git lets me cast them aside to fix a critical issue and then resume where I left off. There is nothing quite like seeing a single view of a code base of this size converted within seconds from one large feature to another simply by switching branches.
It certainly also helps that Git works solidly on Windows as well. I found that I had to configure msysgit to leave line endings as they are rather than converting them to avoid problems with our legacy code base. Other than that the defaults are solid and Git makes it easy to integrate tools like KDiff3 for Windows to allow graphical merging and diffing.
What do we get by switching to Git? Developers get to fearlessly develop features and fixes with its first-class support for branching and merging. QA and Product Management gain interactive control of the release by actually being in the path to committing developer changes to the released code repository. All in all Git is a win for people process over technology. Git is an SCM for companies that value putting people in the driver’s seat of the release process.
7 comments:
How about server side windows support, is this plausible? I'm trying to convince my employer to switch but having trouble getting real world information on git server side. I know the concept of "server side git" isn't exactly right for what git really is, but what I mean by this is the canonical source of truth for the given codebase.
In windows do you just setup an ssh server within cygwin to handle this? Are there other ways? etc?
Did you have any other issues at all with windows client side for git aside from line endings? that sounds really good if that's the case.
Thanks very much for the report.
Have you looked at wandisco.com as a solution? The company I work for uses their software and it's been very stable.
Word.
It was about time you crazy enterprise cats caught up with the rest of us.
@Eric Bennett:
For a Windows the developer sets up Nginx and use set up the post-commit hook to run git update-server-info. We do a git clone --bare of the Git repository into Nginx's HTML dir (ex. nginx-x.x.x\html\product.git). When the developer is ready to publish the changes they do a simple git push and they are done.
If you want something more advanced with authentication and external push try out Gitosis or Gitorius on your server. IMHO, in practical cost terms Github hosting is better and would require less training.
Ahh, he thinks 500k LOC is a large code base! Isn't he cute? Such a precocious lad!
@Eric Bennett:
Scott Chacon's Pro Git has very clear directions for setting up an HTTP Git repository:
http://progit.org/book/ch4-5.html
Post a Comment