Being careful is usually enough to prevent problems, but sometimes I need to double check the branch I'm working on (e.g. "hmm... I'm in the dev branch, right?") by checking the source control path of a random file.

In looking for an easier way, I thought of naming the solution files accordingly (e.g.MySolution_Dev.sln) but with different file names in each branch, I can't merge the solution files.

It's not that big of a deal but are there any methods or "small tricks" you use to quickly ensure you're in the correct branch? I'm using Visual Studio 2010 with TFS 2008.

This sounds like a good candidate for a VS 2010 Extension to be written which allows some sort of configurable visual cue to indicate the branch. Perhaps colorizing the background of the Solution Explorer as per user settings (I'd do green for Dev, yellow for QA and red for Prod).
–
Jesse C. SlicerOct 14 '11 at 15:58

Nice idea, even an indicator on VS title bar would help.
–
henginyOct 14 '11 at 16:10

1

I'd say that should be pretty effective. I have my bash prompt set to include my git branch and whether the source files are clean or if they need a checkin
–
DaenythOct 14 '11 at 16:58

Does TFS not have something equivalent to git status or hg status?
–
user8Oct 14 '11 at 17:59

I use VS user interface for TFS operations, so I don't really have an idea.
–
henginyOct 16 '11 at 10:44

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:

Actually working directories are named differently. But with an already open Visual Studio, (for example after I take a coffee break and return to my desk) I have to check the path of a file to see the directory. So I guess it's the simplest way and no escape from that?
–
henginyOct 14 '11 at 13:18

2

@henginy That's a good clarification. To determine that in Visual Studio, I hover over the tab of an open file. It will display a tooltip of the full file system path, from which I can determine whether the root is "-dev" or "-trunk." Try that and see if it works for you.
–
Matthew RodatusOct 14 '11 at 13:45

1

Yes, that is exactly how I "check the source control path of a random file", and I'm trying to find a quicker way:)
–
henginyOct 14 '11 at 13:59

@henginy Oh, right. You said that in OP. I don't know of a better way off the top of my head. Sounds like I haven't improved on your situation at all. :-(
–
Matthew RodatusOct 14 '11 at 16:18

I should've clarified that better in my question. Thank you for your help!
–
henginyOct 16 '11 at 10:40

I do a lot of my (D)VCS work from the command line. I highly reccomend having your prompt display where you are at. For instance, my prompt when in a Git repo looks like (I do this for SVN too):

[BranchName]RepoTop/path/to/current/wd >>

And if the repo is currently dirty (uncommitted changes):

[BranchName!!]RepoTop/path/to/current/wd >>

I also have the background set to red if logged into prod, things like that. I find simple visual notifications to be super effective for me.

You mentioned that you often see this most after coming back to your computer. I find a post it note, with my current focus (branch, bug #, feature) stuck to my keyboard when I leave, to be super effective in allowing me to get back to work quickly, rather than recreate whatever it was I did last.

I've been using VSCommands extension (with Visual Studio 2012, but there is a 2010 version) and it conveniently puts the branch name in the upper left corner of the screen as well as into the solution explorer.

I avoid working in the wrong branch by doing almost everything in one branch (in trunk - per so called "unstable trunk" branching strategy).

The cases when I am forced to update branches are pretty rare - these are pre-and post-production bugfixes (prod candidate code is isolated in branches). Since these fixes should be in trunk too, I typically draft, test and verify them right there in trunk, then port to prod branch. Porting as a rule involves just a straightforward copy of 1 to 5 files to branch and build check.

I am also somewhat lucky that in most of my projects management preferred to convince customers to use newer releases instead of patching old ones - this brings post-production part of updates in branches to almost negligible minimum.

It's indeed nice not to have to maintain previous releases. In that case I'd only use a branch for experimental purposes I guess.
–
henginyOct 16 '11 at 10:35

@henginy I can't recall cases when I had a luxury of not having to maintain previous releases at all. However, management attitude can make a big difference here: depending on it one can eg either implement 1-2 hotfixes/year in older branches or mess with these half of all the time
–
gnatOct 16 '11 at 20:39

A specific answer depends on the version control software that you're using, but there's usually a command that lets you easily see the branch you're working on. For example, with Subversion, use the svn info command in a directory to see the URL for that branch. If you're more interested in a particular file, you can specify that too:

From the URL, I can see that my copy of foo.c is in the caleb-dev branch.

I don't need to do that very often because my local directory has the same name as the branch. A quick look at my command line prompt is usually enough to confirm that I'm in the right directory, and therefore working in the right branch.

Lots of answers here already, but none that touches on the simple solution we have where I work: for each branch, create a new VM containing a dev environment, and check out from the proper branch. You only have to do that and get it right once, and then you just switch VMs to switch branches.