Source Control Opinion

I do not think its the correct way to do. Source control is very wide topic and can not be discussed under one question. However, Approach for source control depends on project. Code checkins should be done on one of the development branch based on the iteration of your project. Then the changes are propagated to integration, pre-release and production branch based on the approach taken.

And generally, code should not be checked in for longer than necessary.

Similar opinion to OriginalGriff on this one, we also use Subversion and the 'trunk' should always be a working copy of your code. You should be able to download a complete copy from the trunk and be able to build with no problems, you should be able to deploy this code at short notice. E.g. a hotfix is required

If there is a large amendment required to your solution, then this is where you create a branch and begin developing against that. In the meantime, other developers maybe working against the trunk, making minor amendments or fixes.

When you've completed your development against the branch, this is where you merge in your branch changes against the trunk to create a new 'trunk' version that incorporates the large development and all fixes that occurred during that development phase.


That's always been my experience with source control anyway!

Same here, if you use TFS let's say you might consider differenct branching strategy to make sure your code is checked-in and correct functionality is not affected untill everything is tested and working.

Just a note of clarification:

We have Development, QA, Release Candidate, and Production branches that we move our code through as it goes through the development and testing process.

The question here is how the production deploy is done. In what order do you build, check in, and deploy?

Because of the size of the company I work with, we have multiple systems in play.
I daily have to deal with:
SourceSafe.... *�$&@(*@#$ pretty much sums that one up.
TFS: Not that bad if the system is set up properly to take advantage of the problem ticketing system built into it.
SVN: Pretty good provided everyone plays by a strict set of rules as far as how trunks/branches/versioning labels are handled, etc.
CVS: I used CVS some time in the distant past and it was effective, if not a little "interface challenged". That being said, I would have to assume that CVS has evolved over the years as well.

We also implement a build server which does a complete sanity check before the application can be staged for release into the next environment.

My suggestion as well mirrors Griff's in that NOTHING should be checked in unless it has been reviewed locally on a developers box by another senior, then the build server does it's thing which should catch a scenario where a dev has a good build, but it breaks a testing rule somewhere.