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.