Source control products that support linked/shared files?

Question

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

• Subversion and shared files across repositories/projects?
• How to share files between CVS projects?
• Will TFS ever support shared files for projects under source control?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.