1

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?

Mariusz Schimke
  • 3,185
  • 8
  • 45
  • 63

1 Answers1

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.

onon15
  • 3,620
  • 1
  • 18
  • 22
  • Actually I'm not sure if our needs are that unique, but I have to discuss with others what we gain and what we lose when migrating from VSS and losing file linkage. We store our installation wizards on VSS as well. Binaries from different projects are linked to appropriate directories of those wizards' projects. Imagine how easy it is then to create a new setup file. You just download a wizard's project directory structure (where all binaries are up to date) and rebuild it... You don't have to collect all binaries manually. Neither do you have to update each of them to their head revisions. – Mariusz Schimke Dec 16 '12 at 15:43
  • Indeed it doesn't sound unique. I think the common solution to that is to use submodules, and either have the build script refer to the binaries from the submodule directory (in your case, the installer project will have a lot of linked sub-directories instead of a lot of linked binary files). That way you don't need to do the collection manually. So you just need to make sure the SCM you choose can keep track of the remote revision of the submodule. – onon15 Dec 16 '12 at 15:49
  • OK, thanks a lot for your help. I wasn't sure if the per-file linkage is a unique feature of VSS (I just couldn't belive it), but it seems that it really is, according to what you say. So we can either stay on VSS (kill me :-) ) or make a step forward and check some contemporary solutions of which Plastic SCM makes a good impression. I used to work with SVN for a couple of years and it is very good. But Plastic SCM seems to be simpler and much more intuitive (this is my first impression). I will have to check if IT is possible to create scripts for performing automatic Xlinks updates. Cheers! – Mariusz Schimke Dec 16 '12 at 16:03
  • 1
    @Mariusz I'm one of the developers at PlasticSCM and we're about to restart a vss migration project since all the ones going through the git path don't look stable enough. That being said: yes, the xlinks are pointing to directories, not individual files. We could easily do that, but IMHO it would turn the entire system nearly unusable, too complex, don't you think so? BTW, if you have good examples and cases, we'll be eager to listen! And learn! – pablo Dec 19 '12 at 22:55
  • @pablo Thanks for your feedback. IMHO sharing files is better. Sharing folders creates constraints. But I'm no specialist at this topic :). What we currently need is the file sharing feature and an option of automatic shared files update. When you download a project from your repo, it would be nice if you were informed if some xlinks are out of date and if you could select which ones to update at that moment. The same option available in some context menu of your working directory folders. I think these are our prerequisites. We just want to keep our projects coherent and up to date this way. – Mariusz Schimke Dec 20 '12 at 22:29
  • @pablo You know, VSS seems to be kind of specific if it comes to its unique file sharing feature. In fact, I don't think it is good that when you modify a shared file, then all projects get this file modified as well without control. So this was my idea just to inform the user that some xlinks have changed and let them update those at once. Or just click a working folder and select something like "update xlinks" to get the list of all shared files whose revisions have changed and update all of them (or selected) at once. – Mariusz Schimke Dec 20 '12 at 22:37
  • 1
    @pablo It would be a great deal for us to migrate from VSS with our 10-year repo and change the whole directory structure and modify all projects individually to adjust to directory sharing :(. If you look for discussion groups questions about migration from VSS, file sharing seems to be a quite common issue. We just want to go through the conversion process without too many troubles and then not to lose features that we consider really important. Thanks for reading it! :) – Mariusz Schimke Dec 20 '12 at 22:48