Click here to Skip to main content
Rate this: bad
good
Please Sign up or sign in to vote.
See more: source TFS
I have a coworker who says that the proper use of source control is "to deploy to our production environment and then waiting for a certain amount of time (at minimum a day) to make sure it is correct before checking those changes into our production branch of source control". He says "this is the tried, true and accepted way of doing source control".
 
I've already provided my opinion. I'd like to hear others. Does anyone do it this way? What are your thoughts?
Posted 11-Jan-12 3:17am
Edited 11-Jan-12 3:21am
v2
Rate this: bad
good
Please Sign up or sign in to vote.

Solution 1

I use Subversion, and my rule is: only check in when it works, and is tested.
Definitely, I would not wait for release to production - it gets checked in as I go, so that the latest version can be worked with as you go along.
 
I can see where he is going though - production release is serious, and very hard to roll back from.
  Permalink  
Rate this: bad
good
Please Sign up or sign in to vote.

Solution 2

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.
  Permalink  
Rate this: bad
good
Please Sign up or sign in to vote.

Solution 3

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!
  Permalink  
Rate this: bad
good
Please Sign up or sign in to vote.

Solution 4

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.
  Permalink  
Rate this: bad
good
Please Sign up or sign in to vote.

Solution 5

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?
  Permalink  
Rate this: bad
good
Please Sign up or sign in to vote.

Solution 6

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.
  Permalink  
v2

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

  Print Answers RSS
0 OriginalGriff 278
1 Maciej Los 205
2 DamithSL 193
3 Nguyen.H.H.Dang 190
4 arvind mepani 187


Advertise | Privacy | Mobile
Web02 | 2.8.140709.1 | Last Updated 11 Jan 2012
Copyright © CodeProject, 1999-2014
All Rights Reserved. Terms of Service
Layout: fixed | fluid