Coming from VSS (or Source Unsafe, or Source Destruction - choose your favorite epithet) some things which are common in other control systems take some getting used to when first moving to "real" source control. My only other version control experience was with Perforce, and there are some parallels here. I have since also gotten into CVS while dealing with NUnit development, and there are other parallels here. If you come to TFSC from one of these other systems, the learning curve will be much more shallow.
Allow me to enumerate the lessons learned so far:
1. The folder you designate as a workspace for a certain project will be totally controlled by source control, including deletes. This is great (and normal for other version control systems), but a real adjustment for lazy VSS users who sometimes like to keep the development area dirty in order to work with different versions of code at the same time (mySource.cs.old for instance).
2. What you actually have on disk is of no consequence to the source control system. Which is to say that the notion of having the latest, or the content of a particular file is controlled by the actions which you have taken against source control through its interfaces. The information stored in the source control database will be used by the source control system, not a lookup of files on your disk. If you happen to do something on disk, outside of source control - you will soon be very confused when you go to use source control again. To get back to a usable state, you should choose "Get Specific Version", and then check the "Force get of file versions already in workspace" checkbox. This will "update" your disk, even if everything was up to date, and get you back in sync with what the source control system believes to be true. In short, don't do anything to the workspace outside of version control. If you want to play around with files, copy the workspace to another location.
3. Putting auto-generated folders or files in source control is unworkable. What used to simply be a problem or difficulty in VSS is totally unworkable in team system source control. This means all /bin, /doc, and /obj folders must be left out of source control. This is actually a tenant of good configuration management anyhow, but the problem is that by default when you add projects to source control, you will get these folders. You must consciously remove or avoid these folders.
A related issue is how you deal with assembly references when you are not including any of the referenced assemblies in these auto-generated folders. Your projects keep relative links to referenced assemblies in the
<HintPath>..\..\ReferenceAssemblies\Release\SomeAssembly.dll</HintPath>
element. Each developer (and the build server) will need to have this same relative path, or a gac entry for the referenced assembly. Another possibility is to use an environment variable so each developer can have their own locations, but this seems like more setup than its worth.
4. The entire team must standardize on file or url based projects when working with web projects. Because of the relative references in web.config and because of unit tests, all hell breaks loose if you have one developer using a url based web project, and another using the file system based. Choose one way to do it, and force all developers to accept this standard.
As far as which to choose, I would say the file based is better simply because it is keeps your web projects in the same basic location as your other projects, and because it is the way Visual Studio expects to work - and we all know that if you accept some product defaults, you'll save headaches.
Posts
1 comment:
Nice post!
Just a couple of quickie comments:
The Version Control vs. Source Control thing: http://blogs.msdn.com/jmanning/archive/2005/10/24/484455.aspx
Auto-generated folders in source control: if you're using Solution Explorer or doing the "add solution (or project) to source control" those folders should *not* be added. If you have a repro case for this (with beta3 or beta3 refresh), please post it in the Team Foundation forum (http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=22&SiteID=1). The main point of having "add solution to source control" is so we take care of what should and shouldn't be added for you - you shouldn't have had to deal with this. Now, if you use something other than Solution Explorer (for instance, Source Control Explorer, or the command-line), then yes, you'll get all the files/folders added.
References: the approaches you listed are definitely possible. Another possible approach is checking in references into source control so everyone's got them at the same relative path. No single approach will work perfectly for everyone, so definitely find whatever works best for your team.
Post a Comment