1

I have following situation in my project:

There will be 2 source code repositories however each of them should have "shared" area for some part of code (potentially more than one).

Lets assume following structure of repositories and their folders (and files within these folders).

Repo1

  • folderA
  • folderB
  • folderC

Repo2

  • folderA
  • folderD
  • folderE

"folderA" should contain exactly same "copies" of files. So when I commit some change to Repo1/folderA and then checkout/update Repo2/folderA, I should be able to see these changes. Of course it would be great if it could work the same in opposite direction.

Unfortunately I cannot structure source code in another way and create some kind of shared library.

I'm looking for VCS that could help me with solving this problem in a best way (SVN, Git, ...)? Do you have any experience with this kind of setup and could you recommend something?

michal.slocinski
  • 505
  • 1
  • 9
  • 22

2 Answers2

3

If you are using Subversion, then you could use externals, which will allow you to have a single folder in your repository with the shared code, and each of the trunks in your two project folders would have their externals property set to point to this shared repository location.

It's two way, so you can make changes to the shared folder and they will be picked up when you update either project folder, or you can make changes from the local project folder, and they will be submitted to the shared repository folder.

However, you should be aware of the issues with externals.

Another option may be to completely seperate the source of the shared code into a third party library, and then use NuGet for easy deployment of that library to your various projects. TeamCity for example can build NuGet packages (and acts as a NuGet package server) for you on commits of your shared library code.

Community
  • 1
  • 1
devdigital
  • 34,151
  • 9
  • 98
  • 120
1

Using git, you can create a third (shared) repo containing just the shared files (folderA). Then Repo1 and Repo2 can both include the shared repo as a submodule, so:

Repo1/folderA ->
     /folderB    \
     /folderC     \
                   -> Repo3/folderA
                  /
Repo2/folderA ->-
     /folderD
     /folderE

downsides:

  • repo 1 & 2's submodule links are themselves versioned, so you have to explicitly update folderA in both repos if you want them to see the latest changes on repo 3's HEAD.
  • if you have working copies of both repo 1 & 2, you end up with two nested copies of repo3 as well, and they're not necessarily in sync

The upside, if it matters, is that you can permission read & write access to all three repos independently.


It's certainly much easier to use

Repo/shared/folderA
    /project1/folderB
              ...
    /project2/folderD
              ...

if possible (the build system likely works out easier as well). You do lose the ability to permission your two projects independently though.

Useless
  • 64,155
  • 6
  • 88
  • 132