Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I work with a team of programmers as the business analyst. We just released version 2.0 of our product and are working on the next version to be released in 3 months (it's an internal software product). Unfortunately version 2.0 has some issues that they have had to fix and we're going to deploy those fixes in a couple weeks. The problem is that we also don't want to deploy the changes that are still being worked on and are not slated to be released for another 3 months.

The programmers decided that the way to manage this was that only the code for the defects will be checked in, and the code for the new enhancements will be kept on the developer's local machines until they are done. I will have to get local builds from their machines to test because if they check in the code and we have to push out another patch to fix defects we don't want to include those enhancements just yet. There is also the problem where the same code file contains both defect fixes and enhancements, so they have to copy the code file locally, then make a change to fix a bug and check that one in, then resume work on the enhancements by taking the local copy they made.

It seems quite convoluted - is there a better way to handle this type of scenario? We're using Team Foundation Server and Visual Studio 2010.

share|improve this question
107  
Fire your programmers. –  Bernard Jul 17 '12 at 17:11
10  
Give them a branch each. Enforce daily checkins. –  user1249 Jul 17 '12 at 17:19
16  
@Ryan The only plausible excuse they could have had would be if this were a legacy project on something old like SourceSafe. Team Foundation Server 2010 however is a really good source control solution that should have no issues managing multiple branches and performing merges of these branches into the main. If they do not know this then they are obscenely incompetent and should be fired. More likely however is that they are actually too lazy or apathetic to feel bothered with branches and merging so they are feeding you a line. –  maple_shaft Jul 17 '12 at 18:49
10  
@Jan_V Nothing in SourceSafe is easy. –  maple_shaft Jul 17 '12 at 18:58
26  
I'm not familiar with TFS, but this question reads like an advertisement for Mercurial or GiT. –  Jim In Texas Jul 17 '12 at 20:53

7 Answers 7

up vote 71 down vote accepted

V2.0 should have had what we used call a 'steady-state branch' (we used Perforce, not TFS) made for it once it was released. Any fixes for v2 would have been made to this branch and then propagated back into the v3 development branch while v3 features were also being worked on, i.e. a defect on v2 would result in a defect also on v3.

Having changes reside on developer's machines for a long time will likely result in an integration nightmare.

share|improve this answer
5  
MS has a white paper on exactly this subject (which covers things in far more detail): vsarbranchingguide.codeplex.com/releases/view/38849 –  Richard Jul 17 '12 at 18:03
2  
And they can still make a version branch in TFS based on the v2.0 build datetime. –  DaveE Jul 17 '12 at 18:31
2  
I've passed this blog post around a lot, I think it's very well written.(relates to git, but still relevant) nvie.com/posts/a-successful-git-branching-model –  BZink Jul 17 '12 at 23:03

Well there are multiple ways to deal with issues like that, generally covered by 'branching' tag, each with own set of benefits and downsides.

But approach chosen by your developers... gee I'll quote it verbally to make sure that I didn't misread...

code... will be kept on the developer's local machines until they are done...

...the way like above is probably the only one that is totally, completely wrong!

What makes it border to criminal to me is that for TFS, there is an excellent, easy to understand, Microsoft Team Foundation Server Branching Guidance - huge and detailed document with branching strategies recommendations carefully tailored and explained for all kinds of different projects (HTML version here).

share|improve this answer
5  
Seriously, the programmers need to go and read that Team Foundation Server Branching Guidance, and not write another line of code until they have done so, understood it, and created separate branches for 3.0 dev and 2.0 bugfixes. –  Carson63000 Jul 18 '12 at 5:07
    
@Carson63000 agree it's well worth reading even for non-TFS guys (like me). The way how Microsoft guys classify projects and especially how they lay out factors to consider when choosing appropriate branching strategy are tool-agnostic and make pretty good food for thought. –  gnat Jul 18 '12 at 8:41
  1. Your dev's have a fundamental misunderstanding of how to use version control.
  2. Do not get into a discussion about the "right" version control software. This is not the problem.
  3. Every code tweak is making the problem harder to fix.
  4. WHEN y'all decide to do the right thing, you cannot continue code changes while you fix things. You MUST stop all development and get the code into version control.
  5. The dev's must be feeling the pain enough to at least sit down and talk about it.
  6. All version control software supports basic concepts:
    • ALL code goes into the version control repository.
    • All code files have version numbers. These numbers increment automatically as code is re-checked in.
    • A TAG marks all code files of a (and at a) particular version. Thus we can TAG the software version 1 release, for example.
    • a BRANCH is a "turn away" from the main trunk.
      • Any and all changes made to a branch do not affect the trunk.
      • You may optionally merge branch changes back into the main trunk at some point.
      • Thus we may experiment without fear of messing up "the good stuff."
  7. Y'all must get the version control "leap of faith" as I call it. TRUST that following basic rules will keep things straight. Inexperience makes us think otherwise, trust me.
  8. Here is a decent tutorial. It is general and complete enough that you don't need to scour lots of other sources
share|improve this answer
2  
Nitpick: "All code files have version numbers. These numbers increment automatically" Some VCS (e.g. Subversion, Git) have version IDs per repo instead of per file, and the version IDs are not necessarily numeric (Git). Of course the basic point still stands. –  sleske Jul 18 '12 at 13:24
    
"per file / per repo(sitory)" versioning. Yep. This is a fundamental differentiation of VC software. I've used both kinds - "country AND western" (+1 to whomever knows this reference). I like the "per repo" model more. –  radarbob Jul 23 '12 at 14:58

What you are describing is a terrible way to use version control. There should have been a branch made for release 2.0, or a tag or some identifier. That way, modifications to that release can be contained and more development can continue to happen.

This article can give you some ideas. It's written with git in mind, but there's no reason that it couldn't work with mercurial as well. I realize that you're using neither of these, but that's also a problem that you should consider fixing.

share|improve this answer
8  
What's wrong with using TFS? –  Bernard Jul 17 '12 at 17:10
2  
Depends on what you're trying to accomplish. The pros and cons are a common topic on SO. This is a decent starting point. stackoverflow.com/questions/4415127/… –  jdl Jul 17 '12 at 17:14
4  
Distributed version control systems don't always make sense. –  maple_shaft Jul 17 '12 at 18:48
2  
-1: Despite what the evangelists claim, the distributed revision control is not the answer to every problem, and would not solve this one. –  mattnz Jul 18 '12 at 4:03
3  
@Ant: Perhaps you are right, but in the context of the original question, I don't think it matters whether TFS is being used for source control. As long as TFS supports branching, it should be utilized by the OP's development team. –  Bernard Jul 18 '12 at 17:43

Quick Answer: Development team should have a separate Production branch to keep deployed code-base V2.0 separate from the Main trunk.

All the bug fixes need to be done in that branch first and then tested and deployed to other branches, in order to keep code in sync.

Your project should also have have several environments for health development like Prod, Staging, QA and Dev (sometimes UAT ). These environments should be set up before going to Production release.

All in all, being ready for bugs and modification is the way to support a released application.

As TFS was mentioned as a version control, i have also compiled list of articles which will be helpful to set health development environment(s):

share|improve this answer

No, because while you are using a VCS, you are not doing version control.

The central concept for version control is tracking difference over time, you are PLANNING on recording some differences, but at the moment most of your changes are unrecorded.

As others have said, you should be using branches. Once you have that setup, you should be checking in all functional changes (ie not every keystroke, but anytime you fix a bug, add a feature, delete a feature or otherwise complete a change such that it still builds and works).

share|improve this answer

I'm a developer and we are given different branch code and db for fixes of current version and a different for enhancements and for later consecutive version.

Once our fixes are done they are merged with production and are deployed we get new fresh branch to work again back to enhancements.

Moreover we follow a practice like if I have 10 fixes for my current version

I write as

//Start Iteration 2, Fix No-1, Branch No-"ABC"
code where I have done changes or fixes or added new code lines
//End Iteration 2, Fix No-1, Branch No-"ABC"

Similarly for other fixes, I just do this for each and every line I change or add for fixing. And just compare and commit. Similarly if they were doing parallel on same branch they can use

//Start Enhancement -1, Branch No-"ABC" 
code where I have done changes of fixes or added new code lines
//End Enhancement -1, Branch No-"ABC" 

Ctrl+Shift+F command and type //Start Iteration 2, Fix No-1, Branch No-"ABC" to search in entire solution helps a lot to find out exact locations, files where code is changed and take fresh code only that part can be used to commit.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.