[inglor]

Branching is an overstatement. SourceDepot didn't _really_ do branching.

You had patches you'd float with "changelists" on top of enlistments. Each part large enough in thhe org (for example Excel or Word) gets a "branch" and it gets "forward integrated" and "reverse integrated" to the main "branch".

From your perspective the tool used to submit stuff (usubmit usually) you just push to the same branch as everyone else in your org and if your code breaks things it gets "backed out" by an automatic process.

Using git now is so much nicer.

[drewcoo]

SD was basically P4 with syntactic sugar. You likely didn't have permissions to create branches.

Windows sources 20 years ago used to have a ridiculously complicated branching strategy, driven by middle managers and made worse by having actual devs sneak around the edges to do "buddy builds" of changes with some godawful batch file that I heard may have originated with RaymondC (who was exactly the kind of person to make ridiculous MSFT somehow bearable for the rest of us). It was Conway's Law, somehow twisted and applied to version control. With permissions SNAFUs.

I still see companies today trying to map their org chart into their branching strategy and just shake my head . . . and run away.

[Kwpolska]

Did branching in SD work the Git way (where creating a branch is instantaneous and requires zero resources), or did it work the TFVC/old-style-VCS way, where a branch required creating a copy of all files and took many minutes (probably hours at NT scale)? If you are stuck with this kind of system (why would you be these days?), long lived team branches would be the only sustainable strategy.

[inglor]

> You likely didn't have permissions to create branches

I did, it was just a very long and complicated process. You had to set up a lot of tooling for it and you were strongly discouraged from doing it so in the year of SourceDepot (on Office) I saw this option being used exactly once.