Chris Rathjen : Hatteras

TechEd 2008 FAQ: Branching and Merging with Team Foundation Server

CRathjen — Wed, 18 Jun 2008 21:48:00 GMT

This was the most popular question asked at our booth (and perhaps all of the VSTS area) at Tech Ed Developers 2008. It was asked in various forms, but they all boil down to basically the same question: How should I manage branching and merging?

Some folks are new to the concepts (e.g. many folks familiar with labels, sharing, and pinning in SourceSafe, but want to step up to TFS). Others have a system in place that they're unhappy with. Others have a system that is working, but they wonder (or even hope) that there is a better way they could be going about it.

First, the bad news: There is no silver bullet. There isn't a "right way" to go about this that applies to everyone. Even the solution we use internally has merits and drawbacks.

Now the good news: There ARE some general trends and associated best practices; odds are good one of these will be similar to your unique situation. We also have a lot of resources, examples, and experience that we can share. Finally, we're always open to feedback on what needs we aren't meeting, so if it sounds like you have needs that we can't yet meet, please let us know.

Before I go farther, one disclaimer: I am not an expert of this particular problem space. But, hopefully I know enough to get you started and point towards the experts.

The first resource I suggest everyone check out is the TFS Branching Guidance on Codeplex. This content covers branching and Team Project structures, physical layout, some "anti-patterns", and includes a comparison to SourceSafe.

I'll point to some previous blog posts that relate to this, but first, let me put my own spin on the topic.

In my opinion, there are two fairly common models that a lot of users will fall into (one or the other, sometimes some of both):

You produce one (or a small number) of products, releasing and maintaining various versions over time (be it a website, shrink-wrap software, etc.)
You have a lot of projects going on at once, and most of them have a finite lifecycle. Once it's "released", it goes into maintanence, but typically it makes more sense to spin up a new project than to keep working within the existing one.

For people in the first category, a three-branch model (typically called "dev-test-production" or something similar) works well. Some of the details vary; for example, if you publish to a website, you might re-use your test and production branches constantly, whereas, for shrink-wrap releases, you'd probably create separate versions of these branches for each major release, and potentially additional ones for minor releases. In either case, your ongoing feature work happens in the main branch (or development branches off of it); you branch (or merge into) the test branch when you're ready to stablize for a release, and you branch (or merge into) the production branch when it goes live. On the merge side, you'd take fixes as needed in each branch, and merge them back up (from prod to test, and from test to dev) as needed.

For the second category, a branch per project makes perfect sense. If a given project has a formal release process, you might create the same dev-test-production structure underneath these branches as well. The key here is that the project-specific code and other artifacts are each in their own branch, while in the first model everything lives together.

A frequent variation to this scenario is where there's a set of shared tools or code that spans many or all of the projects. In the SourceSafe world, these are frequently shared, but you can't do that in TFS. Instead, I'd probably recommend a separate branch (and/or project) for the shared components. They probably have their own release cycle - so you make that tools branch the "master" and branch it into each project that needs them. You can then roll out versions to each consuming project in a predictable way. You might also consider limiting (or even preventing) changes to these components from ever merging BACK into the parent from the project branches, but either approach can work depending on your situation.

If neither of these scenarios sounds like your team, please leave comments/feedback - we can probably find a model that works for you.

Finally, here's a few posts that talk about branching and merging:

Buck

Chris

There are several other posts out there, but I think this are good places to start - if nothing else, to turn a few general questions into lots of specific ones! :)

I have a smile...stretched from ear to ear...

Must go faster...must go faster!

CRathjen — Fri, 25 Aug 2006 17:39:00 GMT

In addition to being Jeff Goldblum's favorite one-liner (apparently), this is a pretty common expression for anyone dealing with computers. My experience has been that, aside from the very day you get a brand new machine, you probably wish it could do something faster than it does - load a program, render your Night Elf, shade those pixels - whatever. If nothing else, boot times seem to get worse as operating speed gets better, so waiting for your speed demon to start doing things not-quite-fast-enough is another possibility.

