Second Mainline Branch to Abandon Source Control Misuse?

Question

I just learned about Source Control this week and came to the realization that my team uses it plain wrong.

• One mainline to commit code to live. No other branches; that's it.
• Branching features turned off for everyone except administrator
• People create manual file backups and leave them littered around, because no branching
• Working directories on shared drive: everyone edits the same files

• Checkout is always exclusive, perhaps by design regarding shared drive files

• Workflow is typically Edit-Checkout-ImmediateCheckin because of the exclusive locks. God forbid someone drops a project to work on something else and leaves it half-finished on the shared drive

The stigma is that source control is put into place for accountability reasons rather than for revision history: checking in to the sole live branch requires a support ticket "so we don't have another Office Space." Our test system is much more free: compile your file from the dev area and drop it into place in the staging area (also a shared folder) and see if it works. People like this freedom.

We are currently migrating our console applications to GUI, so a lot of things are being rewritten. I figure that this is the best time to introduce a change.

I was thinking about adding a second mainline for our new code that will "do it right this time," rather than clean up the mess we have now:

• a new mainline for live code (if only for the new programs)
• a Test Baseline branch under this new mainline for stable builds
• on-demand workspace branches for new features and bugfixes

I've talked with two of four developers and have some buy-in from them, but they are concerned about the complications and extra steps it may bring to their workflow because they've never used branching before.

We use Surround SCM coupled with TestTrack for change request tickets, if that matters. I'm proposing checking in only to private workspace branches, then promoting branches up to mainline as we see fit.

Answer 1

There's no need to start a new repository, just start branching.

Give leaders permission to merge onto trunk, everyone else must create a branch and commit their work there. the only extra complication is having to create a branch (per ticket, recommended) and switch their working copy to the branch rather than trunk. You can get rid of the exclusive checkouts too at this point.

This will make things easier for devs, and will also give you a lot more traceability of what is on a release - it'll be only those branches that were merged to trunk. Once you have release day, you can also create a branch from trunk and call it something special so you have a snapshot of a release you could modify with those emergency bugfixes.