Edward Thomson

Earlier today we announced the release of Teamprise 3.1, and you might be wondering why you should upgrade. Maybe you haven't run into any big bugs in Teamprise clients (and we hope you haven't.) Or maybe you just don't feel like upgrading for "just a point release". It's true that we only revved the minor version to 3.1, but it's more than just bugfixes: we've also added a lot of good new features.

The biggest new feature in 3.1 is support for working offline in both our Teamprise Plug-in for Eclipse and our Teamprise Explorer clients. Offline support is a big advantage for TFS users who have unreliable network connections - particularly telecommuters and road warriors, who might want to get some work done wherever they are, be it a coffeeshop or an airplane.

If you're an Eclipse user and wish to go offline from your Team Foundation Server (or if your network unfortunately takes you offline), just go to the Team menu and select "Work Offline". You'll be disconnected from TFS, yet you'll still be able to perform all the file operations like you expect -- you can add, edit, move and delete files just like if you were online. When your network connection returns, you can choose the "Return Online" menu option and pend all those changes to the server.

Working offline in Teamprise Explorer is even simpler, you don't need to specifically enter offline mode. Simply make whatever changes you wish in your workspace, and click "Return Online" from the Source Control context menu. Explorer will synchronize your local workspace with the server and pend any changes you made while you were offline.

The Command Line Client has had offline support since version 3.0, so that's nothing new, but it does get some cool features aside from that. We've added an XML output option for many commands so that you can parse the results easily from a script. The "brief" and even "detailed" formats tend to truncate output for easy interactive viewing, but this can be troublesome for scripts. The new XML output should be perfect for getting all the information out of Team Foundation Server.

Those are a few of the bigger features, but there are many more. And seeing as this is still a point release, there are a lot of bug fixes, too. If you want to see all the details, check out the 3.1 release notes.

We've spent a lot of time on 3.1, and we think you'll enjoy it, even if you're not the type of person to upgrade for "just a point release".

Teamprise will be exhibiting at TechEd 2008 Developer in Orlando, June 3 - June 6. If you're interested in Team Foundation Server or source control with Java, you should stop by booth 1426 and say hello.

We'll be giving demos of the new Teamprise 3 and all it's great new features. Hope to see you there!

It's been a long time since I updated my blog, in part because I'm lazy, but mostly because we were busy putting the finishing touches on Teamprise Client Suite 3.0. We're very proud of our 3.0 release, it's got a lot of great new features, and we think you'll be very happy with it.

If you're in the greater Chicagoland area next week, I've been invited to the Chicago VSTS User Group to give a tour of the new version of Teamprise. If you're interested in how Team System can play nice with Java developers, I suggest you stop by and check it out:

The meeting begins at 5:30 PM at the Microsoft Chicago (Loop) Offices:
77 W Wacker Dr, Suite 2300

Please RSVP if you're going to attend.

Even if you can't make it next week, be sure to check out the Chicago VSTS User Group, or another user group near you. It's a great resource if you're a VSTS or Team Foundation Server user!

Microsoft's currently launching the newest version of Team Foundation Server as part of Visual Studio 2008. There are launch events all across the US (as well as in many other parts of the world), so if you're interested in the new features in TFS 2008, check out the events near you at Microsoft's
"Heroes Happen Here" site.

Teamprise will be exhibiting at the Chicago launch event tomorrow, March 11. We're in booth 47 - stop by and say hi if you're attending.

Even better -- our very own Martin Woodward will be presenting at the Dublin launch event tomorrow. Be sure to check him out if you're attending out there.

Otherwise, there are still plenty of events in a city near you - be sure to go check out what's new in TFS 2008!

Sorry for the late notice, but if you're free on Wednesday evening, this might be interesting.

Teamprise was invited to present at this month's Chicago VSTS Users Group to discuss using TFS from within the Eclipse IDE and from non-Microsoft platforms. I'm excited to make a fool of myself speaking in public (and excited to learn that a VSTS Users Group exists in Chicago.)

