Version control architecture for a large project with many dev groups - version-control

We are working on a very large portal project. We need a scalable source version control architecture such that, it should be scalable to many teams and possible incoming teams.
There will be common libraries and each group will work on different part of the system. At demo times, we need to integrate these parts and have the product testable, demoable and so on.
Do you recommend some guidelines or architectures?
How would you approach this problem?
In terms of version control system, we are using TFS, if it helps.

Sounds to me you would be better off with a DVCS (Distributed Version Control System) like Git, rather than TFS which has a centralised version control system.
TFS now integrated with Git, here is a good blog post which provides you with most of the details you would need - http://blogs.msdn.com/b/visualstudioalm/archive/2013/01/30/getting-started-with-git-in-visual-studio-and-team-foundation-service.aspx
Add an enterprise level Git Repository Management tool like Atlassian Stash and life will be sweet - http://www.atlassian.com/software/stash/overview

From a TFS server side...setup only 1 team project. This will be key. The other key is to have the server running SQL Server 2012 with SP1 (there's tons of perf improvements in SQL that will help you scale TFS).

Related

Upgrading to Team Foundation Service from TFS2010

I work for a company that has a small development team (~30) distributed across multiple continents and multiple development platforms (Windows & OSX). As is such, Team Foundation Service seems like a great way to have a high-availability source control that works well with different development platforms. We're currently using TFS2010 and have about 20,000 checkins in our checkin history. If we were to move to TFService, we'd like to be able to bring the Source Control history with us.
Is this possible?
If possible, are there any guides available covering how to do this upgrade?
Team Foundation Service seems like a great way to have a
high-availability source control that works well with different
development platforms.
I can't vouch for multiple platforms (yet), but for all things Windows-related I have been extremely pleased with TFS "in the cloud".
This article looks promising: Migrating from an On-Premises Team Foundation Server to Team Foundation Service Preview Using the TFS Integration Tools
In this article, I demonstrate a migration from an on-premises
Microsoft Team Foundation Server (TFS) 2010 to Team Foundation Service
Preview, which uses the latest TFS Integration Tools.
...
The TFS Integration Tools help you move yet keep the integrity of
version control (VC) data, work item tracking (WIT) data and the links
in both.
The crux of the article seems to be the usage of the TFS Integration platform, found here on Codeplex
Note that TFS Preview recently (October 2012, I believe) went live so it is no longer a "preview".
A good search phrase for this process seems to be "migrating on-premise TFS to cloud".

CodePlex TFS Services

I have been thoroughly confused by CodePlex and the TFS services it offers or doesn't offer. I am going to soon begin working on on open source project with a few friends using Visual Studio 2010 Professional. Because VS is so nicely tied in with TFS, we would prefer to use TFS.
However, we do not have the money to purchase TFS ourselves, so we were looking at CodePlex as an alternative. Does CodePlex offer free TFS hosting? I believed it did, until I came across this which led me to believe it only offers part of the TFS feature set.
(This is my first experience with version/source control, so please be light on the terminology.)
CodePlex offers free TFS hosting with a feature set aimed at hosting open-source projects. Its version control offerings are complete, but Team Foundation Server is a platform with many feature areas, so let's look at those:
Version Control: CodePlex supports the entire feature set of TFS Version Control. In fact, CodePlex pioneered some version control tools for TFS like their SVNBridge.
Work Item Tracking: Team Foundation Server allows for a customizable work item tracking template and ships several out-of-the box to suit development processes ranging from CMMI to Agile. CodePlex, however, provides a single work item tracking template that is suitable for open source projects and does not allow customization.
Continuous Integration: CodePlex does not support automated builds at this time. You can set up your own continuous integration builds against a CodePlex endpoint for source code, though.
Document Repository: There is no SharePoint document repository available in CodePlex.
Reports: SQL Reporting Services are not available in CodePlex.
I would argue that for a small open-source project, none of these are deal-breakers. For a very large project, however, some or all of these features may be desirable, though.
If you want to use TFS and you are looking for a cost-effective solution for a small project, you may also want to look into Team Foundation Service, which is currently free while it is in its preview state. (Future pricing has not yet been announced.)

Team Development offline

I want a version control system tool, but offline.Like I develop a project on my computer,and someone is working on a different part of this project on a different computer.Is there a tool that allows to me bring the project from different computer to mine and sync all the changes.
I would like to have all functionalities of a version control system like diff,rollback,commit
Please suggest a suitable tool.
Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.
http://git-scm.com
It can be used online or offline easily.
Almost all the version control tools on the market support these features: diff, rollback, commit, offline, etc. I list some tools here for your reference:
Open Source
Git
SVN
Commercial
SourceAnywhere (developed by the company I'm working for)
Microsoft Team Foundation Server

I need a simple source code vault for use with vs2010. is there a bare bones version of TFS?

I thought I heard that there was going to be a entry level, low cost version of TFS that is targeted at VSS users who want repository and versioning functionality only. But I can't find the link anymore...does it exist? Or do I need to figure out how to use subversion?
You're looking for TFS Basic, an installation option in TFS.
It starts at $500.
I would recommend SVN. Go here for TortoiseSVN, an integrated windows shell solution. Alternatively, you could use VisualSVN or any number of other SVN clients, some with VS integration. If you understand the basics of versioning and source control, Tortoise is perfect for you - it's all GUI so you don't need to mess with a CLI unless you want to.

Source control system for single developer

What's the recommended source control system for a very small team (one developer)?
Price does not matter. Customer would pay :-)
I'm working on Vista32 with VS 2008 in C++ and later in C# and with WPF. Setting up an extra (physical) server for this seems overkill to me. Any opinions?
I would use Subversion (in fact I use it) [update: Jul 2014 -- I use Git -- see end of the answer].
SVN is:
free,
good enough (see disadvantages below),
simple,
works fine on Windows (and Linux too),
a lot of people use it so it's easy to get help,
can integrate with most of IDEs i.e. Visual Studio (i.e. ankhsvn or VisualSVN -- more info) or Eclipse (i.e. Subclipse -- here someone asked about that).
I would strongly recommended separate machine to source control server. At best somewhere on the cloud. Advantages:
You don't lost your source control repositories if your development box dies.
You don't have to worry about maintenance of one more box.
There are companies which host SVN repositories.
Here are links to SVN (client and server) packages for various operating systems.
Disadvantages of SVN
I am using SVN on Windows machine for about 5 years and found that SVN has a few disadvantages :).
It is slow on large repositories
SVN (or its client -- TortoiseSVN) has one big disadvantage -- it terrible slow (while updating or committing) on large (thousands of files) repositories unless you have SSD drive.
Merging can be difficult
Many people complain about how hard merging is with SVN.
I do merging for about 4 years (including about 2 years in CVS -- that was terrible, but doable) and about 2 years with SVN.
And personally I don't find it hard -- on the other hand -- any merge is easy after merging branches in CVS :).
I do merge of large repository (two repositories in fact) once a week and rarely I have conflicts which are hard to solve (most of conflicts are solved automatically with diff software which I use).
However in case of project of a few developers merging should not be problem at all if you keep a few simple rules:
merge changes often,
avoid active development in various branches simultaneously.
Added in July 2011
Many devs recommended Distributed Version Control like Git or Mercurial.
From single developer perspective there are only a few important advantages of DVCS over SVN:
DVCS can be faster.
You can commit to local repository without access to central one.
DVCS is hot thing and fancy to use/learn (if someone pay for your learning).
And I don't think merging is a problem in case of single developer.
Joel Spolsky wrote tutorial about Mercurial which is definitively worth to read.
So, despite of many advantages of DVCS I would stay with SVN if merging or speed is not a problem.
Or try Mercurial, which according to this and this SO questions, is better supported (in July 2011) on Windows.
Added in July 2014
For about a year I use Git (Git Bash mainly) for my pet-projects (i.e. solving Euler problems) and local branches for each Euler problem are really nice feature -- exactly as it is described as advantage of DVCS.
Today Git tooling on Windows is much, much better then 2 or more years ago.
You can use remote repo (like GitHub or ProjectLocker and many others) to keep
copy of your project away from your workstation with no extra effort/money.
However I use GUI client only to looks at diffs (and sometimes to choose files to commit),
so it's better to not afraid of command line -- it's really nice.
So as of today I would go with Git.
I would also recommend Mercurial. It's command set is much like the one found in Subversion, so the learning curve is not that steep. As mentioned earlier, it's designed to run locally, but it's also easy to share/merge changes across computers, or even just push it to a remote server for backups.
It offers excellent tools, like TortoiseHG, and it has good plugins for NetBeans and Eclipse. It also runs natively on Win32, as it's written in Python.
If you don't want to set up a server yourself (for backups, e.g.), there are free hosting providers available; there's a comprehensive list on The Mercurial Wiki.
I would definitely recommend git
Works great for both big and small teams. Only drawback is poor native windows support. Although it works fine for me in Cygwin. There also exists a native windows port.
Some of its benefits:
Excellent support for a non-linear work flow. Its branching and merging is far better than eg Subversion.
Good tools to navigate your repository
Handles large projects well.
It is not possible to modify the history without changing the cryptographic signature of your repository
With its non monolithic design, it is easy to script.
Some people find that it has a steep learning curve. But once you understand it you can do almost anything you would want with it.
Go for subversion and tortoiseSVN, you don't need to set it up on a server.
Costs are zero
The subversion documentation is great and fun to read
tortoiseSVN is a very convenient client
Subversion has very low barrier to entry.
TortoiseSVN is a free client, and integrates into your explorer- i.e. in right mouse click menu.
The repository can be just a directory somewhere on your PC or on a network drive. Backing up just means zipping up this directory
There are a few plugins to Visual studio for Subversion, AnkSvn is one I have used, it is free and integrates nicely (i.e it will be smart about moving and deleting files etc)
Subversion is a good choice for one developer.
Update:
Since this post, I've been using Mercurial. It is a Distributed SVN. The 'distributed' aspect may not be directly useful to a sole developer, however it is better at merging and is somewhat faster. There is also a free and good Windows Explorer extension client - Tortoise Hg.
So in summary, if you are the sort of person who will work on many branches at once (doing spikes etc) or if you work on multiple PCs at once and would like full offline access to checkin history on both, then Mercurial. If you just want simple tracking and a well proven and easy to understand solution, then Subversion.
Sourcegear's Vault is a great option, it runs on SqlServer and it has been around for many years. I would not use any version of VSS (Visual Source Safe).
I'm surprised no one has mentioned Perforce. It's free for 2 people, blazingly fast, and integrates with VS. Also source server has bindings for it by default.
In addition to source control, it really is worthwhile to complete the loop and setup a symbol server and a source server, so that you have simple debugging of anything you've shipped (e.g. no more searching for pdbs or source that match the binary). Both source and symbol server are completely free and supported in VS since 2005.
You can use Vault from SourceGear, the replacement tool for visual studio source safe.
The IDE is integrated in Visual Studio.
The tool is free for single user.
More information: http://www.sourcegear.com/vault/index.html
I use Mercurial. It runs a treat running stand alone on my Vista development system with no other dependencies required. I use the command line but there's also TortoiseHG to integrate with Explorer.
Two comments:
There are other tools which probably integrate with VS better. I think Subversion has nice VS plug ins.
The benefit of a separate server is that it's a nice backup of all your work in case your HDD dies on you etc. so discount having one.
Edit: #Slartibartfast - if you just want to run source code control on a single machine a Distributed Source Code Control tool like git or Mercurial is ideal since they're designed to run complete repositories on a machine without the overhead of a server. The fact that you never connect your repository to anyone else's to push and pull changes doesn't mean that tool won't be right.
There are two possible solutions for your problem: centralized VCS or Distributed VCS (DVCS).
Centralized VCS like Subversion would satisfy you feature for committing and browsing the log. It also enables you to safely store your repository to another computer which should be one of your major goals as hard drive failure is always a possibility. However, using Subversion the history still resides only at the central location making it vulnerable and you stated that you do not want to have another server.
Distributed Version Control Systems (DVCS) such as Mercurial and Git enable you to do more complex operations on your repository. With both of those tools the whole repository resides with the same computer making it bit easier to make backups and using the repository with another computer e.g. laptop. While Mercurial might seem complex at first the operations you would use with subversion are pretty much the same with Mercurial. Therefore there is no extra overhead to get started if you already know Subversion and you can easily use more advanced features of Mercurial later.
You should be able to find online repository service for your Mercurial repository enabling you to make easy backups and do collaboration some day if you have the need for it.
My recommendation is Mercurial with TortoiseHg.
A source control system doesn't care if there's only one developer involved :)
I would recommend that you use a source control system that you've used before and liked.
If you like vs 2008 integration of the source control system however I would go with TFS although I never had the experience to set it up but it shouldn't be so hard.
Another possibility is to use svn (you'll find some servers on google) and use Tortoisesvn that integrates into the windows shell and is nice to work with.
A number of the posts advocate putting the repository on a server because it provides redundancy. I don't think this is all that helpful for a single user. Using a separate server machine adds a lot of complexity, but it doesn't buy much redundancy: if you lose the server machine, you still have the current sources on your development machine, but you may have lost ALL your history. Putting the repository on a server does make sense if that server is being regularly backed up. Using an exernal hosting service for the repository can provide storage redundancy, but you're at the mercy of the external service AND you need an internet connection to access the repository. If you use an external host, make frequent backups of the repository that you keep control of!
I would presonally recommend TortoiseSVN using a local file based repository. Just make sure you backup the local repository to a second machine or external media (such as CD-ROMs) on a regular basis.
I'd recommend two things:
First up, that other server - what happens if your machine dies? the house burns down? etc. Having it on another machine is a good idea from a redundancy point of view.
The second one is WHAT:
If you are very familiar with visual source(un)safe, think about SourceGearVault. It's VERY nice, very fast, and very much a vastly improved "clone" of VSS (ie works the same way from the users POV, not under the hood). Needs SQL server and windows tho (it's .NET + SQL server). Free for 1 user.
Of you are not, then I suggest you do one of two things:
First, get VisualSVN. It's great, works with VS2008 really well.
Second, if you MUST run it locally, get VisualSVN server (free!). Make sure you have a good backup plan. Runs on XP/2003/2008/Vista etc.It's just Apache + SVN, under the hood, so it just saves you on the setup - took me 5 mins to install and have it running.
OR, and I prefer this one:
go somewhere like Unfuddle, Dreamhost etc, and get hosting for SVN. It's private, it's fast, and most of all - it's OFFSITE. My dreamhsot account, with something crazy like 500GB of storage and 1-2TB of transfer/month costs about $6/month! There are others which do SVN hosting + bug tracking etc. Look around.
But yeah - SVN is the schizzzznit.you could create a local repository, but I like having a remote, backed up server.
TFS is total, utter overkill for 1 developer (or <5 IMO)
I realize that cost isn't a problem but a nice free solution that wouldn't involve checking in and out would be to host the code within Dropbox by doing this you'd instantly get versioning and backup which are the main features that a single developer system would provide.
Bazaar is a good version control system. I like to use it for my linux configs because you don't need to create a separate repo.
A while back I did a how-to blog post on using SVN with only one developer.
I called it Single serving source control
Well, for start, you don't need distributed one :)
I'm not sure what this physical part means, because you could put svn server on your own machine in little trouble.
On the other hand, NetBeans have local history module that logs all local changes of a file. Maybe something like that would be enough for you if Visual Studio have something similar.
I would recommend Subversion since it's for single developer and I assume that you're not doing complex merging and lots of log/history checking.
Seems like many people are using http://svnrepository.com/ for their hosting. It comes with Trac and even Git if you need it later.
Some good answers here.
I want to re-iterate the suggestion to use a separate computer to host the source control server, although it doesn't have to be a dedicated machine. It could be your Windows Home Server box, or some other server you're already running. Or it could be a virtual machine hosted on some other server. Whatever, just make it separate from the machine(s) where you write code.
I also want to suggest that you get a good backup discipline for your server. Something nightly at least; hourly if you can. Back up to a dedicated device (like an external hard drive) or something offsite (a server in your cousin's house in another state) or in the cloud (Amazon S3). Remember that your source code is your key asset; take care of it!
I've been working with Bazaar now for a few weeks and really like it. I'm a linux developer so don't really know much about Tortois but if you like it you should know that there is a Tortoisbzr
Hands down I would use git, and I believe many reasons why a single-developer would like to use git are hinted at or described in git magic
I use Springloops - version control tool for developers
SVN / Git version control
Automatic deployment to servers
Create repositories
Invite people
Import files
Great support
So, try Springloops
I dont see why the fact that your one developer changes anything on the source control issue. I would follow the same system (in fact I do on my solo projects). I use wush.net (svn and trac) in those cases. It's fast to set up and dont require that you yourself do or know any server issues. I recommend you use something like this.
I would recommend using subversion. Many have recommended using a seperate box as a server, in case your dev machine dies. What happens when the SVN server dies? The answer here is that no matter where you choose to run the server, ensure you always do frequent backups, possibly automated daily to some secondary, preferrebly offsite machine.
I use Perforce as well for my own personal stuff, mainly because we use it at work. There are emacs bindings for it as well, so you can sync, check stuff in or out, etc. all from within emacs.
I recently moved my studio from Subversion to Perforce and put some notes about it, sort of a postmortem, on my blog here. Hope it's useful.