Comments on: VSS to SVN http://www.gamesandcode.com/blog/2008/01/vss-to-svn code it, play it Thu, 12 Aug 2010 18:51:39 +0000 hourly 1 http://wordpress.org/?v=3.0.1 By: Phil http://www.gamesandcode.com/blog/2008/01/vss-to-svn/comment-page-1#comment-18 Phil Sun, 27 Apr 2008 03:09:03 +0000 http://www.gamesandcode.com/blog/2008/01/vss-to-svn#comment-18 The core Subversion package is relatively easy to install (via a linux distribution's package manager, or on Windows using the .exe installer.) Like most open-source tools, it has a command line interface, and can be tough to configure correctly. (Especially when setting up Apache on Windows to use the svn DAV module.) TortoiseSVN is a very functional, reliable tool for Windows users; there are also a few VS plugins that provide a level of integration similar to that of VSS. AnkhSvn is reasonably functional and free; VisualSVN (visualsvn.com) is somewhat more reliable (it's based on TortoiseSVN), but is a commercial product. (Well worth the $49, IMO) VisualSVN also provides a server component for Windows, which automates the installation and provides an MMC-based configuration tool. It supports SSL and Windows user authentication, and best of all, VisualSVN Server is free. Subversion supports file locking quite easily; there are lock/unlock commands (also exposed in the GUI tools) which allow a file to be locked by a specific user; commits will be rejected until the file is unlocked. For problematic files (such as binary files) there is a "needs-lock" property that can be set for a file, which requires the file be locked before a commit is allowed. (Unlike VSS, if someone goes on vacation with a file locked, anyone can forcibly override the lock. Since any rouge changes can easily be reverted, this isn't a significant security issue.) Subversion does in fact support file sharing via the externals feature. "svn:externals" is a property that can be applied to folders; when a folder with this property set is checked out or updated, Subversion automatically reads this property and checks out/updates the specified projects (elsewhere in the same repository or in a different repository altogether) into subfolders. Unlike VSS, this functions on folders, not individual files; there is no way to share a single file in SVN without putting it in it's own folder. (IMO, sharing individual files is a bad idea anyway; better to share a complete library, as this induces looser coupling between projects.) We use this with third-party libraries; we check either the source (if we have it) or the binaries (if we don't) into a separate project, and include it in other projects via Externals. You can also lock an external folder to a specific revision of it's target repository with a parameter in the externals property, similar to the VSS "pin" feature. (Again, folders only, and it affects the entire subtree.) The core Subversion package is relatively easy to install (via a linux distribution’s package manager, or on Windows using the .exe installer.) Like most open-source tools, it has a command line interface, and can be tough to configure correctly. (Especially when setting up Apache on Windows to use the svn DAV module.)

TortoiseSVN is a very functional, reliable tool for Windows users; there are also a few VS plugins that provide a level of integration similar to that of VSS. AnkhSvn is reasonably functional and free; VisualSVN (visualsvn.com) is somewhat more reliable (it’s based on TortoiseSVN), but is a commercial product. (Well worth the $49, IMO) VisualSVN also provides a server component for Windows, which automates the installation and provides an MMC-based configuration tool. It supports SSL and Windows user authentication, and best of all, VisualSVN Server is free.

Subversion supports file locking quite easily; there are lock/unlock commands (also exposed in the GUI tools) which allow a file to be locked by a specific user; commits will be rejected until the file is unlocked. For problematic files (such as binary files) there is a “needs-lock” property that can be set for a file, which requires the file be locked before a commit is allowed. (Unlike VSS, if someone goes on vacation with a file locked, anyone can forcibly override the lock. Since any rouge changes can easily be reverted, this isn’t a significant security issue.)

Subversion does in fact support file sharing via the externals feature. “svn:externals” is a property that can be applied to folders; when a folder with this property set is checked out or updated, Subversion automatically reads this property and checks out/updates the specified projects (elsewhere in the same repository or in a different repository altogether) into subfolders.

Unlike VSS, this functions on folders, not individual files; there is no way to share a single file in SVN without putting it in it’s own folder. (IMO, sharing individual files is a bad idea anyway; better to share a complete library, as this induces looser coupling between projects.) We use this with third-party libraries; we check either the source (if we have it) or the binaries (if we don’t) into a separate project, and include it in other projects via Externals. You can also lock an external folder to a specific revision of it’s target repository with a parameter in the externals property, similar to the VSS “pin” feature. (Again, folders only, and it affects the entire subtree.)

]]>