54

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.

Improve this question
20
  • 113
    Fire your programmers.
    – Bernard
    Commented Jul 17, 2012 at 17:11
  • 11
    Give them a branch each. Enforce daily checkins.
    – user1249
    Commented Jul 17, 2012 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 ♦
    Commented Jul 17, 2012 at 18:49
  • 10
    @Jan_V Nothing in SourceSafe is easy.
    – maple_shaft ♦
    Commented Jul 17, 2012 at 18:58
  • 30
    I'm not familiar with TFS, but this question reads like an advertisement for Mercurial or GiT.
    – Jim In Texas
    Commented Jul 17, 2012 at 20:53

7 Answers 7

Reset to default
78

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.

Improve this answer
3
51

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).

Improve this answer
2
  • 6
    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
    Commented Jul 18, 2012 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
    Commented Jul 18, 2012 at 8:41
39
  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

edit

  • Put version control on your work computer.
    • You can do this right now w/out team coordination
    • Even with team version control, I highly recommend this
    • If your team uses Git or Mercurial you are using an independent, local repository. That's how distributed version control works.
    • You can use different VC software from your team. Our team uses Subversion, I use Mercurial locally. The VC software metafiles (".svn", ".mg", hidden folders) do not conflict.

You are not acting as a de-facto team repository. It's for managing your own work, refactoring efforts, etc. and CYAing yourself as the team continues to FUBAR the code base.

end edit

Improve this answer
2
  • 3
    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
    Commented Jul 18, 2012 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
    Commented Jul 23, 2012 at 14:58
14

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.

Improve this answer
8
  • 9
    What's wrong with using TFS?
    – Bernard
    Commented Jul 17, 2012 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
    Commented Jul 17, 2012 at 17:14
  • 4
    Distributed version control systems don't always make sense.
    – maple_shaft ♦
    Commented Jul 17, 2012 at 18:48
  • 3
    -1: Despite what the evangelists claim, the distributed revision control is not the answer to every problem, and would not solve this one.
    – mattnz
    Commented Jul 18, 2012 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
    Commented Jul 18, 2012 at 17:43
8

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):

Improve this answer
5

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).

Improve this answer
1

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.

Improve this answer

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