Jeremy D. Miller -- The Shade Tree Developer

Phil Haack has a great post that's near and dear to my heart, Better Developers Through Diversity....

Phil Haack has a great post that's near and dear to my heart, Better Developers Through Diversity....

Phil Haack has a great post that's near and dear to my heart, Better Developers Through Diversity....

Could you (or another commenter) do those of us stuck in VSS-land a favor and post some links to information about how to integrate VS.NET and Subversion or CVS?

I agree that VSS has flaws, but I haven't seen anything like "Subversion for VS.NET Developers", while VSS is relatively easily integrated.

I download and install one of those alternatives every once in a while in a fit of disappontment at VSS but must be missing something important. :)

Thanks!

I don't know if Steve Barron will be coming back to view responses to his question any time soon (his comment was left many months ago).  But for him and anyone else who happens upon this blog entry I have three items to consider:

AnkhSvn is a very nice tool for integrating SVN with VSS.  It has a few minor quirks, but it is actively developed (which means that it has far fewer quirks than it used to, unlike VSS).  I personally think it is great, and have used it for a long time.

TortoiseSvn is the reigning king of all subversion GUI clients, indeed of all of the source control GUIs that I've seen.  I personally use it much more frequently than AnkhSvn.  It integrates with Windows Explorer.  So, if an alt-tab or Win-E isn't too much trouble, I think you'll find that the VS.Net integration isn't all *that* important.

Lastly, I'd like to suggest that the biggest problems people will have when switching from VSS to svn will not be the client integration issues (because the two clients mentioned integrate with Windows and VS.Net better than VSS does), but with the following necessary paradigm switches: Going from the Lock-Modify-Unlock model to the Copy-Modify-Merge model.  A smart working directory (with lots of useful meta-data).  Copies/Renames/moves/branches etc, should *only* be done via a subversion client, or else versioning will be lost (VSS would lose your versioning as well, but svn working directories have a lot of metadata in them that can sometimes give confusing behaviour if you don't use the svn clients for your copies/renames/moves).

The subversion manual has a good description of these paradigm differences, most importantly: http://svnbook.red-bean.com/nightly/en/svn.basic.vsn-models.html  VSS ostensibly supports Copy-Modify-Merge (under the name "multiple checkout"), but it's implementation is unsafe and should be used only very cautiously.

I cannot (yet) compare svn to MS TFS, but my employer will soon be installing that (because they are full-fledged members of the .Net community that takes everything from Microsoft without question), and I'll be able to compare them then.


Another nice thing about subversion is its multiplicity of clients.  Eclipse plugin, command line, java standalone, VS.Net add-in, windows explorer, linux, mac, windows, solaris, etc.  And better yet, almost every single one of these is free (open source, even) and well-supported.  Multiple platform or client support is not exactly a selling point for VSS nor for TFS (clients exist, but they are quite pricey or not very good).  But, as the blog stated, the .Net community is usually rather ignorant of products and platforms that come from outside the domain of Microsoft.

Jeremy, Our org is considering different source code control tools to manage a number of Supply Chain applications including Subversion, VSS, Clearcase.

One fundamental question: Does VSS have a hook into UNIX ( most of our apps are unix based...) ? I hoping you say no...VSS sounds like it is fraught with issues, yet there is backing for VSS in some quarters...

Thanks!

@Crochetti

VSS is Windows only.  Regardless, VSS should be avoided at any cost.  I'd strongly recommend Subversion (free, solid, minimal friction, common, supported by numerous tools).