4

We're interested in moving from a source control system that supports the concept of shared or linked files.

A shared file means: a file modified in one project, is automatically updated changed in every other project that uses that same file. It does this without a developer having to request it, reverse-integrate it, ask for it, or even want it.

We're trying to see if any other commonly used source-control systems can meet our needs, and include linked or shared files. My limited research shows that:

  • Team Foundation Server doesn't support sharing files
  • Subversion doesn't support sharing files (including Externals)
  • CVS doesn't support sharing files (including Modules)

Anything else? (besides our current source control product, obviously)

References

Community
  • 1
  • 1
Ian Boyd
  • 246,734
  • 253
  • 869
  • 1,219
  • Argh: the only VCS I know which both support linked files, and dynamic update is... ClearCase! But I do not dare to say it in an answer; ClearCase would probably gives you more troubles than solutions, unless you have *a lot* of inter-dependent projects... – VonC Sep 11 '09 at 15:44
  • 1
    What's wrong with SVN's externals? It seems this is what they were invented for. – sbi Sep 11 '09 at 16:13
  • I suggest that maybe you can work around the shared file thing. They're a pretty horrible feature to be honest, is you're use of them really a good thing? – Jim T Sep 11 '09 at 16:34
  • 1
    Maybe my POV is warped because my tools *don't* support this but, it sounds to me like you are Doing It Wrong. I'd address this problem at the level of build/dependency management by making shared thing into a releasable artifact of its own, which those that need it then use. – bendin Sep 11 '09 at 16:49
  • I prefer to call this feature "spooky action-at-a-distance" :) But it's a fair question to ask. Look at Vault, as suggested, or see my answer for a more robust and SCC-independent workaround. – Richard Berg Sep 11 '09 at 18:13
  • @sbi: You cannot share files. You can only share folders - and the only real mechanism to do that is to create an external library folder and have everyone point to that. – Ian Boyd Sep 11 '09 at 21:13
  • @bendin: Problem with having shared code as a releasable artifact of it's own is that it's a separate binary. – Ian Boyd Sep 11 '09 at 21:14
  • @JimT: What would the workaround you suggest? Why is the perfect soltution a horrible feature? – Ian Boyd Sep 11 '09 at 21:15
  • @Ian: I see. I hadn't understood that you wanted to share files, not folders. – sbi Sep 12 '09 at 13:42

5 Answers5

8

I've used Sourcegear's Fortress (an all-inclusive ALM - for just source control, check out their Vault product) for years with no complaints, and it supports Sharing. You can essentially branch a file from one project into another, and the second copy will be kept up to date with no additional interaction required.

The product is designed as a replacement for Sourcesafe, and since VSS supports shares, so does Vault. As an additional feature, they support "Pinning", which is where the recipient of the file link can set it at a particular version and not receive any additional updates, if that's what they want. If they don't pin the file, they'll continue to use the newest version, but the option to pin at any point is there if they want it.

SqlRyan
  • 33,116
  • 33
  • 114
  • 199
  • 1
    +1 despite not agreeing with "source control without the extra features" its not a DSCM but it still does everything as far as I can tell. (comparing to SVN as that is the other SCM I use) – Pondidum Sep 11 '09 at 15:54
  • I rephrased it - I use Fortress, which is an entire ALM with bug tracking, planning, and Source control - Vault is their source-control-only product, so may be more suited for the OPs comparison. – SqlRyan Sep 11 '09 at 15:57
  • We found Vault, and it looks like the front-runner. We were just scared of the pricing for 9 developers. (Whereas we already have licenses for VSS and Windows Server) – Ian Boyd Sep 11 '09 at 21:12
  • They may already have licenses for VSS, but VSS licenses don't come with MSDN (many people wrongly assume that their MSDN subscription includes a VSS license), so the difference in price may not be as drastic as you'd initially think. – SqlRyan Sep 11 '09 at 21:21
3

I don't know how many degrees of freedom you have to solve this problem. However, it sounds like a more traditional solution for this problem would be to build a library which is external to the projects that depend on it. Reference the library (assembly, .jar, .so, .pm, whatever) in its "officially published" location.

Let the "mod downs" begin for not answering the question as asked, but it does sound like the wrong quetion to me.