I'll be speaking with David Dugan who's a Senior Consultant for Sogeti. David will be discussing accessing TFS from older versions of Visual Studio.

Maybe I'll see you there!

My coworker, Martin Woodward has been very pleased with himself lately about his world's smallest TFS proxy. Never one to back down from a challenge, I present the smaller than the world's smallest TFS proxy. It's running on a Mac Mini, which Martin assures me is (just slightly) smaller than his proxy.

Inevitably, someone else like me with an overblown competitive streak will come along and build a still smaller TFS proxy. Being as I'm a jerk, I've decided to hit a point that nobody else will match: this is the first TFS proxy server to run on a Mac.

When I say "run on a Mac", I don't mean that I've got a VM running Windows and Microsoft's TFS proxy server. That's too easy -- we've got a pint-sized TFS proxy actually running in MacOS X, thanks to Teamprise's new Java SDK for Team Foundation Server.

Fortunately, writing against the Teamprise SDK is easy. I didn't keep strict track, but I think that writing this little proxy server took about 10 hours, which probably broke down like:

• 4 hours: figuring out the Jetty servlet framework (for hosting the proxy)
• 2 hours: figuring out the hsqldb database framework (for caching)
• 1 hour: lost to cigarette breaks
• 2 hours: various other slacking
• 1 hour: getting the files out of Team Foundation Server through our SDK

As you can see, our new SDK will let you very quickly one-up your coworkers. Isn't that really what software's all about?

If you're at TechEd, and want to see the (new) world's smallest TFS proxy, or the world's first TFS proxy on a Mac, swing by and say hi. Teamprise is at booth 1333.

Teamprise is very excited to be announcing compatibility with Microsoft Visual Studio 2008. Our Client Suite - Teamprise Explorer, the Teamprise Plugin for Eclipse and our Command Line Client - are tested and known to work against the next version of Team Foundation Server available in VS 2008.

We're very excited about the next version of TFS, as it includes several big performance enhancements, as well as some interesting new features such as support for working offline. My coworker, Ben Pryor has written significantly about using Teamprise with Visual Studio 2008, which is very helpful if you're curious.

Teamprise is exhibiting at Microsoft TechEd 2007 this week. Come visit us at booth 1333 and say hello. We'd love to talk to you about what we're doing with Visual Studio 2008.

Teamprise is pleased to be exhibiting at the JavaOne conference next week, Tuesday 5/8 - Thursday 5/10. If you're attending JavaOne and you're interested in Team Foundation Server, you should stop by our booth to see Teamprise in action.

But you don't need to be registered for JavaOne to visit us! I have a limited number of exhibit-only passes to JavaOne.

If you're in the Bay Area this week and you're interested integrating Team Foundation Server's version control and work item tracking into Eclipse, or you're interested in accessing Team System from cross-platform clients, come check us out at the Moscone Center.

Just send me an email and we can get the passes to you!

This is Part One in my introduction to the Eclipse Synchronize View

I'm not ashamed to admit it: my first time was terrifying.

It was a friday afternoon in late spring, and I was lazily fixing bugs while mostly thinking about what I'd do when I got off work. I wasn't even paying attention - I was just staring out the window when I decided to do a Get Latest. Then, from nowhere, was the Big Bad Merge.

It turns out that one of my coworkers had done a major refactor of our project, and we'd both been working on many of the same files. Automerge couldn't handle it - oh no, these changes were nasty and invasive - I resolved them all by hand, well into the night.

The state of version control has changed significantly since then - atomic transactions and bug tracking integration were unheard of then - but even with a version control tool like Team Foundation Server, many of us still have no idea what's coming at us when we do a Get Latest. Many of us have no idea when the Big Bad Merge might appear for us to fight again.

It's a scary thing to live in constant fear of conflicts. Many programmers have strategies for dealing with this unknown... most of them ineffective... Here are some of the coping mechanisms I've seen:

The "Real Programmer"
Many programmers, after their first few Big Bad Merges, develop a strange belief that merging is somehow a "real programmer's" sport. That their successful ability to merge widely disparate codebases is what separates them from those lower echelons of untalented hacks who use crutches like "automerge" to get the job done for them. The eschew tools - preferring to pore over every line of code, fixing even indentation and line breaks, than trust a tool to do the job for them.

Their tales of "that nasty conflict that took all day to resolve" are often accompanied by bragging about how they merged back in "the old days", presumably done on punch cards, uphill both ways in the snow.

This particular coping mechanism is very dangerous, as it's entirely psychological and doesn't actually get your conflicts resolved any quicker or more accurately. It often has the opposite effect, as these are the sorts of people who are prone to throw out their three way merge tools^[1] in a fit of hubris.

You can identify the "Real Programmers" easily as they use obscure operating systems with an 80x24 green on black terminal, and drink black coffee (not because they like it, but because it puts hair on their chest.)

The "Edge Case"
Some programmers have had just one too many of those really hard merges and it's left them shell-shocked and resentful of ever having to do it again. They respond with a little insurance policy - a second copy of the source tree, isolated from the one they're working in, which they keep updated constantly so they know what conflicts are coming down the line.

Unfortunately, the line between "proactive" and "insane" gets blurred pretty quickly and eventually they're spending as much time looking at the changes you've made as they spend actually working. They get farther and farther away from the server's version and closer and closer to that Big Bad Merge they were trying so desperately to avoid. As they realize what's happening, they become increasingly nervous and erratic. They often become angry and will lash out you - after all, it's you that made those checkins, and put their working repository into a conflicted state. (Helpful hint: avoid the "Edge Cases" with an affinity for large caliber firearms.)

Eventually, these programmers will spend a panicked, sweaty afternoon getting their changes checked in and their work repository up to date, and they'll be productive again... at least until the next conflict.

You can identify the "Edge Cases" by their facial ticks, occasional psychosis and their desire to work for the Post Office or TSA.

The "Agilist"
Some programmers get smart, and decide to minimize the cases of the Big Bad Merge by developing a a "checkin early, checkin often" attitude^[2]. Thinking - correctly - that if they track the latest version on the server and make small, incremental changes, they're never so out of sync that they have a really horrible merge.

Ultimately, anybody on a team who uses this style of development is rewarded with few conflicts that are kept small and manageable. This means those developers get an added bonus: they implicitly punish their Lazy, Annoying Coworker^[3] by making them deal with the big bad merges.

The problem with this solution is that eventually your Lazy, Annoying Coworker is going to catch on and adopt this solution for himself^[4]. There are few things worse than a programmer who's simultaneously lazy and annoying and checks in quickly. Soon the Lazy Annoying Coworker will be checking in before they bother to test what they just wrote - or worse, even bother to compile it. Suddenly builds fail due to missing quotes and poor use of semicolons.^[5]

So what's a software hack to do? How does one cope with this constant unknown?

One makes it a known problem -- one gets better tools.

One uses the Eclipse Synchronize View, which I'll demonstrate in my next post.