When it comes to working remotely, the problem is obviously more pronounced. Time to login successfully is substantially slower if you don't have a local domain controller. Time to sync and send email is slower when the Exchange server is a 1000 miles or even a continent or two away. And of course, everything is slower if you have to use VPN to talk to 'the home office'.

Team Foundation Server is intended to support large teams - including teams that are geographically distributed, as most of you probably already know. In fact, the team that developed TFS is itself just such a team, with members located in:

Redmond, WA, USA
Raleigh, NC, USA
India
China
(In V1, we also had people in Europe and Fargo, ND, USA)

Yet, they all used a single (dogfood) Team Foundation Server, in Redmond.

It became obvious along the way that one of the most obvious bottlenecks for everyone NOT in Redmond was waiting for files from version control to download. That's where the Team Foundation Version Control Proxy (or AppTier Proxy, or just "proxy" for short) comes into play.

Jason (and then Rob, and now me) took note of a blog post from one of the Teamprise devs, Martin, about how he used a TFS proxy to improve his "get" performance substantially. I won't repeat his post (for one thing, his "slick graphics skill" is much higher than mine), but I will repeat (paraphrase) his takeaway:

Even a fairly modest machine on the remote end of a slow ("narrow") connection can yield substantial performance improvements for those remote users. Here in the Raleigh office, our link to Redmond is often characterized as a "soda straw" compared to the bandwidth at main campus (which I can only describe as stupendous - if it was any faster, pages would be loaded before you finished typing the URL).

Yet, with the proxy, everyone (after the first person, of course) can sync even multiple gigabytes of versioned items very VERY quickly. It's been awhile since I ran any performance numbers, but the basic improvement is that you're almost entirely bound by your LAN's bandwidth, instead of your link's (a difference of roughly two orders of magnitude, in our case). As Martin said, incremental updates don't see the gains as much as a 'clean, full' sync; but on the other hand, we also have a couple dozen users in our office (maybe even 50+), and our branches are measured in gigabytes. Yet, we're still using a modest Pentium 4, with 512MB RAM, and (again) neither CPU nor memory has been a bottleneck.

So, if you have remote users of your Team Foundation Server (or are one), you can get a lot of "bang for your buck" by deploying a Team Foundation Proxy. You can read more about the deployment requirements and instructions here: http://msdn2.microsoft.com/en-us/library/ms242919.aspx

Remind me what to do before I'm...

Team Foundation Server: Why are my files transferring so slowly?

CRathjen — Thu, 11 May 2006 21:59:00 GMT

I'm not sure if anyone "in the field" has run into this (yet), but it's happened to us a couple times internally now, and I figured other folks might be interested in the issue.

We've seen situations where larger files (in the latest case, 100 meg) take an inordinate amount of time to upload (checkin) or get.

After some poking and prodding, the devs tracked the problem to a configuration disparity - the AT's network interface was set to Auto-negotiate link speed and duplex, while the switch to which it was connected was "forced" to 100Mbps, Full-duplex (or maybe I have the server and switch reversed, but either way). Once these two settings were made to match, the problem went away. We've observed it a few times since in various test runs.

I'm not sure WHY this mismatch is a problem (since I'm assuming Auto is still negotiating to 100/Full), but this issue has a very distinct set of symptoms and the cause isn't apparent (unless you just happen to monitor your switch error rates for fun). I used to take a certain amount of pride in my knowledge of networking, but this one throws me every time. Maybe someone out there who admins a switch can enlighten me?

So, if you see file transfers that take way too long - but only for files above a certain size - check your network card settings and compare them to the switch. Hopefully, most of you out there would only have to worry about this setting at most once (per server, anyway).

Q: Resolve dialog is empty even though I have conflicts

CRathjen — Thu, 09 Mar 2006 17:15:00 GMT

Various people have hit some variation of the following:

"When I checked out a file, I got a message saying there was a newer version in source control. But, when I ran resolve, it said there were no conflicts to resolve. What gives?"

There are at least three possible reasons for this, I'll address them in order of most- to least-likely.

