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
Related
We have this huge application that has 18 projects in our source control (VSS).
Whenever we are working on small changes everything is fine because each developer has a set of a few files checked out to himself, and hopefully no one is going to need them until they are checked in (in about 4 to 8 hours).
But when we want to work on big changes a developer keeps so many files checked out for some days and make it hard for others to do their assigned tasks.
Here's a scenario for example:
Last week we wanted to implement a feature that will fetch every list in our application using a paging mechanism. Therefore we should change the UI, business and data access layers.
There's a developer assigned to this task, she's checked out a lot of files, and she's blocking other tasks.
How should we plan to develop these kind of features?
Switch to a better Version Control System. VSS suffers from design issues and its hard lock principles. Subversion is available for free and can be used for large scale application development. Branching and tagging are cheap operations and there is no hard lock.
Your company will definitively live better with Subversion. Try it out!
Server Easy to setup on what system ever (Windows/Linux)
TortoiseSVN Client for Windows that integrates within Windows Explorer
SVN Manual Read at least the first few chapters
There are many other alternatives but VSS is a pain in large scale development. As there is a better free solution available, why stick to a vendor?
If upgrading to a real VCS isn't an option right now, have the person doing the major feature download a local copy of everything and then make his changes outside of version control. Merge it all at once (over a weekend or something in case it gets complicated).
This doesn't help the developer who will need version control while making the "big changes"
Well, you do what you gotta do with the tools you've got. He could always install a modern VCS like git which works locally. Just check the entire baseline into git (minus history) and go.
VSS sucks, migrate to a real SCM, microsoft will probably help you seamlessly upgrade to TFS which doesn't have this problem. Or migrate to any one of FOSS SCMs like subversion, but the transition will probably be harder (but may be cheaper).
Have you considered sharing and branching? Also, you can allow multiple checkouts with users who have experience. In your case of making a large application change, I suggest labeling then creating a branch. If something happens to "big changes", you will not the production version. You can make your quick fixes in the released code then merge them into "big changes" once it is ready. Check the help topic "Sharing and Branching".
Use a version control system that works in merge mode (optimistic), not in lock mode.
Merge mode is optimistic is that it assumes changes will usually not be made in the same place. If it happens in the same place then it is usally easy to resolve.
An example of a version control system that can work in merge mode is CVS. It is outdated now, but others exist.
SVN is the answer to your problems. I have used it and its a breeze to learn/work with it. But there are a few new kids on the block. Try GIT. I have been hearing a lot about it althought havent had a chance to try it
VSS is just an old story, we use Subversion (server) and TortoiseSVN (client) now. (That's just based on our preference)
By the way, migrating to other version control / source control - only - will not solve your team issue. The problem is about communication. If she can't communicate with the others and stay with her habit (working with a lot of files without checking them in), she will put your team down, you must let her know how to work with team using version control. If not, she will put you into "Merge" problems when using Subversion. ^^
You already got the advice about changing to a usable VCS.
Above that, you and the developers should train to break the big changes into smaller ones. I'd consider about 10 commits per day and full time developer a normal rate. It makes the locks much less painful.
The principle should be: make the smallest possible change that brings you toward your desired state and works (as in the software compiles and passes all tests).
In the case you sketched out. Adding a parameter to one layer, and changing all calls to that layer (possibly with a dummy value) would be one change. Actually using that value, would be another change.
This should result in much less files locked for a much shorter period.
Long-term, you'll want to migrate to another VCS. As others have mentioned, consider either open source or TFS if you want to stick with MS. (We use TFS, but I'm not going to sing its praises - it's OK.) As AMissico mentioned, branching will help with any VCS that supports it. Learning to use branching effectively is not trivial, and will require study and/or training.
Continuous Integration will also help. TeamCity is what we use, and it's relatively simple to set up. See FeatureBranch.
We are a small Microsoft shop with 4 developers. We like the idea to have everything integrated and under the same SQL database but not to deal with too many features or a complexity we don't need.
The other option would be to use two distinct third party tools. We also wonder if VS2010 version control and bug/issue tracking capabilities are comparable with the best third party tools on the market.
With TFS 2010, there is a TFS Basic version/configuration options. You can use SQL Server Express as the database, the install is simple and quick and you can install it on a client OS. It includes version system, work items and build system (no sharepoint, reporting...). Price should not be high, the target users for TFS Basic are those used to use SourceSafe. Also if you have MSDN, there is a change that it goes with it, so you would not have to pay extra.
Some thoughts on TFVC in general -- note that I've never used TFVC specifically, but I've been in a similar situation a couple times. My main concern is that it's too little.
TFVC (Team Foundation Version Control) appears to be a client-server version control system. I don't know anybody who hasn't upgraded to DVCS yet. I've never used TFVC but I can't imagine what benefits it'd offer to outweigh the architectural disadvantage. (And before you ask: I only use it from my workstation in the office, where the network has never gone down, but I still use its distributed features every day.)
I also work at a small Microsoft shop with 4 developers and we have never once regretted using Mercurial. It's one of the few decisions we made that everybody seems to have loved. It's one of those moves, like switching to a language with GC, that you never want to even think about reversing.
In terms of support, I hope you found some way to get great support from Microsoft. Things will come up with any VCS and it looks like community support is a couple orders of magnitude worse than Hg or Git.
I can't say much about bug trackers -- I think they're all pretty much the same these days. I've installed a couple open-source ones in an afternoon, even with no experience. The major difference seems to be, if you go with a big-name one, you'll be able to find lots of tools and extensions that work with it. For example, there are a million and one extensions for reporting/testing/etc. for Bugzilla. TFS probably has similar things, for enough money.
Two other things I'd keep in mind:
First, even if you only want these 2 features today, you will want other features in the future, and it will be (sooner or later) something Microsoft doesn't offer. So it's best to make peace with 3rd-party tools ASAP.
Second, unless you miraculously happen to pick the perfect set of tools for your company's future growth for all time, you will at some point want to migrate away from whatever solution you pick today. So make sure it either provides a way to do a full export, or is popular enough that other projects are falling over themselves to write importers for it.
I guess this all sounds kind of negative for TFS. I didn't really mean it that way -- I'm sure it does some things really well. But unless you're rolling in dough already, save your money.
Good luck with whatever you choose!
TFS work ittm tracking is awesome. Whatever your workflow is and the information you want to gather, you can do it easily with TFS.
Most expect TFS to do what they do out of the box as if it were omniscient. Unfortunately, you do things slightly differently than me and I from everyone else. The key is making it easy for the many different roles in your organization to get and input information into whatever your work tracking system is.
There is a plateau you will reach with custom, cobbled together tools that you won't get from cross referencing information along the product development process. TFS removes that barrier. The second barrier is knowing how to consume the information and that takes training and experience in effectively managing projects.
TFS Version control is certainly the low point when compared to the industry right now. DVCS popularity exploded about the time TFS came out. That said, Brian Harry has stated that TFS "fully expect that we will be adding distributed version control to TFS." http://blogs.msdn.com/bharry/archive/2010/01/27/codeplex-now-supports-mercurial.aspx
Take that as you will.
TFS is a great system but after having deployed and used it for some time I realize that the TCO is just too high to justify for a small team.
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.
There are about 200 projects in cvs and at least 100 projects in vss. Some are inactive code in maintenance mode. Some are legacy apps. Some are old apps no longer in use. About 10% are in active development. The plan is to move everything to perforce my end of year 2009.
Has anyone done a large migration like this?
Has anyone come across best practices for moving from cvs to perforce? Or a similar migration. Any gotchas to look out for?
On the VSS side, there are conversion tools that are available to help with migration. They can mostly maintain version history (there are caveats that are explained in the readme and docs). I have migrated well over 50 VSS projcts into perforce using the VSS to perforce tool. Getting the data out of VSS can be a bit finicky and not terribly speedy, but it works. If you have direct access to the disks (i.e. not over a network share) to the VSS repository, the conversion can go much quicker. You can find information about the scripts here.
There is a simlar page for CVS to perforce conversion here, although I don't have direct experience with that. These links are good places to start. You can also search through the Perforce mailing lists at the Perforce Knowledge Base located here. I'm pretty sure that you might find some conversion information in the mailing list archives.
Migrate your old projects first. You can make sure that your process works. When we migrated active code to Perforce, I took one weekend and basically took down access to the servers and moved the code over to Perforce. Honestly, it was a pretty easy migration and when people came back on Monday they were ready to go. You might think about preparing your employees with Perforce cheat sheets after you start doing the migration.
The biggest gotchas might actually be preparing your people to use Perforce. Had I done it over again, I would have migrated our smaller active projects first and prepared smaller numbers of people to use Perforce at once. As it was, I had to train 120+ people on day 1 after the migration and that was a bit much. Also, make sure that you don't have 100+ people hitting your server for a fresh sync on day 1 either. We wound up taking our server down multiple times during the first few days. We used a windows 32 bit server which I would not recommend. We have a windows 64bit server now and it's much more robust. If you can, I would actually use Linux as your OS for your perforce server. Again, there should be good info on the Perforce site about performance.
I haven't had to do something of this scale, but I have a few ideas. First off, start by taking a small, unimportant project, and migrate that. That will give you an idea of how much trouble it is going to take to migrate the rest of the projects. Immediately after that you should choose a medium size project as there may be issues with migrating a larger project (say with branches) that might not be apparent on a small project.
Make sure you spend a bit of time seeing how easy it is to convert cvs projects to vss, or the other way around. If converting from vss to perforce is a real pain, you can convert vss to cvs, and then to perforce. Don't sink days into it, but it could back you out of a sticky situation. I think the key here is go incremental.
Backups are good. Period.
Consider a cutoff date, and any projects that are inactive, and older then that, should be mothballed. Check out the final revision and store that in Perforce. Do you really need 15 yearold visual basic code?
What ever you do, keep the old repositories in read-only mode some where.
Forgive my answering a question with a question, but doesn't Perforce provide tools for this? Or, at the very least, documentation? I'd be beating up my Perforce salesperson...
Consider not migrating dead and inactive projects. Simply put their repositories in read-only mode. The data will still be available if needed and you save the time effort of migrating them. Just migrate the 10% that are in use. Document the process thoroughly.
If one of the un-migrated projects gets resurrected some time in the future you can easily migrate it using your documentation as a reference.
We migrated our svn repository with a tool that we wrote, and just took the head revision of our starteam projects.
Watch out for differences between single-file checkins (CVS) and multi-file changesets (Perforce).
Watch out for branches is separate space (CVS) vs. branches in filepath-space (Perforce).