76

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


50

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


39

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


31

You've written down a few pointers for them, but you haven't explained why is your approach better than the one they already use. This may be problematic. If you're in a spirit “We'll do it my way, because I have six years of professional experience, and you don't” (and reading your question, it looks exactly this way), be ready to be hated by your team ...


27

The "Product backlog Item" is indeed the What, the functionality that needs to be built. The Task describes the steps that need to be taken to get there. Many teams are not used to decompose into tasks, they just build what the spec says. For these people it's hard to see them as two separate things. Maybe a simple anecdote would help: See the Product ...


20

One workspace does not allow the same TFS folder to be mapped to more than one local directory. However you can have two or more workspaces for one computer, and each workspace can map a TFS folder to a different local folder. What revisions of files are in each workspace is tracked separately (to keep each up to date you need to do a get in each: easy with ...


17

Martin Fowler's little survey says a lot about the state of TFS in previous years. 'dangerous' is quite right. (I think this refers to the way that it doesn't recognise changes made outside of VS, so you can create a WCF project, then use the external svcutil tool to create your client, then check all your changes in.. but TFS will happily ignore your client ...


16

I am using this http://visualstudiogallery.msdn.microsoft.com/f3f23845-5b1e-4811-882f-60b7181fa6d6 Updates your title to for example: Development\myproject or Main\myproject or Release\myproject Hope it helps


16

For a team of 3-4 devs, you're proposing WAY too many branches. Every branch you create is additional overhead that comes with a cost (time spent merging, keeping track of what's where, etc). You need to make sure that the benefit you get from having a branch outweighs the cost. Keep in mind that the only real benefit to a branch is code isolation. ...


15

Option A. Just using mainline and tagging for release Pros: You avoid merge hell. Keeping to the mainline encourages some best practices like proper release planning, not introducing a lot of WIP, using branching by abstraction to deal with out-of-band long term work, and using the open closed system and configurable features for dealing with ...


14

As per Microsoft on Review code with pull requests: Vote on changes the suggested purpose of each class of approval is: Approve with suggestions : Agree with the pull request, but provide optional suggestions to improve the code. Waiting for the author : Do not approve the changes, and ask the author to review your comments. The author should let you ...


13

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


13

You should create a new repo for each independent project. Why? Someone working on project D does not have to download all the history for E and F. Git repos are cheap to initialize, so you can use as many as you like. It is painful to work with multiple projects at once when they are represented as branches in a repo: When switching from A to B to quickly ...


12

I've never seen a CI system doing any merging. In theory you could set it up to do that but as you mentioned the build will break if you run into any merge issues. CI environments usually have a specific fixed branch as the "build" branch and the CI server will monitor that branch for new check-ins to fire off a new build cycle.


12

I've moved from a company with a largely Atlassian stack (and Mercurial) to a company with a heavy TFS stack. I find two irritations. The first is Source Control. When you've got used to DVCS, switching back to a CVCS is painful. TFS is particularly painful because, for all that integration to work, it insists on being connected to the server at all times. ...


12

In Git, the basic model for pre-commit code review is to have a branch somewhere where it can bee reviewed, then merged with the main stream. This branch may be in the same repository as the main stream or in a completely separate one. Some ways that I've seen done are: Push a branch to origin, and have the reviewers merge the changeset in when they're ...


12

I like the other answers that say to put as much "tooling" code as you can into Iteration 0. However, sometimes, these kinds of tools come up after the project has already started. Perhaps in Iteration 3 you realize you need a generalized XML parser widget to be used on various stories going forward. In that case, the first User Story that relies on these ...


11

"we need a professional tool" oh dear. Let me tell you about the time we scrapped our perfectly working SVN system and replaced it with an 'enterprise' tool that came highly recommended by a consultant and the management. .. actually, no I can't bring myself to document the horror that we endured for the year it was in place before we scrapped it and ...


11

Stick with one TFS Team Project, having multiple becomes a pain when trying to upgrade and has some limitations when it comes to cross team project work items. Instead you should be making heavy use of Areas and Iterations. Split your VS Solution into multiple solutions, one per major application. This will speed up local builds a lot, as well as the ...


11

Important note There is no out-of-the-box feature for this, and usually I try to steer people away from generic tasks like "Test", "Deploy" and have them think about testing all the way through the work and to have them define intermediate tests they want to execute along the way. Generic stuff such a Release Notes and Deployment can be completely ...


9

I personally have Multiple reasons to shelve: I want/need to go home but the current code would beak the build when it would be checked in. it is a backup if I would get sick, other members of my team would be able to get my changes and work on them sometime I am making a change and want to start over but not lose all the code that I have written sofar. ...


9

don't go with Git just because its "pretty cool", use it because it solves your problem in a way that fits with your workflow. As for TFS... Martin Fowler had a little survey. Anyway, you have to define "security" - do you want to protect the source from unauthorised users, or to put a read-only flag on some areas, or even prevent some people from looking ...


9

This sounds like a internal process issue more than a check-in issue. You should work with the person to ensure that they are doing proper testing and debugging to ensure that the code works. If you have a group of testers, make sure he is sending them his changes to test, they are usually good at finding problems. You could also be bringing these ...


9

We make the changes to foundation (Foundation-A) and push them out to the nuget feed as an unstable package. Here's where your problem begins... Don't do that. Any changes to Foundation v1.0 should inherently be valuable to all consumers of Foundation, otherwise it doesn't belong in Foundation. So, when creating the nuget package, do it as an official, ...


8

I don't trust my local hard drive not to crash overnight. Shelving = backup, for me personally. I've also been on teams that use the shelving feature for exploratory/proof of concept coding that might span several days. It let's you see how something might fit into the software without really committing to it too much.


8

My general take on the best practices is that any member of the development team should be able to perform any action on the tree presuming those actions don't do things like kick off a production deployment. In cases where a specific branch / tag / repository does act as a source for automated deployments putting in some reasonable change control or ...


8

I think Jesse has provided a great answer. I'm simply going to try and make it, well, simpler (if possible) :) The Product Backlog Item (or User Story, if you prefer) is usually written like this: As a New Customer I want to register my details So that I get informed of new product releases In a developers head this may translate in to: Create a ...


7

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


7

He told me it's much more secure to use an SQL Sever based tool Define (or get your boss to) "secure": security from data loss or access control? The latter certainly is easier in TFS (and I suspect that's what he/she wants). So the question is who would you block from access? Using multiple Git repositories with limited users performing pulls from others ...


7

The official Agile answer is that this simply should not be allowed. Unfortunately, as you are experiencing, the reality is that this often happens. Sometimes this is because business requirements change too rapidly even for short sprints. Sometimes this happens because of pure bad planning on the part of the product owner. And unfortunately sometimes ...


Only top voted, non community-wiki answers of a minimum length are eligible