We have a C codebase, in maintenance mode, which supports a number of build personalities, for a given board architecture.
We are launching development of generation 2 of the product, which uses a new board architecture. Generation 2 will replace generation 1 (we aren't making any more Gen 1 boards). Generation 2 will require a good chunk of the code to be rewritten completely. I'd say 50% of it. OTOH, there is some code that will just stay the same. Making the build modular to support both types isn't worth it to us. So we're essentially going to permanently fork the project into two products.
We currently use a scheme in our repository of having a
master branch for production releases, a
testing branch where we accumulate "blessed" work, and individual branches for different development units.
So we could:
- Make a new git repository, copy the code from the old into it and take off and see where the future takes us.
- Keep the same repository, but just add more branches.
The Pros/Cons as I see them are:
- Two Repositories
- Pros: Branches stay simple. Forced to have a repository for each loaded if I need to compare
- Cons: Can't cherry pick between the two (we rarely do this though)
- One Repository, Different Branches
- Pros: Code all stays in same branch, maybe able to leverage some "cross branch" features of git
- Cons: Have to annotate the master and testing branches for the two different things to disambiguate them
I'm looking for advice/experience that would lean one to go one way or the other.