You got a warning, but you didn't actually create a conflict yet. This is a more interesting version of the basic "you don't actually have any conflicts" scenario below, and is by far the most common cause of an unexpectedly empty resolve dialog.
Our resolve command only handles conflicts that have already been generated by other commands - usually get or checkin, but merge as well. So, while we try to warn you if you're heading for a conflict, that warning doesn't actually create the conflict; you could see the warning, undo your checkout before making changes, and do a get latest, or you may have good reasons for pending your changes against an older version - we're not going to make a hasty assumption.
If you do want to go ahead and generate a conflict so you can merge/auto-merge your changes, just go ahead and try to check in, or do a get. The good news is that we'll go ahead and bring up the resolve dialog when you create any conflicts (unless you specified /noprompt from the command line).
You don't actually have any conflicts. This might sound like a joke. But, there are several warnings/errors we issue that might sound like something you could address with resolve, but are not actually conflicts. The example that comes to mind is "Unable to delete <folder> because it is not empty." This is actually "just" a warning - we won't move/delete that folder because there are items under it which we are unable or unwilling to delete - unversioned items, or items in use by a process, etc. We'll mark the folder and any versioned contents as deleted/moved anyway (from the server's perspective), but it's up to you to go do any final cleanup (if necessary).
You ran resolve from the wrong workspace. This can happen in VS and from the command line. In VS, remember that whatever UI component has focus when you run File/Source Control/Resume Conflict Resolution determines the workspace for which we'll run resolve. This might be the pending changes tool window, the Source Control Explorer, or Solution Explorer - each of which has an 'active' workspace, and each of which may be different (why they're all potentially different is the topic for a whole different blog, let alone a blog post). Note: If Team Explorer has focus, you won't have the menu option.

To summarize parts of 1&3: TFS Version Control can issue warnings, errors, and conflicts. Resolve will only address conflicts, you must decide how to handle errors, and warnings may or may not require action. Makes us sound more like a compiler than a source control server, doesn't it?

In v1, there's no obvious way to distinguish between conflicts, warnings, and errors. They're in the same color in command line output. We generally return an exit code of 100 if there were any errors, and 1 if there were any warnings or conflicts, but that's not much help if you're using VS. I don't think it will bother most people; in general, if you do something that causes a conflict, you'll also get a resolve dialog at the end of the operation, and you'll be able to resolve the conflicts and move on.

That's all for now.

Alive in the superunknown...

Which came first, the product or the patch?

CRathjen — Mon, 06 Mar 2006 19:03:00 GMT

I'm setting up a Version Control Proxy for this week's manual testing efforts (flavor of the week: OS and product language settings are Japanese, topped off with setting the calendar to The Japanese Emperor Era).

I'm running into a new variation of the chicken-and-egg problem that both confused and amused me. I already knew to install IIS/ASP.Net, but then I ran into some additional wrinkles:

To install the Proxy, an ASP.NET QFE must be installed (which is on the media)
Of course, to install the QFE, the 2.0 Framework must already be installed...
But the product is going to install 2.0 for me? GoTo Step1

Of course, the 2.0 .Net runtime is on the media as well, so it's just a question of running that (it's under "wcu" for Windows Component Update) by hand first, THEN applying the QFE, THEN installing the proxy.

The fact that the installer knows how to install the framework for you is sort of spoiled by the fact that it will never get a chance to do so.

It's one of those situations where a perfectly logical chain of events led to trouble. It made sense to have the installer put the framework on for you at the time the installer was initially created. But, entropy happens, and this is the result.

I suppose we'll slipstream the QFE into the runtime (or perhaps into the proxy install routine) at some point, but in the meantime, you'll have to do a few (more) steps by hand before you can install the VC proxy.

Accessing Team Foundation Remotely: Fast, Faster, Fastest!

CRathjen — Sat, 25 Feb 2006 01:07:00 GMT

We've had quite a few folks asking about TF Version Control's performance, especially in the remote access scenario. Buck wrote up a nice post awhile back on the remote access story; you can still find it here.

The good news is that, even leaving customer needs aside for a moment, the Version Control team has been very motivated to set and meet aggressive perf goals - the Dogfood Team Foundation Server is in Redmond. In the land of main campus, the bandwidth is wicked fast. Like, that kid from The Incredibles fast.

