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.
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.
I've just joined a new company and at the moment we're using Microsoft SourceSafe as our repository. The settings aren't ideal and it's proving to be a big pain in the neck.
I've recently used Mercurial and thought it was amazing, so I'm advocating switching to that, but it looks like the company already has a Team Foundation Server licence and wants to use that instead.
Can anyone give me a list of points where one is better than the other? I've not used TFS and so I don't know what it's good/bad at.
You cannot directly compare TFS and a DVCS.
If your company leans toward TFS, that may be because of the other features TFS comes with (data collection, reporting, and project tracking, all well integrated with Microsoft products)
On the pure Version-Control side, the Team Foundation Server 2010, with its Team Foundation Version Control (TFVC) 2010, introduces branches as first-class citizen.
See Team Foundation Server and branching characteristics, compared to others.
I still find their branching models more complex than a Mercurial or Git one.
See TFS2010 Branching into a subfolder of another branch vs. Guide to Branching Model in Mercurial (and this SO question which also details merges and branches with DVCS)
That being said, it remains a CVCS (Centralized VCS), meaning you get different working processes than with a DVCS: see Describe your workflow of using version control (VCS or DVCS).
The true killer feature of a DVCS remains its merge capability (simpler and faster than any CVCS).
But introducing a DVCS in a corporate environment remains hard.
I recommend Joel on Software http://hginit.com for a list of very good reasons to switch to distributed version control.
I have found a few gotchas with TFS that make it a little different than other CVCS.
TFS is very difficult to use outside of Visual Studio. Even diffing versions is done inside VS. Personally I only like to use VS for writing code.
We have had lots of issues with dll's and other binary files not updating to the latest version.
TFS makes all your files under version control read-only. This makes modifying files outside of VS very painful. In fact, this is still causing issues with out Silverlight projects in our Continuous Integration build in TFS.
The command line tool for TFS is not easy to use from the command line. (Personally, I like to use the command line)
Background:
My company switched from SVN and TFS and I use Mercurial/Git for my side projects. I also followed this blog about using Mercurial with TFS and it has made my work with TFS much more enjoyable.
TFS is an Application Lifecylce Management Tool not ONLY a source code repository / versioning system.
It's strength's are:
-It's natural integration into Visual Studio (+100)
-It's Full App Lifecycle support from Work Item through Q/A acceptance.
-It's integration with MS Project / Sharepoint, and all the other
hoo-ha's you get
-And now TFS 2012 has added support for "Local Workspaces" which allows
for off-line working, but also allows "Server Workspaces" which is
similiar to TFS 2010.
-Diff on every Check-in / Commit
The Source control side of it is also very strong, however, personally, as long as I can see the entire history, not lose code, and not have my code "stepped on". I could give a darn.
I've been using TFS since 2008 and the latest round of improvement further demonstrates Microsofts commitments to evolving their products and keeping up with industry changes. Personally I love it, but i stay in the Microsoft environment (which i also love).. outside of that, it may not work with everyone's needs.
Now, a few days into working with Mercurial professionally (BitBucket / Mercurial / tortoiseHG / VisualHG ) , i have to say the tools seem a bit dated. The integration with Visual Studio is like luke warm coffee (ho-hum), and the explorer integration takes me back to "the good ol days" when i was lucky to NOT be working on Visual Source Safe.
Another thing to take note of is the ease in migrating from Visual Source Safe into TFS, it's fairly painless.. i recently moved my last companies entire history in VSS into TFS and it just took a couple command line utils and overnight to get all the change history moved over. I was shocked (as where my colleagues) at how easy the migration was, it even kept all the history since the beginning (by request of the powers that be)
I'm definitely biased having worked with MS tools for a long time, but there's not much to source control as long as it works..
If your organization wants to truly manage all aspects of application development, and they haven't got integrated tools or processes yet, TFS will afford them the ability to grow and manage from the get go.
Start with Source Control, end up with specs originated in MS Project, tied to work items tied to Unit Test tied to acceptance tests tied to automated builds and deployments
And Lastly: Burn Down / Velocity Charts
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.
I am looking for a good source control solution. Here are the requirements:
Must have a GUI or have an available GUI plug-in.
Must be free.
Must work with HTTP.
What source control would you choose?
BACKGROUND
Our .Net development team is part of a large parent company. We're in the process of acquiring VS Team System, however the bureaucracy of a large company moves slowly and it could be months before we have a Team System server up and running. In the meantime, we have a large project that will be outsourced to a vendor in India. In the past, our team's process has been something like this: 1)specify the requirements, 2)let the Indian team create the solution, and 3) receive the solution back from the vendor a month later.
We're looking for a more disciplined approach and Team System is our long term solution, however I'd like to use something right now instead of nothing.
Here are some of my thoughts:
Source Safe is a no-go, because of stability issues.
Ease of use is more important than advanced features, like branching and I'd really, really want it to use a GUI versus command lines.
HTTP access is a must, because the development team will be remote.
Additional Information as a follow up to feedback so far
We need a free solution, not because we can't afford it, but because the company's corporate purchasing policies will delay getting it. Free enables us to install at any time. I suppose that if it were cheap enough, I could pay out of my own pocket, but it would have to be pretty cheap.
Final
Sadly, we did not end up using any of the recommendations. We did finally obtain a TFS license, however we're not expected to have clearance to use the server until next year. In the interim, the offshore team is uploaded zip files onto an ftp server. Ugggghh! Why is it so hard to convince large companies that it's ok to use non-standard solutions (such as GIT) rather than wait months (or years) as they dither on trying to decide whether or not a purchase (in this case TFS) is worth it.
I recommend Subversion and TortoiseSVN. Even the documentation for Subversion is free.
Edited to add:
I also strongly recommend VisualSVN Server to setup your SVN repository. The setup was a snap and its been so trouble free I had to go look to see what it was called because I haven't had to touch it once since the initial set-up.
Think about a distributed system: darcs, git, or mercurial. They all have their adherents, but operationally they're much similar. darcs can take a long time to build, because it's written in Haskell, and you end up needing to build Haskell first. Mercurial is python based, easy to hack with and extend. And of course git is what's used for Linux, very widely available, lots of tools.
Subversion is, I think, pretty much the baseline of modern SCM; it would be a good choice too, but it does force you into having a fixed central server; either you, or your Indian collegues, will have to check out and commit over a long pipe.
Subversion (SVN) is obviously a popular choice. It's also quite commonly used now (Google Code, Sourceforge, etc.) so there should be lots of documentation out there about its use. Git is a good choice too, but the lack of GUI interfaces available makes it not fit your requirements so well.
I'm assuming since you're using .NET you're developing in a Windows environment primarily. Check out VisualSVN products. They make a great (FREE) Server product for actually running a full fledged svn server in a windows environment (it supports SSL, group/user authentication including Active Directory support).
They also offer a Visual Studio plugin, although it is not free (although quite reasonable at $49/developer). AnkhSvn is another Visual Studio client plugin option. It's not quite as great, but it is free.
http://www.visualsvn.com/server/ - Free Windows SVN Server
http://www.visualsvn.com/visualsvn/ - Visual Studio Client Plugin
http://ankhsvn.open.collab.net/ - Free Visual Studio Client Plugin
So, I think Subversion using VisualSVN's product offerings are going to give you the best windows/gui integration at a very reasonable price.
SVN sucks quite badly over HTTP in my experience. You will want to pull your hair out if your repo is of any significant size especially with a Trans-Atlantic round trip stuffed in there. Personally I'd go with Mercurial.
Google has recently done some research on Git versus Mercurial. The largest advantage that Mercurial had was that it played extremely well with HTTP.
TortoiseHg, while not quite as mature as TortoiseSVN, is a pretty solid Windows GUI. Although you mentioned you're not very interested in branching and merging, these are common activities in all DVCS. Fortunately because they are common, they are well supported in the UI and relatively painless activities overall.
Check out Subversion: http://subversion.tigris.org/
Has GUI plugin as well VS .NET. http://tortoisesvn.tigris.org/ http://ankhsvn.open.collab.net/
All open source & free.
My recomendation is Subversion + TortoiseSVN (for Explorer integration) + AnkhSVN (integration with Visual Studio).
I think you shouldn't use any of the distributet version control systems because after that you will have to get back to centralized one which could be painful.
As mentioned SVN and Tortoise are the way to go.
I'd also get a license for visual SVN (http://www.visualsvn.com/) it's not free but it is really good, it uses Tortoise svn and gives you it's features in the IDE.
Team Foundation Server is quite easy to use and is easy to get started with coming from a source safe background (shares common terminology for commands). However with part of the development being in India, they may be more knowledgeable about Subversion.
If you use Subversion, i would look at VisualSVN. It's fantastic, simple to use, and quick to set up (TFS is a bit complicated to set up). VisualSVN offers an IDE plug-in ($50) and a server counterpart that bootstraps Subversion for windows machines (Free)
Mercurial is great and really easy.
Give Mercurial a shot. BitBucket has free accounts you can play around with. I've written more about why I use it here.
Have you tried SVN and using TortoiseSVN for the Shell Extension?
I second SVN and TortoiseSVN.
I moved from CVS and WinCVS and I am very happy with this setup.
I would recommend the source control where most of your team members have the most experience or where you have someone on your team who is an expert for.
In my opinion besides the endless "git is better than Subversion is better than CVS"-discussion I don't think the differences between them is what matters.
It's more important to have someone who really knows how to use whichever system you decide to use.
Setting up Subversion for .Net development has gotten easier. You could start by installing Visual SVN Server. This will install Subversion Server on a windows machine, will work you through setting up your repository, authentication, etc.
Then for Visual Studio integration with Subversion you can try VisualSVN, it's not free but well worth the license. But if your budget don't allow it, Ankhsvn also works fine, I use it everyday.
I had to make a similar decision several months back. I liked SVN a lot, but the lack of GUI for the administration was a big issue for my team. TFS was ideal, but very expensive.
We decided to meet halfway and license SourceGear Vault. It doesn't meet your requirement of "free," unfortunately. Although I did find its comparison with SVN to be interesting.
If you're certain you're going to Team System, then I believe there's a 180-day trial you can use. That way, you son't have to switch.
Have you tried unfuddle (http://unfuddle.com/). Fulfills all your requirements.
Another vote for SVN.
For a lightweight SVN server on windows look at sliksvn. It doesn't do http source browsing, but is a much smaller and easier setup than apache based servers for small groups.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I am a student and I always develop projects on my own, mainly with Ruby On Rails.
I noticed that even a simple project may become complex if you can't easily rescue deleted code and pass from a version to another. Time Machine backups are not enough.
I would like to use a version control system, but they seem not to be intended for single-user projects. Am I wrong? If so, what policy and software do you use for managing your code?
There is nothing that says you can't use a standard version control system if you are a single user. Doing so would definitely keep you from experiencing some of the more painful problems such as merging files changed at the same time and other conflicts that arise from multiple developers.
Based on this, you could look into any of the version control systems (I believe Subversion is far and away the most popular right now) and pick out the one that will most closely match your needs, or has the interfaces you are most comfortable with.
Distributed version control systems are just for you: look for Bazaar, Git or Mercurial. They are lightweight, local commits are easy and you can always revert to a previous version. With a hosting provider such as GitHub, you can publish your projects, you get backup for free and you can easily share the projects with other potential contributors. Collaboration is easy because merging your changes is also a lightweight operation.
It is definitely a good idea to use version control software, and other project software on your own projects. These tools are not just for team working, although they allow team working. Beyond the obvious reasons for keeping track of your changes to the project it is a good idea to use SCM tools so you are familar with what the industry is using.
Subversion is widespread, and is quite a good bet as it's successfully replaced the earlier and older CVS tool. It relies on a central repository where the code is stored and can be backed up: where I have used SVN for personal projects and small team projects I have backed up to CD. If your project is opensource there are sites like sourceforge that support svn which you can use for hosting.
However as some of the other posters have indicated, a personal project might benefit more from a distributed system: git is increasing in popularity since git-hub has come online and porting efforts to are succeeding. http://git-scm.com/ It is likely that tools like these will grow in popularity over the coming years as they allow a greater number of people to participate on the same code. The idea of one central repository is relaxed giving each developer the ability to version track different designs and only give back to the community the versions they complete.
One of the benefits with using SCM for all projects personal or not, is that a separate server can be set up testing a version of the code. Automated testing on the latest version of the code (using a Continuous Integration Server or similar) can improve the quality of the software you are writing.
Some highly experienced software developers talk about a rhythm where they make incremental changes checking in frequently. Getting into the habit of making small changes which are complete and checking them in: is a good practice to get into for group working.
I would recommend Subversion. It's free and relatively simple, and learning a little about it may well beneficial in the future. It's cross platform and also available on a variety of hosted systems.
See also: https://stackoverflow.com/questions/250984/do-i-really-need-version-control
and: Using Version Control for Home Development?
Subversion!
You can install locally or use a hosted service. The services are nice if you want to switch between computers or use it as an offline backup. http://www.beanstalkapp.com/ has a free plan for personal use.
GitHub (git, not subversion) is also popular but I believe there is a small fee for personal projects.
Use git. It allows you to work without ever needing a server.
There are utilities for the command line and a GUI (older screenshots) too (for linux, windows and OS X).
If you later want to share or publish your project you can easily push it to a site like github.
Even for personal projects, if they become bigger than something you write a few hours, a version control system will be very beneficial.
Here are a few good points:
Many version control systems have good integration with IDEs.
Branching will allow you to experiment without the fear of having to take a long time to revert the changes. The branch can later be merged to the main trunk if needed.
Having a history of changes can be helpful, and tagging will allow setting milestones.
More efficient storage than full backups using regular copying of files.
Extra metadata (such as commit comments) can be attached.
Many version control systems are free!
I personally use a Subversion server running on my system which I access via the Subclipse plug-in in Eclipse, which I find to be very helpful in keeping track of my personal projects.
If you're interested in Subversion, Version Control with Subversion is a very helpful source in learning about the concepts, and how to set up and get started with Subversion.
Version control systems may be a little difficult at first, but it's definitely worth the effort to set up!
I'm very wary of using "always" in any answer I give on SO...
ALWAYS use version control. These days it's free AND easy to do. There's simply no reason ever not to use it. If it's an hour long project...good...it's an hour long project that's in version control now.
My solution has been slicehost(ok...not free), redmine(free RoR bug tracker)git and gitosis. Starting up a new project adds about five minutes on to the front of any coding, but its five minutes well worth it.
Use SVN or Mercurial.
Both very appropriate for "home" usage, I think Mercurial is better for you because by default you'll be creating one repository per project ( oposed to SVN's one "big" repository that stores everything ), so it will be easier to backup individual projects or exchange sources with others if needed.
Both work in command line mode or using explorer-like interfaces ( Tortoise ) or plugins available for the most usual IDE.
I use subversion to manage all my projects. xp-dev.com is a free subversion hosting solution. Also, I think, if you install tortisesvn it installs a subversion server to use locally.
A complete different version control system is dropbox (www.getdrobox.com). It's not (only) intended for source code. It available (with smart OS integration) for Mac, Win and Linux plus private Web Interface.
It may be interesting for you.
One item you will like about git such as using github hosting is that you have a history of changes that you can go to and get the actual code source and thus 'rescue' previous code changes.
You could also use the dropbox approach in just backing up raw code to a folder on the cloud..
I have used both methods for personal projects.
Hosted version control such as beanstalkapp.com is very convenient, but do consider whether you want to hand your source to a third party. You could consider a local repository, backed up online with a solution which encrypts the contents locally before uploading. I do this with subversion, Amazon S3 and JungleDisk.
Bitbucket is an absolute must consideration for personal projects based on:
Free, unlimited, private repositories
Up to 5 users on their free account
Git and Mercurial support
This allows one to quickly spin up a repository without having to pay attention to how many repos are available under a paid source code hosting account.
It also allows projects that will enter the public domain to be simply forked to GitHub, etc.
Version control is always important.
Try a free online SVN like http://beanstalkapp.com/
Do a search and you can find lots of suggestions
I would highly recommend downloading VisualSVN Server. It's a very simple setup and will do exactly what you need.
you can use any version control system that exists just for single user development. as you said, even simple project can become a nightmare if you change something you think is better and it fails. download tortoise snv - it's free and pretty simple to use - and keep your working versions in repository. commit code that works, keep possible small changes (for example refactor one class), build it, test it if it works -> commit, if it doesn't and you don't know why you can allways revert changes and try again.
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.