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

The following is a small web application that converts projects of StarTeam to GIT repository.

http://dl.dropbox.com/u/101447754/startgit.tar.gz

I developed because in my work decided to migrate and give the possibility that any group without previous research work to make such a process.

Now:

StartGIT es una sencilla herramienta para trabajar con Controladores de Versiones, su fin es poder convertir un repositorio en Starteam a GIT, para ello se hace uso del script "svnimporter-1.2-st" obtenido en "http://www.polarion.com/user/direct_register.php?dl=svnimporterst":

Tener instalado: - GIT - git-svn - java - apache2

Pasos: - Descomprimir "startgit.zip" - Colocar la carpeta descomprimida "startgit" en el directorio "/var/www/" - Abrir navegador web y colocar la siguiente direccción "http://localhost/startgit"

//-------------------------------------------------------------

StartGIT is a simple tool, its purpose is to convert a Starteam repository to GIT.

This script uses the "svnimporter-1.2-st" obtained "http://www.polarion.com / user / direct_register.php? dl = svnimporterst "

Have installed: - GIT - Git-svn - java - apache2

steps: - Unzip "startgit.zip" - Place the unzipped folder "startgit" in the "/ var / www /" - Open web browser and "http://localhost/startgit"

Answer 2

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 3

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...

Answer 4

We have done this very successfully with git. We follow this process. Very easy to track progress on any issue:

https://plus.google.com/109096274754593704906/posts/R4qkeyRadLR

If you look at the comments, there have been some influential people that looked over the process. It's an awesome way to work and hopefully that write up will give you the ammo you need. For TFS specific stuff, take a look here:

TFS branching, what are the advantages (misleading title)

Answer 5

There is currently a git remote helper for StarTeam which can also be used to import StarTeam's history into a git repository which can serve as a replacement for StarTeam.

The code is at https://github.com/warrenfalk/git-st/tree/st_to_git_migration_features (it is a fork of git-st with a feature branch capable of doing this kind of import. The branch is st_to_git_migration_features.)

see: https://github.com/warrenfalk/git-st/blob/st_to_git_migration_features/README.migration.md for instructions on how to accomplish it.

I have used this to successfully import StarTeam's history into a git repository.

Answer 6

I wrote this in a comment, but I think it's important enough that it deserves a full answer.

I work as a Mercurial consultant, and when I talk with clients they often ask for "change requests" and "change management". When I tell them that Mercurial had no such notion, they become surprised. Like Git, Mercurial is a focused tool. It does version control and lets you define workflows on top. You can phrase the workflows in terms of change requests if you like, but you don't have to.

The typical way to handle change requests is to put them into an issue tracker of some sort. Linking the changesets with a CR can be done using named branches in Mercurial or using comments in the commit messages in Git. When pushed to a central server, the issue is updated by a hook.

You mention dealing with changes that should not be part of a release after all. The easiest way is to not merge into the mainline before it is known that the change is stable. You will still want to run tests on the branch, so you need a test setup where you can test each branch one by one. To test dependencies between branches, you tentatively merge them and run your tests on the result. You can continue working on the branches and subsequent merges will be small.

Finally, when you want to commit yourself to releasing the branch, you merge it into the mainline.