Nearly all of the Version Control is at a remote office in Raleigh, North Carolina. Now, bandwidth in these parts is pretty generous and easy to come by as well (particularly where residential cable modems are concerned), but our network link to Redmond has never been what I'd call wicked fast. In fact, for a long time it was a lot closer to cruelly slow.

One of the features we've developed -- partly due to our own bandwidth woes, but also due in no small part to customer requests and feedback -- is a Version Control proxy server. If you understand what an HTTP web proxy is and how it works, it's a pretty similar concept.

I took over test ownership for the proxy not too long ago, so I've gotten to learn a fair bit about how it works, how it's configured, and of course how much it can improve download performance.

If you've got a set of users with a lot of miles, hopes, or soda-straws-for-bandwidth between themselves and their Team Foundation Server, you'll definitely want to setup a proxy.

My file's bigger than yours!

CRathjen — Thu, 19 Jan 2006 00:04:00 GMT

As you probably know by now, we intend to support versioning even very large files in Team System. Last I checked, I believe the only hard limit was a question of how big your database's hard disk is.

We've had to fix a few issues (and had to get ASP.Net and SQL 2005 to fix a few issues) along the way. One of those fixes lets the Source Control Proxy download very large files faster than it used to (and using less memory in the process, as well) - the difference with a 2GB+ file was rather dramatic.

So, I'm curious. We've gotten data from a few folks on how big their versioned data is "in total" - as in, how much space the whole repository needs, or how much space the latest version of everything represents. But, how big do individual files get for you? What kinds of files are those? I know we've checked in some big crash dumps before, and zips of large collections of files. What other sorts of "big data" do you find yourself want to keep around/version/track history of?

In dreams I see myself flying...

Choose your client. But choose wisely...

CRathjen — Wed, 07 Dec 2005 00:43:00 GMT

As you may know, Team System is not just for developers, but for all members of a software development team - testers, project managers, and architects, as well as developers (and, if you look at XNA, artists, sound engineers, modelers...the list goes on).

Not all of those folks want to install/use Visual Studio, of course. So we're providing a couple of alternatives. The main "out of the box" choice is simplly called 'Team Explorer' (we also call this 'TFC' internally - Team Foundation Client). If installed on a machine with VS2005, it integrates with VS and provides a great integrated experience for developers.

But, you can also install it on any old machine (hardware requirements aside, of course), and still get a pretty big chunk of the Team Foundation functionality (using only a Client Access License in terms of 'deployment cost'). For example, you get the Source Control Explorer and command line client for version control, all the Work Item Tracking features (at least, all the ones I've ever tried to use - I'm not a WIT expert), etc. So, your PMs can review and manipulate work items(in the TFC client, or in Project and Excel, for example). Your branch admin can perform a merge. Your testers can get access to the bug database on a box sitting in the test lab. I'm sure there are other scenarios I haven't thought of.

That leads to my question: How do you think your organization will use the TFC? Only in VS? Will you only install it on PM machines to get access to Office Integration, or would they likely use the client itself as well?

On a related note, what number (or percent) of your team do you think would use "only" TFC, as opposed to installing it to integrate with one of the VS SKUs (VSPro, VSTS, VSTA, etc.).

Beta3 VPC available at last

CRathjen — Tue, 22 Nov 2005 23:20:00 GMT

Buck's latest post has all the details...

TLAs, part 2: ZBB/ZRB

CRathjen — Tue, 08 Nov 2005 21:30:00 GMT

You might not see these as much as RTM or even OGF, but they're the two that are currently at the forefront of the team's minds. The devs are chasing ZBB - the Zero Bug Bounce. I've also heard it defined as the "Zero Bug Balance" or "Zero Bug Backlog", both of which actually make more sense than the common definition. What is ZBB? It's when we've cleared out all of the "old" bugs - the ones that have been sitting around waiting to get fixed. We "bounce" when ALL active bugs are "new"; usually, this means, open < 48 hours (sometimes it's a week, or 24 hours, but 48 seems to work best).

