0

We currently have a large solution in C# which is comprised of some 40 projects.

A second solution for another client is almost identical, and uses many of the same projects with some omitted, and some others included which are not present in the first solution.

To make code versioning more manageable, I would like to check in each project contained within the solution to SVN as individual projects, however none of the SVN clients I have tried seems to support this without manually adding each project in turn.

The desired outcome is :

1) Open the solution for Client A, and make changes to a common project 2) Commit the changes, then close the solution. 3) Open the solution for Client B. The changes made in '1' are available in Client B solution. 4) Make changes to a project specific to client B. When these are committed, the changes from '1' are not shown up as pending.

I have tried AnkhSVN, and VisualSVN, but in both cases, selecting projects and running Add selected projects to Subversion gives me the option to add the root solution, but not the projects individually.

The closest I have managed to get is with Tortoise, but that involved adding each project manually which is not a feasible option for so many source projects.

EDIT: As suggested, using a common solution and two separate client specific solutions would resolve the issue of committing the code to SVN, but would require compiling against DLLs which would have to be compiled ahead of time.

We did experiment with this approach initially, but due to issues with VS not correctly reloading DLLs sometimes, we had issues with debugging.

I'm not certain whether it is possible to add projects this way using an automated process, but would welcome suggestions before I bite the bullet and write some code to do it.

Many thanks.

Alex
  • 1,643
  • 1
  • 14
  • 32

1 Answers1

1

I would recommend 3 total solutions in this scenario:

  1. Client A solution
  2. Client B solution
  3. Common solution

Each can be backed by its own repository. Now you can publish your common code as a set of dlls (or you can get fancy by setting up a private Nuget server and turning your common solution into a Nuget package) and reference it from the client solutions.

Dave
  • 900
  • 6
  • 22
  • I did consider this as an option. The issue is that when we are testing, we need the code for the entire solution present in the IDE for debugging. Initially, we did compile against DLLs, but found issues with debugging. So far, a Nuget repo for the common code is the closest to what I'm looking to achieve, but it's still not quite there. I'm not certain SVN was ever designed to be used this way. – Alex Aug 08 '16 at 20:14
  • That's what tests are for :) – Dave Aug 08 '16 at 20:17
  • Yup, but for the moment, we don't have many unit tests for the codebase. I've been working on refactoring it and putting tests together, but time constraints have made progress very slow. We use a build script to generate the final release, but that does not push any compiled artifacts to a server as yet. Essentially, I am trying to get similar behaviour as a Maven project (but without the POM hell). – Alex Aug 08 '16 at 20:20
  • I bit the bullet in the end and wrote a tool to upload the projects individually, ignoring the solution. As the structure is unlikely to change, this will work as short term. Long term, a test suite and the client specific solutions is the way to go. – Alex Aug 09 '16 at 15:00