Right now we use a very simple system for version control. We have a completely flat master repository for our entire product line. As our codebase grows and we add more products to the product line, this starts to present some serious drawbacks. We'd like to move away from this, especially with out flat style, but there are seemingly fundamental problems with a structured approach, so it'd be great to hear how other people handle these common situations:
Your code's got multiple duplicate files in separate locations. For example, you have:
./somedir/source1.c ./someotherdir/source1.c
All instances of source1.c
are the same, so when someone changes source1.c
, they shouldn't have to make the same change to every source1.c
in each location where it exists. This is kind of where a flat system works, but it means the structure (with somedir
and someotherdir
have to be created to create the correct file structure.
On the other hand, if you have something like this:
./somedir/config ./someotherdir/config
where both instances of config are unique, and they only share a filename. This presents a big problem in a flat system, you end up doing something like keeping them in a flat repository with unique names, and then renaming them as you recreate the product structure. It seems like this is where a structured file system would make things easier, because there would be no inherent relationship between ./somedir/config
and ./someotherdir/config
.
Maybe I am approaching this with a fundamentally bad idea of standard idioms, but as I'm sure you are all aware, when you are making big changes to an existing codebase, it has to be more of a transition than a throw-everything-away-and-start-over situation.