In theory, once we reach this point, we should stay "in" ZBB - as in, you keep your fix rate at least as high as your incoming rate. With a coding milestone, that never lasts - once the next milestone starts, devs cut back on fixing and start coding new bugs (I mean, features) again. So, that's where the "bounce" comes from - you get down to ZBB, and then start up again (on a graph of active bugs over time, the line "bounces" off of the X axis). And of course, even in our run up to RTM, if us testers get the incoming rate too far ahead of the fix rate, then we may "bounce" and ZBB multiple times. But, the goal is to hit zero balance once, and then stay within the 48 hour window.

So, what's ZRB? Zero Resolve Bounce. This is basically QA's version of the same 'progress indicator', when we've closed or reactivated all of the 'old' resolved bugs. Again, during coding milestones, we tend to hit it and then bounce again, anytime fix rates get too far ahead of our close rate. Since devs are pushing hard to hit ZBB, we're naturally having to similarly "step up" to hit ZRB - this time around, we get an extra week after the target ZBB to hit ZRB.

After that, the goal is to keep "clean" - no bugs take longer than 48 hours to get addressed, and no bug takes longer than 48 hours to be closed (or reactivated) once resolved. As the bar goes up, this gets easier - after all, we should be finding fewer and fewer bugs - and more importantly, less and less bugs will be fixed; they'll be postponed, and those take less time to resolve and even less to close.

On a semi-related note, all of these TLAs are not 'technically' acronyms at all, but rather initialisms - we say "Z-R-B", not "zerb" or something wacky like that (though "zerb" suddenly has a nice ring to it).

We've gone from M0 (before I started at MS), through M1, M2, M3 (3.1, 3.2, 3.3), CC (code complete), Beta1, Beta 2, Beta 3. We're coming up fast on our (hopefully) final ZBB and ZRB - after that, there'll probably be one F.inal T.est P.ass, and we'll be out of TLAs to talk about until the one that counts: RTM!!

Time marches on...

What's an OGF?

CRathjen — Fri, 04 Nov 2005 19:45:00 GMT

You may have seen this "Microsoftism" mentioned before - one of our innumerable Three-Letter-Acronyms (TLAs) - the OGF.

But, a casual poke around didn't turn up a summary of what it is and how we use the concept (in MS in general, but here on Team Foundation in particular).

What it stands for depends entirely on who you ask, and what mood they're in. Ostensibly, it stands for "Overall Gut Feel" or maybe "Overall Goodness Factor". When things are looking grim, it's more likely to stand for "Oh God, we're..." (well, you know - that word that comprises the key component of the military acronym SNAFU).

Here's the geek version: OGFs are a system designed to formally recognize and track subjective evaluations of feature/product quality.

Now that I've set your buzzword alarm off, let's try that again. There's a lot of metrics that you can use to objectively evaluate the state of a feature or product - active bugs, bug incoming rate, code churn, etc. etc. But, that's not necessarily what a person's interested in when they ask "what's the state of feature XYZ?" A lot of people just want to know if it's Good, Bad, or Ugly.

So, we create a set of ratings - OGFs. There's one for diff. There's one for shelving. There's one for the Source Control Explorer as a whole. There's one for the 'integrated checkin experience'.

Someone owns each OGF. Their job is to periodically assess, and record, their rating (right now, Excellent, Good, Fair, or Poor - my attempts to get 'Ugly' as an official rating have somehow not been heard). You may be expected to 'back up' a rating - with relevant bugs, usually - but, ultimately, it's "your call" - 'as of build .56, shelving is good'.

Tracking these ratings over time has proven to be a good way to get a 'pulse' of the project. If only 25% of the features are meeting a Good or better OGF, it's obvious that we're a long way from shipping. If 99% are Good or Excellent, it's probably about time to start the "SHIP IT!" chants.

