0

We are currently developing a slightly larger C# project. However, we are struggling with the structure inside Visual Studio.

The Solution contains multiple projects, which are dependent on one "base" project. 

e.g.:

Solution      
- Base Objects
  - Project A
  - Project B

We now want to work on one "master"- version, but also be able to create a few specialized versions, which are not affected by changes to the "master" - version.
(But we also want to update the other versions when the "master" - version is changed.)

e.g.:
Master 1.0 -> Master 1.1 -> Master 1.2
                    | Update Test Project?
                    V
Test 1.0      Test 1.1

(We are currently using AnkhSVN and have worked with Team Foundation in the past.)

  1. What do we have to keep in mind regarding our project-architecure?
  2. Is AnkhSVN/Team Foundation the right solution?
    (There are multiple people working on the project)
  3. If yes, how do we organize our trunk/branches
    (One trunk for each project, or keep the master as trunk?)
  4. How can we update our specialized versions, without overwriting their own changes?
MIT
  • 1
  • do you mean 'project' in the visual studio sense, or the project management sense? – Ewan Apr 13 '15 at 15:25
  • Project as in management, I refer to the VS-"Project" as Solution. – MIT Apr 13 '15 at 15:29
  • I'd probably have a solution for each project, including the base, then follow [Microsoft's Branch Strategy](https://msdn.microsoft.com/en-us/library/bb668955.aspx). Whenever you need to work on a project with a specific version of the base, you could fork them both at the same time. When the changes are done, merge the changes to the trunk solutions. – Yuriy Faktorovich Apr 13 '15 at 15:29
  • Thank you, that MSDN-Guide seems exactly like the information, we are looking for, thanks^^ – MIT Apr 13 '15 at 15:34

2 Answers2

0

I would encourage you to try git. Distributed source control has a number of advantages you can read about, even here: Using Git with Visual Studio Good tagging and branching, also Sourcetree is a very nice visual tool to work with VS and git: http://www.sourcetreeapp.com/

Community
  • 1
  • 1
Jason Sackett
  • 103
  • 7
0

It sounds like you have the 'versions per customer' problem. If this is the case branching/source control will only help you so much. feature branches and the like are designed to solve the problem of developing features for a single product rather than maintaining multiple similar products.

I would suggest you structure the software itself using a plug in pattern. Here you have a master 'shell' application, which hosts multiple plugins. everyone uses (or has the option of upgrading to) the latest version of the shell app. but each customer can have different or specialised plugins each of which is maintained as a separate solution.

master shell -> feature branch v2

plugin A -> plugin A v2

plugin B

etc

Ewan
  • 1,261
  • 1
  • 14
  • 25