Source control structure for prototype and real implementation

Question

How should we structure a project in source control with prototype + 'real' implementation of the application?

We work on a prototype for a new project and store that in source control (Subversion, but the question should be independent of that) with the following structure in our main repository with all our projects:

[ProjectName]/
  trunk/
    src/
      UIPrototype/
  branches/
  tags/

Along with an intern we work on design for the domain logic, and we plan to start implementation of the domain logic in the following week.

We have thought about the following possibilities:

• a completely separate repository (the intern has few weeks of experience with source control/Subversion)

• a separate project in our main repository

• a branch (e.g. branches/prototype) under the existing project for the prototype and then use trunk for 'real' implementation

What structure would you recommend for this situation?

Answer 1

What we do is have a separate repository called prototypes where we put all of our test/play/experiment/prototype projects. If something is worth it, we move it to its own repository.

Answer 2

Having spent several years as an SCM manager for a large software department with several programs, my recommendation would be to do a branch for the following reasons:

1. If the prototype does not work you can let the branch die at that point.

2. If the prototype works then you can merge it back into a trunk for primary development

3. You can continue to work on the prototype if works on the primary project needs to begin

Subversion is well suited to handle all of these scenarios. You can also use labels to help control your code as well. These should be descriptive as possible so anyone that comes after you can easily determine what the code is for.

Answer 3

We have an application tree, and there are directories labelled 'inhouse' which indicate things not intended for shipment. Both prototypes and internal tools can be developed in this way. Additionally, the prototype code is always handy for reference when we begin a next-gen 'live' project based on our learning from the prototype.