In that respect, you may see one valuable aspect of OGFs - it helps us focus on what needs the most attention. If features X and Y both have 5 bugs, but X is deemed "fair" while Y is still "poor", well, at least one of Y's bugs is probably more important to get fixed. In fact, when we file bugs, we'll mark them as "OGF Blockers" if the bug is sufficiently bad that the affected feature(s) can't meet a 'good' OGF rating. It's sort of funny that we'll take a subjective rating and then turn around and work so hard to objectify it again, but it works. It let's the people not directly touching a feature quickly see the state/quality of that component and some of the reasoning behind it. This lets people "higher-up" figure out where the 'squeaky wheels' are and make sure we're focused on the things we need to do to ship a great product.

So close...yet so far...

CRathjen — Thu, 20 Oct 2005 00:38:00 GMT

There's a LOT to like in the 2.0 version of the Framework and Base Class Library.

But, I ran into something today that I feel is missing. Or at least, it'd be really cool of it was there.

I want to be able to override the ToString method on an enum.

I know, I know - on the surface, it sounds evil. Enums aren't reference types, you nit! They're value types (sort of). But, ever since enum got a ToString() method, I've been running into times I wanted to specialize the way it worked.

Today, the issue was that we want to future-proof some testcases. So, instead of using some strings directly, we want to enumerate their logical values, and use something to handle the logic of taking the logical value and intelligently produce the correct string (in this case, it was to deal with localization, but there's more to it than that).

The simplest thing that came to mind would be to override the enum's toString value. What we're doing instead is a "ConvertEnumToString(enum value)". It's sort of a hack, because an uninformed consumer of the enum won't know that he should use that method instead of calling enum.value.ToString() directly.

Anyone out there have suggestions on a better alternative? I toyed briefly with a static class with properties where we had enumerated values, but that's not viable - can't pass static types as parameters (we have code that wants an array of the enum, for example). A nonstatic class solves that problem but in cases where we just want to switch on the value, now we would have to pass around an instance where we could just look at the value before.

What am I missing?

Shine on, you crazy diamond...

My God, it's full of Edge Cases

CRathjen — Sat, 08 Oct 2005 00:02:00 GMT

I've posted on resolve before, but I figured it'd be nice to come back and see where things stand in the Beta3->RTM timeframe.

When you run get, checkin, or merge, the system can’t always do what you want it to. There are some basic cases – you tried to checkin but you don’t have the latest version of the file, or you tried to get but one of the files is locally writable – that are relatively straightforward to resolve.

Then there are the 1001 edge cases that make my job interesting. :)

We can’t imagine and test every possible scenario, but resolve is one of those commands where we want to get as close as we can. The goal is to make sure your workspace never gets into a state where you can’t work, and to make sure we give you enough data to know how to proceed.

This is one of those posts that has the potential to get complicated (aside: as my fiancé puts it, “Jab myself in the eye with a pencil geeky”); I’ll try to keep it approachable. So, this post will just introduce the types of conflicts and what options you'll be able to choose from when resolving them.

First, one clarification about the way our resolve commands work – you must “generate” a conflict before you can resolve it. The resolve command won’t give you anything to do even if you KNOW there will be a conflict when you attempt a get or checkin; you have to run get or checkin to create the conflict condition first. This sounds a little silly, but it will make more sense once you see it in action. The upshot is that, unless you're using the command line and specify /noprompt for the relevant command, we’ll bring up the resolve dialog for you, so you can go straight into conflict resolution without having to run a separate command.

There are three “classic” types of conflicts: Version conflicts, namespace conflicts, and local/client conflicts. The latter are generally more like “errors”, but we want the resolve mechanism to help the user recover from them, so we generate conflicts.

Version Conflicts

Version conflicts occur anytime you want to perform an operation on an item, but there’s another version of the same item in the way. The most common (by far) is where you attempt to checkin a change when a newer version exists on the server. Similarly, if you try to get latest and have pending changes on an item with newer versions, you’ll get a version conflict.

Your options depend on exactly what the differences are. If you made ‘non-conflicting’ content changes (yes, we’ve overloaded the word ‘conflict’ along with ‘merge’), we can merge the changes together for you (more on content merging in a future blog post, if there’s interest). We’ll let you manually merge content changes. Finally, you’ll always have the option to discard your changes, or ignore the changes introduced in the newer version(s).

