What to migrate to from VSS (Visual SourceSafe)?

Question

I’m looking for revision control software that would successfully substitute Microsoft Visual SourceSafe. I spent many hours reasearching on this subject, but eventually found no appropriate solution. Why? Because VSS’s shared files seem to be a unique feature.

To be specific, by a shared file I mean a single file mapped into several locations. For example, when you want to use one source code file among different projects, you just drag and drop it to whichever project directories you need. Then there is one file linked to several directories. When sombody modifies that file in any of these projects, all others get it updated to its head revision.

An equivalent feature in SVN is svn:externals which enable to share files in two ways: using their head revision or using an explicitly selected revision. However, no matter which one I choose, the result is different than in VSS. So when I attach an external file to a project in its head revision, it is almost like in VSS. But when I want to get a historic revision of my project, I always get the head revisions of external files instead of appropriate historic ones. It looks like a bug, but maybe there is a reason SVN works this way. The second option is using external files in selected revisions. But then these files have to be updated manually in each project when somebody modifies them anywhere. We don’t want to do this manually, really.

Plastic SCM is a second solution I checked. IMHO this system is FANTASTIC! Intiutive and clear GUI and a wonderful revision graph that lets you handle branching and merging really easily. That really grabbed my attention compared to VSS. But let’s get to the topic. Plastic supports Xlinks (symbolic links), but only directories can be linked using them, not files. What’s more, there is no option of sharing head revisions (you have to select specific ones explicitly).

Let me ask you what to do then. What software to choose to make our work more efficient, but at the same time not to lose the sharing feature? Why is it so unpopular? Is there a different approach to sharing code between projects?

Answer 1

IMHO per-file linkage to a shared location is confusing, which I think explains why most SCMs chose to adopt a paradigm allowing sharing in the directory level (if at all). In addition to the example you bring of PlasticSCM, I have experience with git which provides this functionality as submodules, again requiring you to put the shared files in a separate directory, and forcing a less-confusing hierarchical relationship between the shared part (the submodule) and the projects using it.

Unfortunately, it seems you fell in love with a feature not many need or use. It might be that your needs are so unique. But you should carefully consider whether your requirements are indeed unique, and perhaps make the small sacrifice of giving it up for more mainstream development conventions (in this case, putting the shared files in a separate directory), which will allow you to use state-of-the-art tools.