Sharing the same file between different projects

Question

Hi Everyone,

For version control we currently use Visual Source Safe and are thinking of migrating to another version control system (SVN, Mercurial, Git).

Currently we use Visual Source Safe's "Shared" file feature quite heavily. This allows us to share code between design and runtimes of a single product, and between multiple products as well.

For example:

**Product One**
  - Design
     Login.cpp
     Login.h
     Helper.cpp
     Helper.h
  - Runtime
     Login.cpp
     Login.h
     Helper.cpp
     Helper.h

**Product Two**
  - Design
     Login.cpp
     Login.h
  - Launcher
     Login.cpp
     Login.h
  - Runtime
     Login.cpp
     Login.h

In this example Login.cpp and Login.h contain common code that all of our projects need, Helper.cpp and Helper.h is only used in Product One. In Visual Source Safe they are shared between the specific projects, which means that whenever the files are updated in one project they are updated in any project they are shared with.

This is a simple example but hopefully it explains why we use the shared feature: to reduce the amount of duplicated code and ensure that when a bug is fixed all projects automatically have access to the new fixed code.

After researching alternatives to Visual Source Safe it seems that most version control systems do not have the idea of shared files, instead they seem to use the idea of sub repositories. ( http://mercurial.selenic.com/wiki/subrepos http://svnbook.red-bean.com/en/1.0/ch07s03.html)

My question (after all of that) is about what the best practices for achieving this are using other version control systems?

1. Should we restructure our projects so that two copies of the files do not exist and an include directory is used instead? e.g.

   Product One

   • Design Login.cpp Login.h
   • Runtime Login.cpp Login.h
   • Common Helper.cpp Helper.h

This still leaves what to do with Login.cpp and Logon.h

1. Should the shared files be moved to their own repository and then compiled into a lib or dll? This would make bug fixing more time consuming as the lib projects would have to be edited and then rebuilt.

2. Should we use externals or sub repositories?

3. Should we combine our projects (i.e. runtime, design, and launcher) into one large project?

Any help would be appreciated. We have the feeling that our project design has evolved based on the tools that we used and now that we are thinking of switching tools it's difficult for us to see how we can best modify our practices.

Or maybe we are the only people are there doing this...?

Also, we use Visual Studio for all of our stuff.

Thanks.

Answer 1

I can only speak from SVN perspective, but it is pretty common to have the files used in multiple projects stored in a separate module (SVN has the concept of modules, I think that is what you mean when you are referring to sub repositories).

The way I would do this is to have common code that is needed across more than one project checked in as a separate module. If you call this module Design and your other two products are checked into SVN as ProductOne and ProductTwo, then all you need is to check out the Design and ProductOne module, make ProductOne depend on Design for compilation.

In Visual Studio, the workspace is called solution which can contain more than one project. So, you can have all three modules as projects and make the ProductOne project depend on Design project. It is as simple as that.

Answer 2

I have in the past migrated from a similar situation (C++, Visual Studio, VSS) to svn. We chose to share source code between different projects with svn:externals. It worked, but it wasn't very pretty. Especially with branches and tags, this can become really painful.

I would now strongly advise to move the shared code into a separate project, and share at the lib level. Debugging and shared development can work equally well, if you think carefully about your development and build process. Also, moving shared code to a separate project in version control does not necessarily mean that it should be maintained completely independent of the rest of your code. That is more a matter of the surrounding process and project management. On the other hand, this scenario allows for maintaining the library independently. In your current situation you don't even have that choice.

Answer 3

A vote for Mercurial!

With that off my chest, I would agree with the other posters that you should pull any files you duplicate into a shared location. If you use Mercurial I'd have a lib or common directory which is a a mercurial repository, and then a separate folder/repository for each project and it's unique code.

I'm not a C++ (I'm guessing that's what we're talking about :P) programmer, so I can't answer specifically what you should do for those particular files, but in general you should identify files which you anticipate always being the same, and put those in a shared repository, and files which are only coincidentally the same, or only the same for now, should be in separate repositories and treated as if they are completely unrelated files.

Hope that helps!