Comment by dybber
3 days ago
We had a similar setup, also with a homegrown VCS developed internally in our company, where I sometimes acted as branch admin. I’m not sure it worked exactly like Source Depot, but I can try to explain it.
Basically instead of everyone creating their own short-lived branches (expensive operation), you would have long-lived branches that a larger group of people would commit to (several product areas). The branch admins job was then to get the work all of these people forward integrated to a branch upwards in the hierarchy. This was attempted a few times per day, but if tests failed you would have to reach out to the responsible people to get those test fixed. Then later, when you get the changes merged upwards, some other changes have also been made to the main integration branch, and now you need to pull these down into your long lived branch - reverse integration - such that your branch is up to date with everyone else in the company.
At least in the Windows group, we use ri and fi oppositely from how you describe. RI = sharing code with a broader group of people toward trunk. FI = absorbing code created by the larger group of people on the dev team. Eventually we do a set of release forks that are isolated after a final set of FIs, so really outside customers get code via FI and then cherry pick style development.