Question

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. ( https://www.mercurial-scm.org/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

2. 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.

3. Should we use externals or sub repositories?

4. 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.