Best source control system for maintaining different versions

Question

Hi all!

We need to be able to simultanously maintain a set of different versions of our system. I assume this is best done using branching. We currently use TFS2008 for source control, work items and automatic builds.

What is the best version control solution for this task? Our organization is in the process of merging to TFS2010. Will TFS2010 give us the functionality we need to easily manage a series of branches per system version? We need to be able to keep each version isolated from the others, so that we can do testing and deployment for each version.

Our dev team consists of 5 .net developers and two flash developers.

I have heard a lot of talk about GIT. Should we consider using GIT instead of TFS for source control? Is it possible to use TFS2010 together with GIT? Does anyone have similar setups that works nicely?

Any sugggestions are appreciated!

Thanks,

Kjetil.

Answer 1

TFS 2010 - hands down. Not for being a great version contrrol system, but because of all the rest it does. GIT will leave you open to select work item tracking, continous integration again. Keeping the number of suppliers ( technologies low is a core for better administration.

Answer 2

Mercurial will also do the job.

Here's an excellent tutorial on it.

Answer 3

The main reason you should consider Git (or Mercurial) is for:

• its Distributed nature.
• its ease of merging (a consequence, actually, of being distributed)

If your team is located in one site, and if your development process is linear enough (simple merge workflow), a centralized VCS is enough.

From there, TFS2010 has made some interesting evolutions, especially on its branching model, and its other features integrated within it (hierarchy of work items, build with "Gated Check-in" and based on a "Workflow Foundation") makes it a better candidate than a tool limited to the VCS aspect.

Answer 4

Today there are mainly two types of version control systems (VCS), the so called distributed VCS and the central repository systems.

The most popular "distributed" VCS today are git and mercurial. The most popular central repository systems are subversion and SourceSafe of Microsoft. The http://hginit.com introduction explain the superiority of "distributed" VCS over the central system.

With a distributed VCS every developer has its own local repository. It is generally used with a shared central repository holding the official release. But this is just a repository organization. "distributed" VCS are superior to purely centralized VCS in their ability to manage merging.

Answer 5

Subversion!!!

I like Subversion, + TortiseSVN + VisualSVN

http://subversion.tigris.org/
http://tortoisesvn.tigris.org/
http://www.visualsvn.com/

Subversion and Tortise are Free!, and VisualSVN is only $50 per license (but you don't HAVE to use Visual-SVN, it's just the VS integration....not necessary as far as I'm concerned.)

Here's a tutorial and installation guide for all three products.
http://www.west-wind.com/presentations/subversion/

and another...
http://www.dev102.com/2008/10/07/how-to-use-the-svn-client-and-start-working-with-your-subversion-version-control/

Answer 6

All the requirements you need are included in TFS 2010. Branching, and keeping branches isolated.

TFS is more as only a version control system. It is also a work/bug control system and has tools for integrated build. If you need these, and you already have a license for TFS 2010, don't waste your time on other systems.

OK, TFS is not distributed, but actually, when working I like TFS not to be distributed. As soon as I check in stuff (in my personal branch) it will be on the daily backup, and is available for others to look at. (For my home/hobby/personal stuff I use mercurial).

For all other systems there are tools available that provide you with the building and bugtracking, so it is not an issue for other tools that they are not available, it just takes time to select the ones that match your needs.

Answer 7

I just love git and it's being integrated in so many other applications as well, like Eclipse, Trac. who needs to pay for a VCS when you have Git.

The fact the Linux kernel development uses git, I know because Linus said so :), which is not a small project speaks for itself.

Answer 8

A good revision control system will help me when I am working in a scattered way. Not because I like being scattered, but because day to day demands have a way of scattering how one works. The scattering is exacerbated when a group is working in parallel on a decent sized project.

Person A is working on feature 1. Person B is working on feature 2. Person C is working at fixing reported bugs on released version.

While A is doing his work he observes an error in the code and fixes it on the spot so as not to overlook it, and continues. Person C makes 3 corrections.

A, B, and C have chat and B feels he needs the bug fixes C has done right away as well as the bug fix A has done, but not the A's feature. C wants A's bug fix. A wants C's bug fixes. And so on.

Boss decides we want a version with feature 1, another version with feature 2, and a version with both features, and a version with neither released and maintained.

How well does the tool support you in these activities? How much does the tool obstruct you in these activities?

I'm really happy with 'darcs'.

I have tried many revision control systems. I have come across none better.

It is simple, it is rigorously correct.

Because it is rigorous it is reliable and predictable. Because it is simple, it is helpful and does not get in your way.

My second choice would be git.

Git is pretty good, but not as rigorous, it forces an order on you on some occasions when order does not matter. Git is better known so a better resume bullet.

http://en.wikipedia.org/wiki/Comparison_of_revision_control_software

Answer 9

Based on my experience, if you are looking for a DVCS, Git or Mercurial (Hg) is the way to go. Deciding between Git and Hg is a tougher task, however.

Are you primarily using Windows? If so, Hg is probably your friend. Combined with TortoiseHg, it is a very good, versatile tool, that is easy to start using compared to Git. It is a bit less complex, but handles most things Git can handle, even if not QUITE as smoothly.

If you are using Linux or a Unix shell, Git would be my choice. I personally use Git in windows, using the git shell utility. (it also works fine in Cygwin, if you prefer) I have found that Git handles my projects a good deal more effectively than Mercurial does. However, if you're not a savvy with a command-line, I have found that TortoiseGit is a bit more complicated (and clunky) thatn TortoiseHg. But because I am familiar with bash, git is definitely my preference. It is simply faster, leaner, and more versatile than Hg, in my time with both of them. It is simply a bit more complicated, so the learning curve is higher and early on you may be prone to mistakes with it, as I was for a short while.

So in my estimation, the real questions are:

Windows (Hg) or Unix (Git)

and

Graphical (TortoiseHg) or Command-line (Git shell)