Top Reasons Why I like Subversion Better than SourceSafe

*Offline access is the model Subversion is designed around. You don't have to worry about going offline, because this idea is at the root of Subversion. Subversion was designed to replace CVS, which is typically used for projects with huge geographical dispersion. Think ADO vs ADO.NET.

*Offsite access to your repository is painless. Just open a port on your firewall (if you have one) and you can send stuff to subversion over the internet without doing anything special.

*Projects load blazlingly fast when you aren't dealing with SourceSafe (the speed difference is insane).

*You don't have to worry about read only files all over your hard disk just because you added them to SourceSafe. The Subversion model doesn't do file locks at all and is very slick.

*Revision commits are atomic. This means that when you are done making your changes, you hit sync. If something conflicts half-way through, you don't get a partial commit, the whole thing succeeds or fails.

*Renames and moves don't break things. I got quite sick of seeing that “if you rename this folder, it isn't the same item anymore” messages every time I started refactoring my code. With Subversion, files are maintain their identity regardless of any name changes or moves.

*Explorer integration with TortoiseSVN is awesome. Storing non-project assets like third party DLLs or documentation in your repository is amazingly simple. Additionally, since Tortoise is directory based, not project based, you don't have to worry about stupid mistakes like forgetting to add your strong name key file or some new web app images.

*Multiple concurrent versions are painless with Subversion. If you need to fix a bug for a client which is a few revisions back, just check out that revision and fix the bug. Very easy to do and no strange side effects.

*When we switched to Subversion, we switched our web projects to local, non web projects (see this article), which is also very nice. If you don't do this, you will have to deal with that lame “cannot load project information from server” message from VS for some reason, but you probably get those right now anyway. I guess when Whidbey comes around, this will be a moot point, because MS apparently decided that those web projects were such a lame idea that they are pretty much doing stuff this way.

Want to here why some others think Subversion is 10x better than SourceSafe? Check out this link:

http://www.wadhome.org/svn_vs_vss.txt

The only real downside with Subversion is that if you like VS.NET integration, the plug-in for this isn't quite ready for prime time yet. To tell you the truth, however, because of the differences in the source control models, you don't really need VS.NET integration anyway. It might be nice to have some little icons inside the IDE to save you an ATL-TAB when you are done for the day, but it isn't definately anywere as important to have the integration with Subversion as it is with SourceSafe.

11 Comments

  • I agree 100%. Coincidentally I used the same exact phase as in your last paragraph regarding AnkhSVN: "not quite ready for prime time" but hopefully with all the newfound exposure that Subversion is getting lately it will add some fuel to this project. Ideally I'd like to see someone just take TortoiseSVN and make all of its functionality applied to the Solution Explorer.

  • Yes. Subversion has no problems with binaries.

  • Cool, thanks Jesse. I hope it didn't take too long to put together!

  • Great article, Jesse.



    I agree you don't need a plugin as you use sourcecontrol totally differently in CVS/Subversion kind of systems vs SCC kind of systems. I'll check out subversion this weekend.

  • Can Subversion handle binary files as well as text files? I like to use VSS to store multiple versions of my binaries (like word docs, erwins, visios, exes, jars, etc.)

    CVS documentation always said don't do this and corruption was mentioned. I obviously don't expect diffs, just to be able to extract an older version anytime I want.

  • "...to save you an ATL-TAB when you are done for the day..."



    What??? Come on people, SMALL, FREQUENT check-ins.

  • If you are building anything of decent complexity, it is not unusual to have a single change take a day or more to code. If you are in the middle of coding a complex feature which has dependancies, you do not want to blindly check it it and risk breaking the build (or everyone else's code, especially if you run daily test suites). You should check in code when it is ready to be checked in, not just because. The reason you check in code frequently is so that it can be integrated by others at a more rapid pace, and no so much to prevent the loss of a day's work if for some strange reason your hard drive randomly explodes. It is far better to risk losing one day's work due to the random explosion of your hard drive than to risk putting 100 other developers a day behind schedule because you broke all their crap.

  • So now I'm curious. I'm a fan of frequent checkin's. I use cvs and check in code constantly. I don't know bout anyone else, but I can't afford to lose one days work. Why would code tagged as 'mynotreadyforprimetimecheckin_20040226' break a build? I agree, if you blindly check in code in sourcesafe that has the potential for causing havoc and someone does a blind 'Get Latest' build, you'll have problems. When my code is ready for primetime I promote the tag to whatever it needs to be to get built. Am I doin somethin weird or does anyone else work that way?

  • if you are working in your own tag, independent of the main trunk, then i don't see any problem with frequent commits (checkins) since your code isn't depended on by anyone else's code. but here, we all work in the main trunk of our app so that the other team members get the newest code changes as they are committed (the changes, not the team members *g*) Because of this, our rule is you commit when your code "works" ... or at least compiles. Whenever I update and then I can't build because of someone else's code, I chew them out. (I have this luxury being the "senior" developer.)

  • I'm a firm believer in using continuous integration on projects. Having Draco.NET monitor your repository, and do an automated build anytime you check something in can be a real time saver. Especially if you are using unit tests. Seeing who broke the build, and when is definitely better than doing a daily or weekly build!



  • please delete all of the comment spam

Comments have been disabled for this content.