Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
We are currently looking for a version control system to use in our projects. Currently our team is less than 10 people. We have been using VSS for the last 5 years. I have never worked with SVN and other version control systems.
Up to now we have been using VSS, but nowadays more powerful source control systems exists like TFS, SVN, etc. We are planning to migrate our projects to Visual Studio 2010, so the first idea coming to mind is to start using TFS 2010.
My question is: how good is TFS compared to other source control systems? Is it a good idea using it, or should we rather use SVN (or any other system)?
Having worked with TFS, Git, Subversion, CVS and VSS, let me quickly summarize my experience:
It's fair to say that both Visual SourceSafe (VSS) and Concurrent Versions System (CVS) are pretty much obsolete these days.
Git is technically the most powerful tool, but requires some time to understand the concepts. It also plays most of its advantages only if you really go for a distributed scm approach. The number of third-party software supporting Git is increasing rapidly, but is not yet as ubiquitous as for SVN.
Subversion (SVN) offers clean and easy-to-understand concepts with a fairly common-sense and generic approach. A vast amount of integration software for most IDEs and file managers, as well as a lot of extension software is available. Because of the use of standard protocols like HTTP and WebDAV, it also integrates with software that wasn't actually designed to work with SVN, such as Microsoft Office ("Windows Web Folders") and more. SVN would be my recommendation if you are planning for a more traditional, centralized SCM approach.
TFS version control is tightly integrated with Microsofts "Visual Studio" product line and the rest of the TFS development lifecycle platform. For use outside Visual Studio, there are a number of tools and a command line interface, but it really doesn't make sense to use TFS without Visual Studio, believe me. TFS version control is technically one of the worst I've ever worked with. Reasons:
It needs explicit checkout of every single file you work with. The same file being checked out by more than one person at the same time means TFS sees a conflict, no matter whether these people actually changed anything.
TFS uses a "workspace" concept, where actions in your working copy are recorded on the server as you work. You can't just checkout multiple copies of the source tree to multiple folders, you need constant online connection to the server (there is an "offline" mode, but that messes things up). All changes to anything in the local working copy have to go through TFS client tools first, since files are downloaded as read-only.
The fact that TFS shows more conflicts in the UI than are actually there encourages users to just bulk-accept or bulk-reject changes, which leads to loss of changes in one way or the other. It thus obstructs your view to what is actually important, which is a dangerous thing for a version control system.
The UI integration in VS doesn't support many useful operations you need when working with a SCM system seriously, like atomic (server-only) creation of branches, Branching from earlier revisions, undeletion, reverting of changes of a given changeset, and many more.
It is horribly slow, because creation of a branch implies downloading a whole new copy of the source tree if done via the VS GUI. A simple rename of a folder is also really slow. All in all it seems to create a lot of network traffic for simple operations.
The built in "shelving" feature, where you can save away your current changes without checking them in, is a nice idea but very much useless in most scenarios, since it doesn't support conflict resolution or merging when you re-apply your shelved changes to your working copy. If creating branches was as simple, reliable, fast, and straightforward as e.g. in SVN, you wouldn't really need such a feature, since every developer could create their own branches to manage this requirement.
In our environment, a number of bugs have turned up in TFS version control where files that had actually been changed where not recorded as such, and in few cases files were reverted to an earlier version without notice. This really shouldn't happen in a version control system!
Team Foundation Server is a full Application Lifecycle Management suite. If you have a Professional, Premium, or Ultimate version of Visual Studio 2010 with an MSDN subscription, Team Foundation Server 2010 is now free. All of your Visual Studio users that fall under that classification, as well, and do not require an additional CAL. Other users, however, will require that you purchase CALs to stay compliant with the license.
Using Team Foundation Server 2010, you will get source control, process management, defect tracking, build services, reporting, project portals, and more. SVN is strictly source control. I have used both, and they are different beasts. It would be fair to say that the type of features offered by SVN are a subset of Team Foundation Server, on the whole. While there are third party connectors to make it easier to work with SVN inside of Visual Studio (free, I believe - as well), the native integration between Visual Studio and Team Foundation Server is fairly seamless. From an administrative standpoint, both on the server and project level, you have an excellent balance of ease of use and features.
For the last three years, or so - between two different employers - I have setup and installed Team Foundation Server and maintained it over its lifetime. Both companies have used it to their advantage to be able to bring ordered process to their SDLC. The MSF Agile v5 template, if you are an Agile/Scrum shop, is outstanding. Sprint planning and management has never been as easy with any tool as it is now.
Edit - Added information about small teams:
I noticed a comment to the question regarding small teams. Team Foundation Server 2010, given its price point, makes sense for small teams now, as well. I would not have recommended it with Team Foundation Server 2008, though. With the latest version, there is a very nice "Basic" configuration that provides a lightweight installation, sans reporting and portal functionality. You can also install it locally, as well, if you are a "one man shop" with this configuration (Microsoft actually lists it as an acceptable configuration for a client install.) I have it on my laptop for my POC work - having set up a nightly maintenance plan and moving my backup to Dropbox. Works very well for peace of mind. ;-)
Martin Fowler has an interesting post about this topic on his website.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I'm interviewing this week for a position at a firm where I would be the sole initial developerplus support the application I am taking over work for. Because positions like this can vary so wildly in the details, I plan to go in advocating a number of specific approaches that would make the job workable.
One thing that I'm considering bringing up is an inclination to move the existing source code out of SourceSafe (where it is currently resident) into a better version control product like Perforce.
I've had a number of bad experiences with SourceSafe causing massive problems like permanent file lock-out and code corruption. Alone, I'm afraid that those anecdotes sound like "I want to change it because I don't like it." If I'm going to bring the subject up, I want to have a slam dunk case.
So, what are the empirical reasons that SourceSafe is viewed as an inferior product?
See also:
Any Real-Life Visual Source Safe Horror Stories
How do I convince my team to drop sourcesafe and move to SVN?
Empirically, it makes no sense to trust your precious source code to a piece of software that isn't even up to the level of reliability as Microsoft Access. The product should have been dumped years ago. It's just not up to modern standards.
I'd rate it below any open source product like CVS or SVN, and I don't know of any product I'd rate below it, except maybe an older version of VSS.
There's a long list of problems here (admittedly from 2002 but the product hasn't really changed since then)
Edit: here's the text from the link, in case it disappears. Page is licensed under CCA3.
Visual SourceSafe: Microsoft's Source Destruction System
by Alan De Smet
There are many fine solutions for revision control systems.
SourceSafe isn't
one of them.
I used SourceSafe for five years though spring 2002 . It has consistently
been an unpleasant experience. New versions failed to improve anything of import.
I hope to dissuade you from using SourceSafe,
sparing you the bad experiences I have had.
Missing Features
SourceSafe lacks usable branching support
A revision control system should provide powerful branching
support. With strong branching support, developers can easily
make minor revisions of old versions while work toward the next
major release continues. Highly experimental code can be checked
into a branch, keeping it separate from mainstream development
but backing it up and making it available to other developers.
If the project is "frozen" while a milestone or final release is
built, a developer can continue development toward the next
version on a branch. (Or more commonly, a new branch can be
created for the freeze while general development continues on the
main branch. When the release is done, changes on the frozen
branch can be merged back into the main branch.) SourceSafe's
branching support fails to effectively support any of this.
With powerful branching, a revision control system must
also provide strong merging support to reconcile different
branches. At the least, the system must allow a developer to
examine the differences between two branches, modify them to
create a merged version, and when satisfied check them in.
SourceSafe's merge support is tightly integrated with checking
in, making it difficult to examine differences and test the
proposed merge before checking it into the tree. With this weak
level of support, it's easy to check non-functioning code into
the revision control system.
SourceSafe cannot be safely extended
It should be possible to easily extend your revision control
system with additional functionality. The ability to send out
emails summarizing check-ins is essential. When working with a
team, regular email messages listing files checked in and the
check in messages associated with them really help keep everyone
up to date with recent changes. You might also want to add
filters to prevent check-ins of code that doesn't meet certain
requirements (standard copyright statements or doesn't compile).
SourceSafe barely supports this. While it is possible, every single
client needs to have the additional functionality installed. If
a single client lacks the extension, it will quietly fail to
behave as expected.
(For details, see
Visual SourceSafe 6.0 Automation.
Check the section "Trapping SourceSafe Events? An Overview".) You can
pay even
more for a third party solution, but does it make sense to
invest more money in a fundamentally broken product?
SourceSafe silently leaves stale files on your local system
When updating your local workspace to match the server, files
which were deleted on the server should brought to your
attention. (Or deleted, since the old version can be retrieved
from the revision control system.) Failure to do so risks out of
date files being used in your project, often causing problems.
I've frequently run into this problem when an out of date header
file is incorrectly included into my project. SourceSafe fails
to delete the out of date file or provide any warning.
SourceSafe badly handles slow networks and the public internet
SourceSafe is unusable over slow network connections. It's
effectively unusable over the public internet. In addition,
because SourceSafe works over network shares, if you place a
SourceSafe server on the internet, you're exposing any weaknesses
in your servers file sharing implementation to the entire world.
Of course, if
you're willing to invest more money in your ineffective revision
control system, you can buy a third party
product to solve this problem.
Managing third party modules is difficult with SourceSafe
It's not uncommon for a developer to use third party modules
in your project to quickly add required functionality. For
example, you might use Codejock Software's Xtreme
Toolkit. It's natural to check these third party modules
into your revision control system. This way, when you step
backward in time to examine a previous revision, you can get the
same versions of supporting libraries and third party modules
that were used to build your code at this time.
Unfortunately, SourceSafe makes tracking a third party module
extremely difficult. Initially checking the first version in
isn't hard. Checking a new version in requires a good memory and
attention to detail. To add a new version, you first recursively
check the folder holding the module out. Now delete the
directory on disk and replace it with the new version. Check in
new version in. You now need to identify any files or
directories added in the new version. Right click on the
module's folder in SourceSafe and use "Show difference" to
recursively generate a list of files which have been added. Note
which directories hold files which have been added and which
directories have been added. Now close the report of differences
(the report is modal, preventing you from using SourceSafe while
visible). Add the new directories as you would normally add
directories. To add the new files, visit each directory holding
new files and use File > Add Files to add them. Again, use the
"Show difference" command to recursively generate a list of files
which have been removed. Note these files and close the the
report of differences again. Now delete each of these files in
SourceSafe.
If you've actually tweaked the third party module, SourceSafe
provides no particular help in tracking down the differences and
merging them into the new version.
(For comparison, to check in a new version of a third party
module using CVS, you would
simply run the command "cvs -q import -m 'Import of Xtreme
Toolkit 1.9' xtremetoolkit Codejock XT_1_9". That's it. If
you've made changes to the module that need to be integrated, you
would use "cvs checkout -j XT_1_8 -j XT_1_9
xtremetoolkit". That will give you a local copy of the
merged changes which you can immediately check in if
satisfactory.))
Viewing and retrieving historical versions is extremely
slow
It's not unusual to need to get a historical version of the
source code. You might need an older version to investigate a
bug report, or the current code is malfunctioning and you need to
get a functioning version. SourceSafe supports this, but it's
extremely slow for non-trivial projects. To get a historical
version, you first need to generate a history for the entire
project you're interested in. On a project with hundreds of
files and just over one year of history, this can easily take
over five minutes (even if you restrict the actual search to the
last 48 hours of changes). Once this history is generated, you
specify the version to get by selecting the last check-in to
accept. The slow speed at which this process is completed
discourages developers from examining previous versions,
defeating much the purpose of a revision control system.
Difficult to maintain multiple local copies of one
project
While making extensive changes to a copy of the project, you
may be asked to make a small change to the project. The most
efficient and safest way to do this is to get another copy of the
project to make the change on. SourceSafe presents two problems
in doing so. First, SourceSafe only recognizes a single copy of
the project on your system. You'll need to either move the
project directories back where SourceSafe expects the canonical
copy, or you'll need to reset SourceSafe's notion of where the
canonical copy exists. Using either technique, it's easy to
accidentally point SourceSafe at the wrong project and check the
wrong versions of files in. Secondly, SourceSafe's weak merging
features mean that if you need to change the same file in both
copies of the project, you'll need to be very careful that
changes to one project don't destroy changes in the other.
Safety
SourceSafe degrades on large projects
Microsoft recommends that your database not exceed 5 GB.
(Source: Microsoft Best Practices)
While this is a large database, it's not unreasonable for a large
project, especially if you check in large binary files (like
Microsoft Word documents).
SourceSafe integration can crash Visual Studio
SourceSafe can hang or crash when your system loses connection
to the SourceSafe database. While this is irritating for Visual
SourceSafe, this can cause you to lose work when Visual Studio is
using SourceSafe integration. Simple having a SourceSafe managed
project open in Visual Studio is enough to open yourself to the
risk. To minimize this risk (and speed up ClassView), I suggest
you
follow
Microsoft's directions on disabling SourceSafe integration.
SourceSafe relies on dangerous file sharing
SourceSafe doesn't really run as a server, but as a set of
files shared over SMB. As a result, you're relying on each
individual client to not misbehave. A single misbehaving
computer can destroy the database. A problem in the file sharing
implementation on your operating system can damage the database. Users only needing read-only
access to the revision control system need write access to the
server, increasing the risk (Required Network Rights for the SourceSafe Directories).
SourceSafe should be scanned for corruption weekly
Of course, with this high risk of corruption,
Microsoft recommends that you run the Analyze diagnostic program
weekly.
(Source: Microsoft Best Practices)
While Analyze is running all of your developers are
locked
out of the system (I hope everyone remembered to quit from
SourceSafe first!). My experience with SourceSafe shows
that a 2 gigabyte system running under Windows 2000 takes several
hours to check if run weekly.
SourceSafe handles multiple time zones badly
If you have teams using the same SourceSafe repository in
different time zones, you're likely to have problems. (See
Microsoft's details on the time zone bug.) The only solutions
Microsoft provides are to incorrectly set the clocks of the
computers to a single time zone, or to purchase a third party
product.
Relatedly, this is a potential problem if any of the client
computers using SourceSafe fail to have synchronized clocks.
Differences of several minutes between computers can cause
strange behavior from SourceSafe with it tries to reconcile
information that appears to come from the future.
SourceSafe becomes corrupted
Your revision control system must be trustworthy. You're
entrusting your hard work to your revision control system. If
your data is corrupted, the system is worthless. SourceSafe's
fundamental design assumes that clients are trustworthy, always
function correctly, and that nothing interferes with the
communication causing corrupted data. As a result, SourceSafe is
fragile and untrustworthy. I have worked with SourceSafe at
three different jobs. In each case, eventually the SourceSafe
database became corrupted. Data has been corrupted, work has
been lost, time has been wasted on the problem. Speaking with
other developers, I have learned that my experiences are not
unique.
Irritations
Minor actions like changing the directory erase the entire
contents of the output window, making it difficult to examine past
actions.
Comparing your local version to the remote repository is
clumsy. You select the directory you're interested in SourceSafe
and select Compare Differences. The resulting report is modal,
preventing you from working with SourceSafe while examining the
report.
When getting the latest version of files from SourceSafe,
each file changed locally causes a dialog to pop up to confirm
the update. The update action entirely stops while the dialog
waits for your response. This is particularly irritating if you
get the latest version, step away from your computer for a while,
then return to discover that SourceSafe is only 10% done and
waiting for your response. You can prevent the dialog from
returning in several ways, but in doing so you get no
indication that any such files were encountered. So when you
return to the finished update, you will have no idea that
SourceSafe encountered potential problems. SourceSafe should
note these files in the output window when encountered, making it
easy to scan the output window for files to be investigated.
Conclusion
If you're considering SourceSafe, consider something else. If
you're using SourceSafe now, migrate away as soon as possible.
Here are just a few.
If you simply must use SourceSafe, definitely take the time to
look at Microsoft's list
of bugs in Visual SourceSafe 6.0 and list
of fixed bugs in Visual SourceSafe 6.0 so you know what to
expect. (These links were originally taken from Microsoft's Bugs page.
This page may be useful if you have a different version of
SourceSafe or the above links fail.)
The big one that I've experienced personally is database corruption. It happens and it is painful. Aside from that, it's pretty slow compared to more modern SCMs.
If I were you, I'd recommend moving to at least TFS. The integration with VisualStudio is just as tight, it is much speedier, and the idiom is pretty much the same. I've had no problems with it in the 4 years I've been using it. Perforce is expensive and that's probably not something to toss around in an interview.
Back in 2002/2003 in a former job, I ended up being the guy who had to babysit our VSS installation.
We gave VSS it's own dedicated server - real physical hardware - in order to minimize disruptions, and still we had regular problems.
Once a week I had to go and fix broken locks - locks that couldn't be released by the developer who placed them.
Around twice a year I had to recover from a corrupted repository - there seemed to be some kind of built-in limit at around the 1G mark, whenever the repository grew much past 1G things went bad pretty quickly.
Given that there are better tools - with better integrations - that are now available at zero-cost, switching from VSS (to me) is a no-brainer.
I agree that VSS is a horrible piece of software but other than the possible database corruption problem, it seems like your situation will be a difficult one to sell people on. For example, you can't say VSS has terrible merge support because, well, you're the only developer. You can't complain about locking checkouts for the same reason. Unless your app is pretty good sized, you can't argue from the suggested 1 GB maximum database size that VSS suggests.
I personally think that in an interview like you're suggesting, you'd be better off looking for lower hanging fruit to suggest like iterative development, TDD or a wiki for documentation. I have fought the good fight to move from VSS to Perforce in an enterprise situation and that was hard enough. I can't imagine trying to convince management of a major source control change on an application that has one developer. YMMV.
SourceSafe is an antiquated technology built upon Windows shares. The storage mechanism (non-transactional "flat files") is a recipe for poor performance and bugs. Its adoption has nothing to do with what it has over other SCM's, and everything to do with the fact that it was "already there".
I can't comment on Perforce, but I can say that VSS compared to, say, Team Foundation Server is a very weak offering and should be used only in circumstances where there is already a large investment in it and NO money can be spent.
Microsoft does not use it internally. Instead, they got a source license to Perforce, and they've hacked it up to suit their needs. This is telling, since Microsoft proudly dogfoods their other products, like Windows and Office.
My last experience with Sourcesafe was years ago, so take this with a grain of salt. In my experience, it doesn't scale well as the number of developers touching the same code goes up.
There is no way to have multiple people working on the same code, and then merging their changes together on check-in. Instead, each developer has to lock the files they are working on, while the other developers can't make progress on anything touching those same files.
Because it makes your source unsafe even when in repository.
The issue I'm wreslting with now is Visual Source Safe's insistence that my project's folder structure cannot possibly be represented within the target working directory. It always thinks that a service setup project is trying to encroach on the service project and refuses to check it in. When you add a project to source control, it invariably adds another folder to its path in source control. Version control should just represent a file structure that is ALREADY WORKING on a developer's machine, without complaint.
See also Better SCM Initiative: Version Control Systems to Avoid.
One of the issues that I have read there, and I haven't seen mentioned so far in the answers, is that VSS has no support for deleted then recreated files: either you purge history of file (and can never recover old version), or you can create file with the same name as some deleted file had. Even CVS (which is also file-based) tried to did this right by using 'Attic' area.
Code Corruption (including your entire history stack)
Binary file corruption (we had this issue specifically with PDF templates)
Poor integration into Visual Studio IDE (very buggy)
Constant file lockouts
Did i forget to mention repository corruption...eeek
No branching
I can go on and on. The bottom line is to absolutely avoid this product. I think it may go well with smaller projects, but developing enterprise level applications should not involve dealing with constant codebase repository issues.
We have a small 3 developer team that is currently using Subversion for our source control. We expect the team to group to 8 members within the next 6 to 12 months. We are considering changing our source control to either TFS or Mercurial for improved branching. I know TFS is overkill for just branching, but that is the immediate need, and the other features of TFS could aid our team. One of our main concerns with TFS is we've heard that there is a lot of overhead deploying it, especially on a small team. I'm hoping to get some community insight into just how much overhead there may be involved, suggestions to make the process easier, and anything else the community may feel is useful in making the decision to implement.
In my experience, TFS works really well, even for small teams. If your total number of developers is five or less, you can use the relatively affordable Workgroup edition: above that, you'll have to pony up for the real thing, pricing for which is definitely in the 'Enterprise' realm...
The biggest hurdle to starting to use TFS is installing the darn thing: this process seems to be designed for maximum aggravation. (The extent to which the 'designers' of the 2005-to-2008 upgrade 'process' despise their users even manages to go beyond that: fortunately, you'll be able to start with TFS2008 and won't have to worry about upgrading for a while).
If you follow the instructions exactly, you should manage in 2-3 tries, though, and the hardware requirements aren't as bad as they seem. My 3-developer TFS setup runs quite comfortable on a previous-generation Dell laptop with 4GB of RAM.
One of the big advantages of TFS is the VS integration: this works just really, really well, and shelving and branching are implemented in a more straightforward way than with any other systems I've seen.
The process guidance and support in TFS are a bit less polished, but still quite usable. The pluggable support for several development methodologies is quite nice, and several third-party add-ons (for example for Scrum) are available already.
All in all, it definitely won't hurt to try TFS: if you have a MSDN subscription, you probably already have the Workgroup edition as well as a trial of the full version: otherwise, you can downloaded the latter from Microsoft as well.
UPDATE, April 12th, 2010: With the release of Team Foundation Server 2010, the installation and upgrade procedures have improved a lot. A new TFS2010 install shouldn't take you more than a few minutes (assuming you already have an instance of SQL Server 2008 up and running) and even an in-place upgrade of my TFS2008 setup proved to be entirely painless.
Setup of TFS is not too complicated, when you exactly follow the given guide step by step. We are using it on a small team for about one year now and i don't want to miss it any more.
Especially when you use more than one part of tfs like version control and work item tracking and maybe even teambuild, your team will benefit of the tight integration of the seperate parts.
For example, you can link to workitems when checking in code changes.
Then you run an automated build with teambuild and it will automatically update your workitems with the build number.
So afterwards you can see for example in a bug workitem the buildnumber which contains the bugfix.
We also use the sharepoint wiki for documentation and planning although i'm not the biggest sharepoint fan...
The main point is the great integration into the IDE and for workitem tracking the Teamsystem Web Access which allows you to control at least your workitems over a webinterface.
It's been awhile, but I'm thinking that it takes about a half-day to get setup, plus some time reading the manuals beforehand to make sure you know what you're doing. Configuration doesn't take too long -- you need to add all of your developers in as licensed users. Setting up projects is not too hard. I usually set up AD groups to map on the project roles and add those groups to the appropriate roles. I set up a new project in about 1/2 hour.
Note: I don't use any of the features of TFS except source control. If you plan to item tracking, use the project sharepoint site, etc., your mileage will vary quite a bit. I've found that on our projects (2-3 developers) a wiki works just as well for project management.
Around here we have been working with a bunch of Visual Source Safe repositories for about 10 years or so.
Now I want to get rid of sourcesafe and move on to Team Foundation Server.
Do you have any tips or tricks for me before I embark on this migration? What are the things I have to be careful about?
I am sure this migration will mean that our working habits have to be modified in some way. Do you think that these changes could be a problem for the organization? Think about a group of about 20 .NET developers in a single site.
There are a few different ways you can migrate. The tool will pull your history, etc. over, but the more pragmatic and simple way is to lock VSS as a history archive and start fresh:
Have everyone check in all changes into VSS, make sure everything builds, etc.
Set all VSS databases to "locked" (read-only rights for all users)
Get Latest on the entire VSS database into a "clean" set of folders on a workstation
Check all of the files into TFS from the workstation
For any history prior to the conversion, folks need to go to VSS, but after a week or two it's realistically unlikely to happen all that often. And you know that the history in VSS is accurate and not corrupted by the conversion process.
Be aware that TFS does not support sharing files between different projects, as VSS does. If you have any such shared files the link between them will be broken during the migration, resulting in initially identical, but now distinct files in each project. Updates to one of these files in TFS will no longer propagate to the copies in the other projects.
If you do choose to use the VSSConverter.exe tool that ships with Visual Studio Team Foundation Server, then you should install TFS 2008 SP1 first as it includes a number of improvements as detailed on this blog by the migration tools team.
Some of the key features of the
release include:
Elimination of namespace conflicts. I
previously blogged about this as "the
rename problem" and we have fixed the
converter to correctly migrate files
with overlapping namespaces. This was
the biggest pain point for most users
trying to use previous versions of the
tool.
Automatic solution rebinding.
In this latest version, VS solution
files will be automatically upgraded
to the 9.0 version and checked back in
to version control. Previously users
were required to do this manually.
Correcting of timestamp
inconsistencies. The use of client
timestamps by VSS can lead to
revisions being recorded in the
opposite order that they actually
occurred in. The tool now recognizes
this issue and continues migrating
changes where it would previously
fail.
Improved logging. Although
we've fixed a lot of issues, providing
better, more detailed logging will
help users that do run into issues
diagnose the problems.
I just googled, but this walkthrough seems like a good reference, and it mentions the tool VSSConverter which should help you make the migration as painless as possible.
I would like to recommend one thing though: Backup. Backup everything before you do this. Should anything go wrong it's better to be safe than sorry.
My links aren't showing up. This is the address: http://msdn.microsoft.com/en-us/library/ms181247(VS.80).aspx
We are currently in the process of doing this at my day job. We are actually making the switch over in about a month. I am a main part of the migration and a big part of why we are getting off of SourceSafe. To help in the migration, I used the Visual Studio® Team System 2008 Team Foundation Server and Team Suite VPC Image. It was very useful. Right off the bat, the image contains a full working TFS installation for you to play and demo with. It also includes Hands on Labs and one of the labs is running the VSS -> TFS migration tool. If you have an MSDN subscription, once you have played with the image, the next step would be to install the TFS Small Team edition that comes with your subscription.
One thing to note is to make sure you get the latest Service Packs for Visual Studio 2008 and the .NET Framework installed on the image. The service packs fixed some annoying bugs and it definately increased the usability of the system. We have a farely large SourceSafe database with about 90+ projects and the migration tool took about 32 hours to complete. First I made a backup of our sourcesafe database for testing. Then I made the migration on the test sourcesafe database. Afterwards, I checked the source tree in TFS and everything transferred fine. We kept all the history for our source files from VSS which was great. No need to keep that stinking VSS database around after we go live.
We are taking the migration in steps. First the source control and letting our developers get use to using it. Then after that we will be migrating the QA and Business Analysts over to use the Work Item tracking features.
My advice is to take the migration in steps. Don't do too much at one time. Give time for people who will be using the system to train up.
VSS Converter is a far from perfect solution. And there are significant differences between the 2005 and the 2008SP1 version of the converter.
For example, in a VSS DB that's been in use for a long time, there will have been a large number of users contributing to VSS. Many of these users will have left the organisation a long time ago and therefore will no longer have domain accounts. TFS requires mapping VSS users to domain accounts, so you will have to decide whether you map old users to a single 'dummy' domain account or to a current team member.
In addition, VSS Converter 2008 requires these domain accounts to be valid TFS accounts. Whereas the 2005 converter does not enforce this.
If your VSS history contains significant folder Moves, then it's likely you will loose all history before this Move. For example, if you Move a folder to a new location, then Delete the previous parent, you will loose all history. See this article for more explanation:
http://msdn.microsoft.com/en-us/library/ms253166.aspx
In one migration I was involved with, we had a 10 year old VSS database that lost all history prior to 6 months ago. This was due to a significant tidy up that took place 6 months ago.
TFS conversion tool <-- Use this
I've used this tool for some times already, the results are pretty satisfatory as it comes with the history of changesets from SourceSafe if you desire too.
Anyway, using this tool you should always pay attention to errors and warnings in the log, and check if everything built okay / passed okay.
It's recomended to also run an Analysis on SS before running this.
Hope it helps
Good guidance there from my former colleage Guy Starbuck. Another thing to add with that approach - you may have decided over time that you want to refactor the way your application is organized (folders etc) and this will give you an oppurtunity to do so.
I've been in situations where we organized a solution haphazardly without thought (let alone major changes in the application) which led to a desire to organize things differently - and the move from VSS to TFS is a great oppurtunity to do so.
As far as the original question:
And: this migration will for sure mean that our working habits have to be modified in some way. Do you think that this changes could be a problem for the organization? Think to a group of about 20 .net developers, in a single site
I would say - yes your working habits will change but much more for the better.
You no should use "Check-out" Locks and "Get-Latest on Check-out".
You can now effectively Branch and Merge
You will now have "Changesets" all files checked-in at the same time will be grouped together. This makes historical change tracking much easier - but more importantly - rollbacks are much easier (ie find all files checked in at the same time and roll them back)
Associating Check-ins to Work Items. Don't overlook Work Items! The biggest mistake you can make is to only use TFS as a VSS replacement. The Build and Project Management features are excellent - you paid for them - USE THEM!
As far as details on how your experience will change, another former colleague of mine (and Team System MVP) Steve St. Jean wrote a detailed article on the differences: From VSS to TFS
I've been programming for 10+ years now for the same employer and only source code control we've ever used is VSS. (Sorry - That's what they had when I started). There's only ever been a few of us; two right now and we usually work alone, so VSS has worked ok for us. So, I have two questions: 1) Should we switch to something else like subversion, git, TFS, etc what exactly and why (please)? 2) Am I beyond all hope and destined to eternal damnation because VSS has corrupted me (as Jeff says) ?
Wow - thanks for all the great responses!
It sounds like I should clearify a few things. We are a MS shop (Gold parntner) and we mostly do VB, ASP.NET, SQL Server, sharepoint & Biztalk work. I have CS degree so I've done x86 assembly C, C++ on DEC Unix and Slackware Linux in a "time out of mind" ...
My concern with VSS is that now I'm working over a VPN a lot more and VSS's performance sux and I'm afraid that our 10+ y/o version 5 VSS database is going to get hoosed...
There's the LAN service that's supposed to speed things up, but Ive never used it and I'm not sure it helps with corruption - has anyone used the VSS LAN service? (new with VSS 2005)
I'd probably go with Subversion, if I were you. I'm a total Git fanatic at this point, but Subversion certainly has some advantages:
simplicity
abundance of interoperable tools
active and supportive community
portable
Has really nice Windows shell integration
integrates with visual studio (I think - but surely through a third party)
Git has many, many other advantages, but the above tend to be the ones people care about when asking general questions like the above.
Edit: the company I now work for is using VisualSVN server, which is free. It makes setting up a Subversion repository on a Windows server stupid simple, and on the client we're using TortoiseSVN (for shell integration) and AnkhSVN for Visual Studio support. It's quite good, and should be fairly easy for even VSS users to pick up.
Latter-day Edit: So....nearly eight years later, I would never recommend Subversion to anyone for any reason. I don't really recant, per se, because I think my advice was valid at the time. However, in 2016, Subversion retains almost none of the advantages it used to have over Git. The tooling for Git is superior to (and much more diverse) what it once was, and in particular, there's GitHub and other good Git hosting providers (BitBucket, Beanstalk, Visual Studio Online, just off the top of my head). Visual Studio now has Git support out-of-the-box, and it's actually pretty good. There are even PowerShell modules to give a more native Windows experience to denizens of the console. Git is even easier to set up and use than Subversion and doesn't require a server component. Git has become as ubiquitous as any single tool can be, and you really would only be cheating yourself to not use it (unless you just really want to use something not-Git). Don't misunderstand - this isn't me hating on Subversion, but rather me recognizing that it's a tool from another time, rather like a straight razor for shaving.
Looks like SubVersion is the winner here. I'd do yourself a favor and use VisualSVN Server. It's free and will save you a bunch of installation headaches.
If you're used to the way VSS works, check out (no pun intended) Sourcegear's vault. It's an excellent way to migrate away from VSS as it comes with IDE integration and supports check out / check in, but when you're ready and feel comfortable you can also move to the edit update commit style of programming found in SVN.
It's free for single developers, runs on IIS and is built on .net so it should be a fairly familiar stack for you to switch to.
Whatever you do, don't change for the sake of changing.
If it's working for you and you're not having problems with it, I don't see any reason to switch.
For what it's worth, Perforce is a potential option if you truly stick to 1 or 2 users. Current perforce docs says you have have 2 users and 5 clients without having to start purchasing licenses.
You might have reasons to switch to perforce depending on your workflow and if you have need of branching the way perforce does it. Not being overly familar with some the other products mentioned here, I can't tell you how perforce compares in the feature department for things like branching, etc.
It is speedy, and it's been rock solid for us (300+ developers on a 10+ year old codebase). We store several T of info and it's been quite responsive. With a small number of users, I doubt that you'd experience many performance troubles assuming you had good hardware for your server.
Having used VSS before, I believe that you can get so many benefits out of a better SCM system that switching should be considered regardless of whether you have corruption or not. Branching alone might be worth it for you. A true client/server model, better interfaces (programmatically and command line) are a couple of other things that could really help just improve your workflow and help somewhat with productivity.
In summary, my view of Perforce is:
It's fast and quite reliable
Plenty of cross platform client tools (windows, unix, mac, etc)
it's free for 2 users and 5 clients
Integrates into developer studio (and other tools)
Has a powerful branching system (that might or might not be right for you).
Has several scriptable interfaces (python, perl, ruby, C++)
Certainly YMMV -- I only offer this alternative up as something that might be worthwhile looking into.
I've recently started using Mercurial for some of my work. It's a distributed system like Git but seems easier to use and seems far better supported on Windows, the latter of which was crucial for me.
With distributed source code control every user has a complete local copy of the repository. If you're the only person working on a project, as you say you often are, this can simplify things a lot since you just create your own repository and do all your commits etc. locally. If you want to bring on other developers later you can just push the full contents of your repository - current versions and all history - to another system, either on a shared server or directly on to another users' workstation.
If you're working only with a local repository remember you'll need a also backup solution as there isn't a copy of all your code on a shared server.
I think that Mercurial has lots of other advantages over Subversion, but it does have a big downside which has already been mentioned as a plus point of Subversion: there a lots of third party tools and integrations for Subversion. As Mercurial hasn't been around nearly as ong the choice is much less. On Windows it seems that you either have to use the command line (my choice) or the TortoiseHg Windows Explorer integration.
VSS is horrible. I may be channelling Spolsky (not sure if he's said this), but using VSS is actually worse than not using source control at all. Despite its name, it isn't safe. It creates the illusion of safety without providing it.
Without VSS, you'd probably be making regular backups of your code. With VSS, you'll think, "Mehh, it's already under source control. Why bother backing up?" Great until it corrupts your entire codebase and you lose everything. (This, incidentally, happened at a company I worked at.)
Get rid of VSS as soon as you can and switch to a real source control solution.
Don't worry about VSS corrupting you, worry about VSS corrupting your data. It does not have a good track record in that department.
Back up frequently if you do not switch to a different version control system. Backups should be happening daily even with other SCMs, but it's doubly important with VSS.
I like using Subversion for my personal projects. I could go down the list of features and pretend like it brings a lot to the table that other source control systems don't, but there's tons of good ones out there and the right choices is really a matter of style. If you check in after each small change (i.e. one checkin per function change), then many people can work on the same source file with very low risk of merge conflicts in practically anything but VSS (I haven't used VSS in years but from what I remember only one person at a time can work on a file.) If this isn't ever going to happen to you, I feel like the best course of action is to use what you know. VSS is better than no source control at all, but it feels restrictive to me these days.
I don't think you're beyond hope because you're asking if it would be better to switch; you're beyond hope when the answer is obvious and you ignore the evidence.
Even if you don't change source control systems, you ought to pick one like SVN or git and spend a few weeks reading about it and making a small project using it; it always helps to sharpen the saw.
I don't agree with the people that say that if you don't have problems you'd better not switch.
I think that SCM is some of the disciplines a good developer should know well, and frankly, even if you master VSS you are just experimenting a small fraction of the advantages a good SCM tool and SCM strategy can do for you and for your team.
Obviously evaluate and test the alternatives first in a non-production environment.
At work we use subversion with TortoiseSVN - works very nicely but it is philosophically different to VSS (not really a problem if there's just you but worth being aware of). I really like the fact that the whole repository has a revision number.
Given a free choice I'd've probably gone with vault but at the time I had zero budget.
I'm looking at things for personal use. There are reasons to use subversion and reasons to use something completely different. The alternatives I'm considering are Vault (as before, free for single use) and Bazaar. GIT I've had to dismiss as I am, unashamedly, a Windows person and right now GIT just isn't.
The distributed nature of GIT and the option of private/temporary checkins (assuming I've understood what I've read) is attractive - hence my looking at Bazaar.
Update: I did some more digging and playing and I actually went for Mercurial for personal use, integrated install with TortoiseHg makes things very simple and it seems to be well regarded. I'm still trying to work out how to force an automagic mirror of commits to a server and there appear to be some minor limitations to the ignore function but its doing the job nicely so far...
Murph
I'd say stick with what works for you. Unless you are having issues with VSS, why switch? Subversion is swell, though a little sticky to begin using it. TFS is far better than VSS, though it is fairly expensive for such a small team. I have not used git so I can't really speak to it.
i used vss for years until switching to svn about two years ago. my biggest complaints about vss were the poor network performance (that problem may be solved now) and the pessimistic locking of files. svn solved both those, is easy to set up (i use collabnet server and tortoisesvn client, although there are two good visual studio plugins: visualsvn - commercial, and ankhsvn - open source), easy to use and administer, and well documented.
it's tempting to say "if it's not broken then don't fix it" but you would get to learn a more modern source control tool and, perhaps more importantly, new ways of using source control (e.g. more frequent branching and merging) that the new tool would support.
If you only have 2 people, and you mostly work independantly, git is going to give you a lot more flexibility, power, and be far and away the fastest to work with.
It is however a pain in the backside to use. Using VSS you're obviously programming for windows - if you're doing Win32 API stuff in C then git will be a learning curve but will be quite interesting.
If the depths of your knowledge however only extend to ASP and Visual Basic, just use subversion. Walk before you can run.
** I'm not trying to say if you only know VB you're dumb or anything like that, but that git can be very finicky and picky to use (if you've used the WinAPI in C you know all about picky and finicky), and you may want a more gradual introduction to SCM than git provides
If you are a one man show and strictly a Microsoft shop, then SourceGear Vault is definitely a prime candidate for switching too.
Features:
Free for Single User, great for you
It uses SQL Server for it's backend, therefore data reliability is huge
It has atomic check-ins, all files checked-in at the same time are arranged in a group and are called a changeset.
VisualStudio integration.
Has a tool for importing from SourceSafe, therefore you can keep your history
The client communicates with the server over HTTP, therefore accessing the source outside the office remotely can be setup very easily and performs well, because they only transfer the deltas of the changes being submitted and received. You can use SSL to secure the connection.
I would definately consider this as an option.
If you want a full Life Cycle in one package then you probably want want to look at Visual Studio Team System. It does require a server, but you can get a "Action Pack" from MS that includes all the licencies that you need for "Team Foundation Server Workgroup Edition" from the Partner centre.
With this you will get Bug, Risk and Issue tracking as well as many other features :)
Source Control
Work Item Tracking (Requirements, Bugs, Issues, Risks and Tasks)
Reporting on your project data (Work Item Tracking, Build, Checkins and more in one qube)
Code Analysis
Unit Testing
Load Testing
Performance Analysis
Automated Build