Tag Info

Hot answers tagged

145

One thing I have gotten in the habit of doing is always looking at the diffs of every file I'm about to check in, right before I check them in.


87

Oh wow, yes. I use both SVN and Git and I cannot tell you how many times they've saved my ass. More Git than SVN, but let's not start flamewars here. This is on projects I work on by myself, as well as projects I work on with other people. No excuse not to, really. As a human, I'm basically entitled to do stupid shit all the time. By using version control, ...


71

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


61

You should never check-in commented-out code. If you have code that needs commenting out before check-ins, you are doing it wrong. As for rules: Get latest Fix merge conflicts Build 3.1 Fix build errors Run tests 4.1 Fix broken tests Go to 1 (until there is nothing new to get) Only check in when all steps are complete. See check-in dance. Other ...


58

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


49

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


38

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


23

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


20

I'm not trying to be too much of a pantsweasel here, but the assumption in this question (and all but one of the answers) mostly applies to Centralized VCS, such as TFS, SVN, Perforce, etc. Fair enough, it's what the OP is using. On the other hand, however, when using DVCS (such as Mercurial and Git), you usually shouldn't wait to checkin, and most of ...


19

As a general rule, source control is best used for source only, and generated files are not source. There are exceptions. Sometimes (using Visual Studio) you might want to keep the .pdb file for reading minidumps. Sometimes you can't duplicate a toolchain, so that you can't necessarily recreate generated files accurately. In these cases, you're primarily ...


18

Mercurial I like Mercurial provided you install TortoiseHG and VisualHG tools. The best feature is that you can create a "branch" to try out some funky new code by just copying your enlistment directory in Explorer. This copy will sync back to Codeplex without changing any settings if all goes well. If it goes poorly, delete the directory and 'all is ...


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


15

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


13

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


12

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


11

Both will do what you need. At my last job we started with SVN and moved to TFS later. Our team consisted of 8 developers and 3 QAs. TFS was nice b/c it had built in VS support, built in ticket tracking, and you could lock files. We also used the SharePoint to keep track of all the documents and meeting notes for each project. It was a very nice and ...


11

When I started at my first job I worked on similar projects (but with smaller scale) and we faced the same problems. We also started with general solution handling requirements for all clients but that was possible only to same point where requirements become contradictory. We did what you suggest and started separate version for each client. Even this ...


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


10

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


10

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


10

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


10

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


9

Yes, a developer should always use version control, of some kind. Who knows how big a project may become, or how many people may be using it, or what bug you've just introduced. VC should go hand in hand with off-site storage of the project too.


9

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


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

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


8

Three things that I didn't see in other answers: Include new files Look for new files that aren't part of your changelist May be specific to SCMs like Perforce -- you have to tell it everything that's in your change. Revert unchanged files I hate when I'm looking at other people's changes and there is a changelist with nine files but only three of ...


8

Actually, I would suggest that you do not need a branching model, but rather a complete comprehensive approach to deal with the multi-dimensional constraints with regard to the system without branching. In practice, I believe it will always be a problem to maintain multiple systems that have some commonalities but will evolve differently in branches, so it ...


8

I don't work in a generic dev or trunk branch. I ALWAYS do work in feature branches. When a feature is done, I follow these steps. Open Source Control Explorer. Merge from dev into current feature branch. Fix any conflicts and ensure everything still works. Check in again. Merge feature into dev branch. Open dev solution. Checkin dev branch. Close ...



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