92

It's not a training issue, it's a human factors issue. They do not want to, and are creating road blocks. Deal with the broken group dynamics, what is the root cause of their objection - usually fear, is it just fear of change, or is it more sinister. No professional developer today, or for the last 20 years, has resisted source control. Once, about 30 or ...


77

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


40

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

Sometimes, real world issues make it impractical to use. False. If the team is not used to using source control, training problems can arise That has nothing to do with source code control and everything to do with training. Training is easy, cheap, efficient and done in a matter of hours. Failing to use source code control is costly, risky, ...


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


19

The advantages git has come from tossing out a lot of old assumptions about what a VCS should do. The disadvantages git has come from not being able to leverage prior experience and not being able to do things the way you are used to. If you are going to switch from something else to git, try to start tabula-rasa (though it is impossible to truly do in ...


17

Developers who refuse to use source/version control should be fired, simple as that. As you have already pointed out, the inherent risks and costs of NOT using it outweigh any overhead it incurs by many, many orders of magnitude. Anyone trying to argue against this simply should not be involved in software development and I would flat out refuse to work 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

Name the working directories differently. That is, if your project is titled "MY_PROJECT," create a different working directory for each branch. If there is one branch named "dev," then you'd need a directory for trunk and a directory for dev, like this: ~/henginy/projects/MY_PROJECT-trunk ~/henginy/projects/MY_PROJECT-dev


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


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


13

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


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


11

Martin Fowler and Pramod Sadalage have written an excellent article on this subject. Every developer has his own database to which changes can be made. These changes are then communicated back (as a changeset) to the DBA who implements them in the master database, so he's still involved in the process, he probably knows best about the structures and needs ...


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


10

We solved the problem by first, setting up a continuous integration server to build our source control into dev. Second, lock down folder access to read only, to prevent people circumventing source control and modifying files directly. It's a PITA on days where you can't reproduce the bug locally, but other than that it's nicer being able to work, checkin, ...


10

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


9

Should both those stories share similar tasks since the development and design are similar? Yes. Should I break up the features into separate stories? No. Stories aren't features. They're stories. You invent features that will support the stories. It's called "design". You don't -- unthinkingly -- just code from a story. First, you think. Then ...


9

I'm not fond of arbitrary branches i.e. Fred's bugfixes or Harry's bugfixes. I'm much more comfortable with one (independent) feature one branch which allows multiple developers to operate on one feature; but for the feature to be merged only when it's complete. So, right now you only need the "bugfix" branch but once you start development you should ...


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


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