1. Shameless plug: SourceGear's excellent DiffMerge 3.0 will be available very soon.
2. (I'm not entirely sure, but I suspect that the entire "Agile Methodology" sprung from a really long day of merging branches with CVS.)
3. Not having a Lazy, Annoying Coworker is much like playing poker without a chump. As Amarillo Slim said: "Look around the table. If you don't see a sucker, get up, because you're the sucker."^[6]
4. Or start cleaning his handguns at work.
5. (Being Lazy and Annoying, when you confront your Coworker with this, they'll merely shrug and make you deal with it yourself.)
6. As I've mentioned previously, my coworkers are neither Lazy nor Annoying. I'm sure that you realize what this says about me.

One of my coworkers asked me for clarification on the conflict resolution dialog in Teamprise. If you're not used to version control that allows multiple checkouts - say you're coming from the rather limited world of Visual SourceSafe, for instance - this could be somewhat vague. I thought I'd post a brief explanation of the conflict resolution process in Teamprise and TFS^[1].

For this example, we'll use the simplest of conflicts, what TFS calls "Version Conflicts." These arise when two people have both made changes to a file: say that both you and Bob get $/Foo/Bar.txt at the same time. Bob makes changes to this file and checks them in. You are now out of date with the server, and you have a Version Conflict. When you try to check this file in, or do a Get Latest on this file, you will be prompted to resolve this conflict with a dialog that looks something like this:

This dialog allows you to choose the action Teamprise or TFS should take to bring your changes in sync with the server's changes. You have two all-or-nothing choices: accept all of your changes, discarding the changes on the server, and accepting all the server changes, undoing yours^[2]. For simple conflicts, you also have a more advanced option, the "Merge changes for me", or automerge option. This is available if the changes Bob made don't "conflict" with the changes you made.

Yes, your conflict can have conflicts. If you both made changes to the same lines, then your changes are in conflict. The "Changes" line in the Conflict Resolution dialog will tell you quite a bit about what's going on with the files in a very concise way. The Changes line will show the following information:

Where:
n is the number of changes you've made that remained unchanged in the server's version
m is the number of changes on the server that remain unchanged in your version
k is the number of changes that occurred in both your version and the server's version, but the changes are identical
j is the number of changes that occurred in both your version and the server's version that are not identical

Let's look at an example:

In this case, you have made changes to different portions of the file, and so your changes are not conflicting at the file-level. Your Changes report will look like this^[3]:

Since the changes are isolated, you're offered the "Merge changes for me" option. If you select this, your changes will be automatically incorporated with Bob's changes. Let's use colors to make it clear where these files came from:

Automerge isn't exactly a panacea, though. It only looks at regions of the file to determine whether your changes overlap with Bob's changes, it doesn't look at the context. Just because the changes were isolated in different parts of the file doesn't mean that the file makes sense, will compile, or will run properly. Imagine the following:

Strictly speaking, this file was automerged. Unfortunately, the results are garbage - this new file won't compile. Clearly automerge is often helpful, but you still need to pay attention to what's going on with your files.

So far we've looked at non-conflicting changes - those where you and Bob edited independent parts of the file. But what if you changed the same lines? Imagine the following changes:

Clearly, this is a conflict -- line two was changed in both places. In this case, you'll get what appears to be an odd report at first:

The 1 common is easy to recognize - both you and Bob changed line three to "3", the same value, and the change was in common. The 1 conflict is also easy to recognize - both you and Bob changed line two independently. But why are there 0 local and 0 server changes? And how are there conflicts if there were no changes? Remember, local changes are defined as those which were not mutual conflicts (be it changes in common or conflicts.)

Also note that now that there's a conflict, the "Merge changes for me" option is disabled. Teamprise and TFS will refuse to attempt to automerge a file with conflicting changes, you will be required to merge manually. You can do this by cancelling the conflict resolution, making changes to your version manually, then going back to the conflict (via attempting a Get Latest or a Checkin) and accepting your version.

Merging conflicts is going to be made easier in the upcoming Teamprise 2.1 release. Teamprise 2.1 adds support for external merge tools. These can be configured for all files, or on a per-file-type basis (by file extension.) This allows you to use your favorite diff/merge tool to interactively merge changes in your conflicts. Here's KDiff3 running on MacOS X, resolving a simple conflict:

Conflicts can arise in any source code control software, and the more powerful a solution is, the more likely they are to occur. Fortunately, Teamprise and TFS have a rich conflict resolution system to allow you to resolve conflicts quickly, and accurately, and get back to work.

1. Although I'll be using Teamprise for these examples, our conflict resolution is modeled after TFS for lack of confusion.
2. Usually not what you want, unless you've coordinated with Bob to incorporate his changes, or your changes are orthogonal and you wish to pick the superior solution.
3. Why not 2 server changes? After all, two lines were changed... The comparison isn't line-based, it's region based. One "region", comprised of two lines, was modified by Bob, and since this region doesn't overlap the region edited by you, the changes do not conflict.