Namespace Conflicts

The easiest way to distinguish between the two conflicts is to ask yourself, “Is the conflict dealing with two versions of the same item, or two different items?” If it’s two different items, you’re looking at a namespace collision. The classic scenario is where you try to check in an add, but someone else has checked in a file of the same name since you pended the add (if you tried to pend the add on an existing item, we’d issue and error and refuse up front).

There are lots of other fun and interesting ways to generate namespace conflicts of course. Where either party had an ‘add’ in my example, they could instead have branched from somewhere else, renamed from somewhere else, undeleted (or undeleted from somewhere else), or merged a new item (basically, a branch as part of a larger merge).

Again, your resolution options depend on the circumstances. We always have the standby “Accept Yours” (what you did wins out over what’s on the server), and “Accept Theirs” (the reverse, which is a fancy way of saying “undo my changes”). For rename conflicts, the UI will let you pick a new name for your item in lieu of your original name. The command line will let you keep your name and pend a rename of the server’s item.

Local Conflicts

There one basic scenario here – you tried to get a file, but there’s a file on disk with the same name that does NOT have the readonly attribute set. This might be because it’s an unrelated/unversioned item, or it might be the same file, but you made changes to it locally without checking out first.

Resolve will let you overwrite the file, or ignore the conflict. That “locally writable check” is a basic way to prevent a ‘get’ from accidentally overwriting local data/changes, but we’re not going to make you attrib the file yourself if you’re sure you want to overwrite it with the server version. If you DO have a version of the file in your workspace, the resolve UI also gives you one more handy option: “Checkout and auto-merge”. This does exactly what it sounds like – checks out the item, and starts a content merge of the local contents with the server contents.

This writable/readonly flag check isn’t a proper substitute for an offline mode, but it does make working disconnected a little easier to deal with than if we didn’t have such a feature. I believe it’s a relatively common convention with other Source Control tools as well.

Whew, that’s a lot to digest. I won’t even get into the additional wackiness that can ensue when you try to do a merge – I’ll save that for a future hypothetical post, if there’s interest.

It’s all right, it’s all right, it’s all right…she moves in mysterious ways

The Steering Wheel is Invalid

CRathjen — Wed, 28 Sep 2005 20:02:00 GMT

We wrapped up the Beta3 testpass, as you can probably guess. My favorite questionable translation from the last week of testing: Babelfish claimed an error message generated on the Japanese version of XP translated to "The steering wheel is invalid." After collecting myself, I quickly realized the error message must be "The handle is invalid" -- I don't know whether XP, Babelfish, or the fundamental vagaries of language context are to blame. Also, given the fact that window handles and bugs relating to them tend to drive you crazy, maybe it's not such a bad translation after all.

Beta3's been out for a few days now. The VPC is apparently a work in progress and should be available for MSDN subscribers "Real Soon Now."

We've noticed a lot of traffic on the forums in the past few days, asking lots of good questions, finding some bugs, and in general kicking the tires. The forum is sort of Q&A/troubleshooting-focused, which is good. But, we're always interested in more general feedback as well.

So, have you tried it? Do you have any highlights/lowlights to share, or "Good/Bad/Ugly" experiences or anecdotes?

"SHIP IT!" (virtually)

CRathjen — Mon, 19 Sep 2005 20:52:00 GMT

In the comments for my last post, nearly everyone was asking for VPC images to be provided along with Beta3 itself.

The good news: There will be VPC images made available for the Beta3 release.

The not-so-good news: They probably won't be available on the same day. It takes some time to get these set up properly and make sure they'll work as expected (if it was simple there wouldn't be a big push to publish them, right? :), and obviously it's not one of those things you can just throw more people at to get it done sooner. Look for one more post (probably not much more than a link) once the VPCs are made available. I'm assuming 'made available' implies 'on MSDN subscriber downloads', but I don't know the specifics just yet.

In the meantime, I better get back to that last handful of wacky resolve testcases...here's one: "Dependent rename - d renamed to c, c renamed to b, b renamed to a - get/resolve should be able to unravel in a single operation".