So there are three major points that made component level branching seem attractive, but its possible there are better ways to achieve them.
Point the first: configurations - I think you're right, using branches to keep track of configurations would get messy. Configurations of components would be better stored inside the component revision instead of on a separate branch.
Point the second: revision control - the branch and merge scheme looked viable for this due to the ability to name your own milestones, which could be implemented as a custom revision numbering scheme. The way I see things, having each save generate a new revision is great for keeping track of every little change, but when it comes to releasing a component for machining things get a little inconvenient.
E.g. I release on V.6, need to do some edits, then re-release on V.9. It becomes necessary to either save a released version separately (and if it's used in another assembly that assembly needs to be saved separately and so-on), or keep track manually of which version numbers are the release revisions.
In my ideal world the auto-reving would continue, but I would have the option to, when I'm happy with my design, name the revision under my own scheme - e.g. A,B,C etc.
So the revision history would go something along the lines of:
auto1
auto2
A (auto3)
auto4
B (auto5)
At my company we're actually using 4 different revision schemes we call proto (0-99), eng (0-99), release (A-Z), and obsolete (OBS). So my absolutely ideal scheme would go:
01 (eng)
auto1
02 (eng)
auto2
auto3
A (release)
auto4
B
...and so on.
Point the third: branch-merge on sub-assemblies - What I'm looking for here is the ability to perform branch and merges on sub-assemblies that will remain linked to the parent assembly. So any changes pushed onto the subassembly also get pushed onto the the main assembly.
Maybe this is still viable at a project only level; perhaps a sub-assembly branch that gets pushed onto the main assembly master branch? I'll look into it.
