Is there something wrong with how we're doing version control?

Question

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.

Being that I have little weight in the technical department, what's the best way to approach this without seeming like I know more than they do (which I don't)? I actually have suggested the branch thing because I did read up a bit on version control, but they would come back listing reasons it would not work. — Ryan, Jul 17 '12 at 17:17
Basically the reasons not for doing it was how to keep the branches in sync. So if a change is made to version 2.0, how to migrate that change to the next version, ie 2.1 and keep everything in sync. — Ryan, Jul 17 '12 at 17:48
@Ryan You'd make the same change separately to the new branch ASAP. It's a good idea to get the same developer to do it if it's a complicated change. It might be possible to do it using the SCM tool but they're all different. I'd add that putting code changes into a Steady State branch is a big deal and shouldn't be done on a whim, if a customer demands it then fine but there comes a point where it should be considered Closed For Business. — James, Jul 17 '12 at 17:51
@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
@maple_shaft: this is not a legacy project. Actually this is a completely new application that has replaced an old legacy project. — Ryan, Jul 17 '12 at 18:52
Even in old version control systems, like SourceSafe, this is easy. I've done it tons of time. — Jan_V, Jul 17 '12 at 18:57
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
+1 to the BA who felt something was up. I'd take a spec from you any day. — Matt Stephenson, Jul 18 '12 at 04:03
@JimInTexas I assure you, SVN handles this in it's sleep, it's the users who don't know their arse from the their elbow... — cmannett85, Jul 18 '12 at 08:33
@cbamber85, I could have called rebasing in svn a nightmare, but I've used clearcase before, so yes, subversion is not nearly as bad. I suspect, even TFS is not that bad and can provide a decent solution to this problem. — SK-logic, Jul 18 '12 at 12:09
Won't the fixes to 2.0 need to get into the 3.0 code base eventually anyway? So, they will need to do a merge at some point - might as well use the TFS tool to do so, which it is designed to do. — Wonko the Sane, Jul 18 '12 at 12:25
Ryan, you're working with crummy programmers. Dunno how else to say it. You're not alone in this problem--good programmers are hard to come by. — riwalk, Jul 18 '12 at 17:35
@Stargazer712 re: the level of programming skill - is that to be expected when doing internal software for non-software companies? I'm considering a BA role in another firm - the firm is a tech consulting company but the role is developing internal software. — Ryan, Jul 18 '12 at 22:18
Yes, you are doing something wrong with version control: not using it. — Kyeotic, Jul 18 '12 at 22:53
As an update, I conveyed these suggestions to the technical manager and she agreed with them. They will implement branching on the next release cycle. Thanks for all of your input. I have a feeling that some of the developers may hate me for this, but so be it - I think it will be better for the group. On another note I am going to be assuming a QA oversight role so this plays into those responsibilities of making sure we have a strong process from beginning to end which I believe includes version control. — Ryan, Jul 19 '12 at 20:01

score 78 · Accepted Answer · answered Jul 17 '12 at 17:09

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.

answered Jul 17 '12 at 17:09

James

4,328
3
21
25

6

MS has a white paper on exactly this subject (which covers things in far more detail): http://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) http://nvie.com/posts/a-successful-git-branching-model/ – BZink Jul 17 '12 at 23:03

score 51 · Answer 2 · edited Apr 12 '17 at 07:31

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

edited Apr 12 '17 at 07:31

Community

1

answered Jul 17 '12 at 17:24

gnat

21,442
29
112
288

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 Jul 18 '12 at 05: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 08:41

radarbob · Answer 3 · 2016-12-22T16:13:53.830

Your dev's have a fundamental misunderstanding of how to use version control.
Do not get into a discussion about the "right" version control software. This is not the problem.
Every code tweak is making the problem harder to fix.
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.
The dev's must be feeling the pain enough to at least sit down and talk about it.
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."
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.
Here is a decent tutorial. It is general and complete enough that you don't need to scour lots of other sources
- Version Control, Better Explained

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

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

score 14 · Answer 4 · answered Jul 17 '12 at 17:07

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.

answered Jul 17 '12 at 17:07

jdl

629
3
9

9

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. http://stackoverflow.com/questions/4415127/git-vs-team-foundation-server – 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
1

@maple_shaft Do you have an example to back that statement up? – rjmunro Jul 17 '12 at 23:22
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 Jul 18 '12 at 04:03
@Bernard: I think a shorter list would be "what's right with using TFS?". The "wrong" list includes: Windows-only (forget the long-abandoned Eclipse plugin); centralized; massive system requirements; hopelessly awful command line utility; checkin/checkout workflow; write-protected local files as a checked-out indicator (what were they thinking?!); dreadful bug tracker UI; etc... – Ant Jul 18 '12 at 17:26
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
@mattnz distributed revision control is not the answer to every problem, just to every problem either solved or caused by centralized revision control. – Jeremy List Jun 17 '15 at 03:03

score 8 · Answer 5 · edited May 23 '17 at 12:40

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

score 5 · Answer 6 · answered Jul 18 '12 at 03:30

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

score 1 · Answer 7 · edited Jul 18 '12 at 16:43

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.

Is there something wrong with how we're doing version control?

7 Answers7