Roboprog
  • 3,054
  • 2
  • 28
  • 27
  • Problem with making it an external library is that it's not part of the same project, and not compiled into the final executable. – Ian Boyd Sep 11 '09 at 21:16
  • @Ian: That's only partially true - you can also use a static library. In the .NET case, there's ILMerge for this. On the other hand, I totally agree with you that libraries may not be the best solution. – OregonGhost Sep 14 '09 at 08:46
  • @OregonGhost Not every language supports static linking of a dll. This is true in my case, and happens to also be true in .NET, where people are forced to use the buggy ILMerge. – Ian Boyd Nov 20 '10 at 12:43
1

Well sourcesafe is the obvious one that supports this (it's horribly broken in every way, but does support this). I wonder if sourcegear's vault will support this as well, since it's supposed to be a fixed version of sourcesafe.

Jim T
  • 12,336
  • 5
  • 29
  • 43
  • 1
    We use VSS now. No problems in 10+ years of use, maybe 300 projects, and full history. – Ian Boyd Sep 11 '09 at 21:19
  • @Ian Boyd - I started believing we were the only ones happy with vss. How did migrating work out for you? – Lieven Keersmaekers Apr 21 '10 at 08:04
  • @Lieven: We haven't done it yet. It's a huge commitment. And there's no guarantee that we'll carry over our entire history. SourceGear seems to be the only choice - nobody else supports shared files. – Ian Boyd Apr 21 '10 at 14:08
  • @Ian Boyd - we kind of already settled on the idea of keeping a VSS repository online for our history and start afresh with TFS. The Shared Files problem will (probably) be dealt with by creating a shared project, link our real projects to the files in that shared project and revision it on its own. It buys us almost nothing and merely adds to maintenance but we don't see any other option. – Lieven Keersmaekers Apr 21 '10 at 14:32
  • @Lieven We looked into having a folder/project for the "common" stuff. This works great for Delphi, where the IDE can be configured to look in a folder for files. But Visual Studio can only find files by them being in the project; and the path the "shared" project is different on everyone's computer. – Ian Boyd Apr 21 '10 at 16:59
1

Building on Roboprog's answer: the more general solution to your problem is to update the makefiles in the "share targets" so that they incorporate items from the "share source" by reference rather than relying on the SCC system to do it for them.

If the common functionality can be easily factored out into a library (assembly, jar, C++ headers + libs), great! This will help everyone in the long run. The library can now be unit tested with a variety of standalone tools; consuming it also becomes easier now that the contracts on both sides have standardized. In addition, you can now treat the library as a first class citizen WRT change management. Breaking changes can be made in their own branch; fixes from other teams that share the code can flow around the repository alongside the rest of your application; and so on.

But none of that is strictly necessary. Even if you do everything in 1 branch, or even if the share in question is a single foo.h, you can continue to use your existing SCM practices with just a few tweaks. Every build system I've ever encountered is capable of incorporating a file from Module A into Module B, so long as the relative path is correct. If you're using Visual Studio's *proj makefiles, the quickest way to do this is Add -> Existing Item -> navigate to the source file -> click the dropdown arrow on the Save button -> Add As Link.

Richard Berg
  • 20,629
  • 2
  • 66
  • 86
  • Problem with separate libraries is that they are separate, and not part of the project. – Ian Boyd Sep 11 '09 at 21:17
  • Well duh. Separation is a good thing if the cost of factoring it out is lower than the dev/test efficiencies gained in the long run -- and it almost always is, IME. But factoring code into libraries is just one example. **The important point is to shift the burden of "sharing" from the SCC system to the build system where it belongs.** You can certainly do so at the file level instead of the project level: it's messier, but occasionally the right solution. I gave the exact steps on how to implement this in VS once you break the server-side link. Should be equally trivial in any other makefile. – Richard Berg Sep 12 '09 at 14:33
  • Not every development environment has makefiles (and IMO makefiles should never have been invented). The important point is that the limitations of a source control provider should not make building more difficult; the burden of sharing lies with SCC. – Ian Boyd Nov 20 '10 at 12:47
0

I think the general problem you will run into is changing a file in each repository will require a commit, in order for history to be preserved.

git is an awesome version control system. They have submodules, which could be used to do what you want, except the maintainer of each repository will need to issue a single command to upgrade the set of "shared files".

Assuming you had a submodule REPO/share, each repository to be upgraded would need to:

cd REPO/share; git pull

You could 100% automate that using git hooks, if you really wanted to.

gahooa
  • 131,293
  • 12
  • 98
  • 101