Lately Git is really the latest "Cool" SCM, a lot of its appeal is coming from GitHub. I like a lot the features that GitHub is providing on top of git. The other day I was hearing a colleague mentioning: "Isn't that ironic for a decentralized scm to take off once you start centralizing projects on GitHub?".
While this is certainly amusing, this is not exactly true, github is nothing like a centralized place, I see it has a rally point (especially for opensource stuff), a convenient hub from where you can share stuff, but thanks to git, it's in no way an obligatory gateway to the code. You can clone / mirror all the stuff from github in a snap, painlessly.
Back to subversion... This is what we use at Six Apart, internally but also externally (for the numerous opensource repository we maintain), and on daily basis I find it painful especially when you compare to git.
Part of the pain comes from merging and branching (some of the pain apparently could go away with the latest subversion I heard), and this pain is amplified by the fact that we have tons of svn:externals So MAKING a release at Six Apart, is not easy (Would you believe me If I told you that tectonic was involved in that process? (no, not tectonik, at least not yet))... I'm still unclear how we would replace, or better, work with a subversion repository with that many externals.
So these difficulties set aside, I was wondering how other big software shops are dealing with such transition or how they have changed (improved) their release management using git?
Another pain right now is that our dedicated QA team is dependent on engineers to do merges and don't really own the release. With git I was musing that ideally QA people would be actually signing off a release by actually branching and tagging in their "Golden QA repo". I kind of like the idea that QA would pull from engineering repository, merging all of the different feature/bug branches that they want to see in a release.
Conceptually, their work should consist in, pull from one bug-branch from one engineer, build, verify. If it's not good communicate the problems to the engineer, and if it's good merge in the "signed-off repo".
In realily I don't know if its doable. Anyone knows a big software shop working with Git, what are the obstacles, best practices?
