StarTeam Migration to Distributed Source Control

Question

We are currently using StarTeam for our project, and the license will expire soon. We are looking at a transition to Team Foundation Server or something similar, but there is a push (mainly from me and another person) to move on to some form of version control. One of the problems is that our change manager wants to track and issue a change request (like in StarTeam), and I don’t think that this can be easily done using 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 supported by 5-6 development subtopics with 30-40 developers. For me, it looks like in a distributed storage there will be a nightmare with “commit before, commit”. The fact that each team will work on a completely different subsystem in the same repository makes this even more unpleasant in my mind.

Our current StarTeam process for any changes is as follows:

• Lock the file (s) you want to work on,
• Make all the changes and view them with a copy on a network drive,
• Complete (and unlock) the modified files, hoping that someone has not locked your lock,
• I hope that your change did not break the assembly, and someone else will replace it with other files.

Personally, I think the idea of ​​“locking" files is ridiculous. There should be enough communication between the teams, so you do not need to.

Does anyone have experience working with distributed project repositories of similar size? Can you make any suggestions for version control and / or change management solutions? The main requirement is that the system can manage requests for changing customer requests and force developers to associate their checks with one.

Thanks.

Answer 1

Both Git and Mercurial are used for projects with a lot more complexity than you mentioned. Therefore, using Git / Mercurial for your project team size should not be a problem.

By nature, we want more control over the version control server. Due to this, Subversion is very popular.

How to easily maintain changeset-based releases using DVCS such as Mercurial or Git.

You may have a repo setup in which change shifts are pushed out only after verification. This should soften the requirements of your change manager.

The advantage of DVCS is that you can easily create experimental branches or clones, throw them out if they don't work, and make changes when you think they are ready for prime time. Commit often / Commit early is a practice that works well with DVCS because you push changes to your own repo. Once it is baked, you can push it up for accessibility within the team.

File locking is an old era. It is not used even with tools like Subversion. This is really an obstacle to work.

Answer 2

We have done this very successfully with git. We are following this process. It’s very easy to track progress on any issue:

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

If you look at the comments, some influential people have reviewed this process. This is an awesome way to work, and hopefully this entry will give you the ammo you need. For specific TFS material, see here:

TFS forking, what are the benefits (misleading header)

Answer 3

Git will not provide the "change management" process you are looking for. This is one of those management requirements that commercial version control systems like to advertise to attract companies with brilliant objects. This does not mean you cannot do this, it is just outside the git domain. Just like authentication and access control (you can use ssh and gitolite, but git itself does not provide these services). You will probably need to develop this integration yourself if you are not working with a regular bug tracking tool.

File locking is always incorrect. This is what fusion means.

I am currently working 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 for other projects. git strength lies in merging, and that is how it deals with several developers and many commits. Keep in mind that each click is a merge in git, whether it looks like it or not. Your local repository may have a branch named master , but this is not the same branch as master in the central repository. To synchronize them, you perform a merge, which is sometimes just a “quick merge”.

We are not trying to force a strong link to change requests. When I thought about writing an interface for this, one of the problems I ran into was how to get the dumb tracking system to know every branch that the error is in. A simple hook is not enough for this.

You should go to git to improve the development process. For me, this fundamentally changed (improved) the way I write code. You will be asked to submit a case for git to better manage change in a business conversation without all the pre-packaged cartridges that come from IBM’s expensive tools. The real problem is that after you embrace git, you will never be able to work with any other tools again, no matter how good the business example they present ...

Answer 4

I wrote this in a comment, but I think it is important enough to deserve a complete answer.

I work as a Mercurial consultant, and when I talk to clients, they often ask for “change requests” and “change management”. When I tell them that Mercurial has no such concept , they get surprised. Like Git, Mercurial is a focused tool. It performs version control and allows you to define workflows from above. You can phrase workflows in terms of change requests if you want, but you don't need to.

A typical way to handle change requests is to put them in some kind of tracker. Linking change sets to CR can be done using named branches in Mercurial or using comments in commit messages in Git. When you click on the central server, the problem is updated using the hook.

You mentioned changes that should not be part of the release in the end. The easiest way is not to merge into the trunk until it becomes known that the change is stable. You still want to run tests on a branch, so you need a test setup where you can test each branch one at a time. To check the dependencies between branches, you first combine them and run your tests for the result. You can continue to work on branches, and subsequent merges will be small.

Finally, when you want to devote yourself to freeing a branch, you will merge it into a trunk.

Answer 5

Below is a small web application that converts StarTeam projects into a GIT repository.

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

I developed it because in my work I decided to migrate and give the opportunity for any group to work on such a process without previous research.

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 whose goal is to convert the Starteam repository to GIT.

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

Installed: - GIT - git-svn - Java - apache2

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

Answer 6

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

The code is located at https://github.com/warrenfalk/git-st/tree/st_to_git_migration_features (this is a git -st fork with a function branch capable of this kind of import. The branch contains 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 complete it.

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