I think not many people have 60+ flows, 4 layers deep, each consisting of 3 components. For the limited number of processes, only 2 layers deep, we just use CVS and common sense/basic QA
We use a large number of flows to better isolate the changes and reduce the risk of collision with the 10 or so process developers. We could model it with fewer flows but we'd have less process re-use and more modeling bottlenecks. The other problem is that the editor gets unwieldy with over a certain number of boxes. We have one flow with 20+ boxes and that seems to be about the max. (I meant to say that our flows have as few as 3 boxes) We use Perforce, basic QA and common sense for that part.
The hard part is branch management. A real app, once in production, typically runs with 3 branches, "production support", "next release" and "future work". The branches are often run by different managers and different schedules. We're trying to figure out the best way to manage the merge and sync process given the fact that each flow consists of 3 components, model, layout and image. Most of our merging and diff tools do a very poor job on XML files. Plain text (java) files are easier to merge because you can bring broken code into the Java source editor and use Eclipse's syntax tools to help put it back together. XML tools are significantly less helpful.
As an aside. Rule engines often suffer from the same problems. They use XML rule definition files which make branch-to-branch merging difficult.