Subversion and shared files across repositories/projects?

Question

I am migrating a client's SourceSafe repository (3 projects) to SVN and two of the projects share source files. (These projects are separate products - with different names and release versions, etc)

Has SVN resolved this shortcoming? How do people generally handle this scenario?

Of the options I know about/can think of

• Use the external or extern or whatever for SVN. I hear this is not a good option for various reasons

• Create a new project (maybe called shared) that contains the source. The problem with this is that we still have to get that code (it is not a library) and import it into the project somehow. It can be shown to be the same problem as the one above and it introduces the overhead of an additional product/project.

• Just check in the files in both repositories and cross-update them. This requires developers to know about the sharing and to remember to check in. I suppose I could write a script that checks all known shared files and updates them when needed.

• Have one repository for the two projects that share. This leaves me with the problem having to create a top level project/repository that contains the two and it is a problem for labeling. I do not really want to label the top pseudo project. (the tags, trunk and branch things are not exactly where I would want them.)

I will probably go with the last option.

Any other comments?

thanks

Answer 1

Using a trigger to update the files sounds like a bad idea. Somehow they are going to get out of sync. Really the solution with shared code is to extract it into a library and use that library in multiple solutions. That sounds to be outside of the scope of your project, though, so the last solution is your best bet.

Answer 2

In my experience it is problematic to have two independent projects referencing the same source files because i may add or change code in the shared file to meet the needs of one project only to break the other build.

It seems that the trick here is to allow each project to advance independently, so however you set up your repositories you want to stabilize the shared code such that it only changes when you want it to.

For example, if the shared code lives in two branches/folders of the same repository or if it is checked seperately into two distinct repositories, or if it lives in a third repository all by itself, you want the step of upgrading that piece of code to be a manual one that does not have side effects, that you can isolate, debug, and bugfix against.

I have factored this code out into a third repository and then i periodically migrate that code into my dependent project repositories as internal release and upgrade steps; My individual projects then have a revision that looks like "Upgraded to v4.3.345 of Shared.App.dll" which includes all changes needed to work against that version.

If the shared code is part of the same repository as the two dependent projects, then have a separate copy of it in each project and use repository merges to propagate your changes.

Answer 3

The safe way to do it is to have a third project that builds the shared source into a library that is used by the other two. The library project has it's own SVN repository.

You can even do this with shared files that are just headers, simply leave them in the lib project directory and add it to the list of includes.

Having the same file in two projects, even with soruce control is asking for trouble sooner or later!

Answer 4

Have one repository for the two projects that share. This leaves me with the problem having to create a top level project/repository that contains the two and it is a problem for labeling. I do not really want to label the top pseudo project. (the tags, trunk and branch things are not exactly where I would want them.)

Like others, I would surely do it the last way. What do you feel is wrong with having 'just' one repository? Repository is about admin rights. Other than that, I would see a single repo have any N number of projects in it.

Answer 5

I don't know what exactly you heard about svn:externals, but I think that's what you should use here. You can even specify your external to point to a stable branch or release tag of you shared source, or even point to two different tags from the two other projects that use it (you might need this if you fix some bug in the shared code ASAP for project A, but you don't have enough time to test it fully with project B).

The worst thing you could do is your option 3 (cross-updating two versions of the same files).

Answer 6

Use one repository, of course. There might be more shared code later on.

What exactly is the problem with tagging? So you have an extra folder in the tag, but it doesn't cost you space. If you really don't want that extra folder, here's an idea for organizing the tree:

• /
  • trunk
    • prj1
    • prj2
    • shared
  • tags
    • tag1
      • prj1
      • shared

That is, when you want to tag prj1, you create tag1, then copy prj1 and shared into it.

Answer 7

You don't mention what language or build tool you are using, but for Java projects, Maven may be worth looking into. One of features is that is essentially extends ant to allow you to pull in external dependencies. That relieves one of your concerns about having to create, maintain and label a meta-project. It also allows you to either pull from HEAD of the external project, or pull from a given tag, which relieves one of the concerns by a previous poster about sharing common files between projects and inadvertently causing breakage, because you can control when each project uses a newer version of the shared files independently.