Migration from StarTeam to distributed source control

Question

We're currently using StarTeam for our project, and the license is expiring soon. We're looking at moving to Team Foundation Server or something similar, but there's a push (mostly from myself and one other person) to move to some form of distributed version control. One of the problems is that our change manager wants to be able to track and release by change request (as in StarTeam), and I don't believe this can be easily done with Mercurial or Git out-of-the-box (please correct me if I'm wrong).

This is a 15+ year-old product with thousands of java files and PL/SQL packages, maintained by 5-6 development subteams with a total of 30-40 developers. To me, that seems like it would make a distributed repository a nightmare with the "commit early, commit often" mindset. The fact that each team would be working on a completely different subsystem in the same repository makes it even nastier in my mind.

Our current StarTeam process for any change is as such:

1. Lock the file(s) you want to work on,
2. Make your entire change and get it reviewed from a copy on a network drive,
3. Check in (and unlock) the changed files, hoping that someone hasn't forcibly broken your lock,
4. Hope that your change hasn't broken the build from someone else's change to other files

Personally, I think the idea of "locking" files is ridiculous. There should be enough communication between teams such that you don't need to.

Does anyone here have experience with distributed repositories on projects of a similar size? Could you make any suggestions as to version control and/or change management solutions? The main requirement is that the system be able to manage customer-initiated change requests and force developers to link their checkins to one.

Thanks.

Answer 1

Both Git and Mercurial is being used for projects with complexity far greater than what you have mentioned. So Using Git / Mercurial for your project team size should not be an issue.

By nature, we want more control on the version control server. Subversion is quite popular due to that.

How ever it is easy to maintain releases based on change-set using DVCS like Mercurial or Git.

You can have a repo setup where change-sets are pushed only after review. This should mitigate the requirements of your change manager.

DVCS do come with advantage that you could create experimental branches or clones easily, throw them out if it does not work and pull the changes in when you believe they are ready for primetime. Commit often / Commit early is a practice which works well with DVCS because you push changes to your own repo. Once it is baked, you can push it upwards for availability within the team.

Locking of files is an old era. It is not being used even by tools like Subversion. It is really a impediment to working.

Answer 2

Git will not provide the "change management" process you're looking for. This is one of those management requirements that commercial version control systems like to advertise to attract businesses with shiny objects. That doesn't mean you can't do it, it's just outside the domain of git's purpose. Much like, authentication and access control (you can use ssh, and gitolite, but git itself does not provide these services). You'll probably need to develop this integration yourself unless you work with a common bug tracking tool.

Locking files is always wrong. This is what "merging" is for.

I currently work on a codebase of ~200,000 lines of code with 10 developers and git works very well. We have groups an order of magnitude larger also using git on other projects. Git's strength lies in merging and this is how it deals with multiple developers and lots of commits. Keep in mind, every push is a merge in git, whether it looks like it or not. Your local repository may have a branch named master, but it's not the same branch as master in the central repository. To synchronize them, you do a merge, which sometimes just is a "fast-forward merge".

We don't bother to force a strong link to change requests. When I considered writing an interface to do this, one problem I ran into was how to make the dumb tracking system aware of every branch a bug is in. A simple hook isn't enough for this.

You should move to git for the development process improvement. For me, it's fundamentally altered (improved) the way I write code. You'll be challenged to present a case for git doing change management better in business-speak without all the prepackaged bullets that come from expensive IBM tools. The real problem is, once you embrace git, you'll never be able to work with any of the other tools again, no matter how good a business case they present...