Offline and back again in VS2008

One of the most painful issues in VS2005 was its quirky offline support.

One of the first features I have checked in Visual Studio 2008 was working offline. And what can I say - it (mostly) rocks!

Let's do it step-by-step.

• You open the solution under source control and there is no connection to the server. What you get is the dialog, indicating offline condition
  
  In Output window pane appears the log message, indicating detailed reason for the offline
  
  Important note: Once the solution is opened offline, next time you open it in Visual Studio the dialog won't appear (but the output pane will show same message every time)
  
  


• If you choose to change files in your solution/project when is offline, you will have a message that file is read-only once you save the changes. There is no indication of "under source control" status for offline projects or solutions
  
  Important note: When working offline, you may edit or delete existing files or add new ones, and these types of changes will be supported when going "online" with TFS server. However, file renames are not supported
  


• Now let's go online. You open solution in VS and you have connection - but tranistion to online will not happen automatically. To sync solution/project back online you should use "Go Online" menu, that available on right-click in Solution Explorer or in "File"->"Source Control" menu.
  
  Once you hit "Go Online" requested, the dialog with changes "Go Online" dialog will appear detailing the changes performed while online. The dialog shows files and
  changes (add/edit/delete) performed while offline. You may choose not to pend the changes for specific files (then the file will remain writable, but will not have pending changes).
  
  Important note: If you did not perform any changes while offline, the appropriate message will appear
  Once online, the pending changes indications will appear in Solution Explorer.
  


• If you want to unbind your solution/project from source control, all you need to do is to go to "Source Control"->"Change Source Control" menu. The message will appear asking you whether you want to go online or permanently unbind your solution.
  

But of course, there were several "Things I did not like":

1. No cancel on Offline dialog - either go offline or ...?


2. No indication for source controlled files in Solution Explorer in offline mode (similar to that of VSS) - only read-only flag on file serves as an indication


3. "Change Source Control" dialog does not allow one to "Disconnect", you can only "Unbind; so going offline happens only when server is not available
   

Overall, I should say I liked VS2008 experience very much (especially as compared with previous version). I can feel that feedback on TFS2005 offline experience was not wasted!

The one and the only non-technical post

As a rule I post only about things technical and TFS related. This post is not going to be technical. Be forewarned!

I just could not pass it. The guy is absolutely hilarious - every picture is in different style, and I liked enormously the sense of humour and diversity of it. So this being Friday and this blog being my personal blog - I will bust the technical only rule for that once!

Here it is - The Perry Bible Fellowship. Or may be this one? A word of warning though - some of the pictures may be a bit risque so parental advisory is strongly suggested.

Have a nice weekend!

Chat with Visual Studio Team System group

Come chat with the Visual Studio Team System group on December 5th!

Join members of the Visual Studio Team System product group to discuss features available in Team Foundation Server, Team Suite, Architecture Edition, Development Edition, Database Edition, and Test Edition. In addition, discuss what's new for these editions for Visual Studio 2008.

There will be two sessions:

Join the chat on Wednesday, December 5th, 2007 from 10:00am - 11:00am Pacific Time. Add to Calendar | Additional Time Zones

OR

Join the chat on Wednesday, December 5th, 2007 from 4:00pm - 5:00pm Pacific Time. Add to Calendar | Additional Time Zones

MSBuild team wants your feedback!

If you ever used MSBuild (and if you have Visual Studio 2005, you probably do it daily) and have ideas how to make it better, MSBuild team is asking for your opinion. And if you use mainly Team Build, that should be of interest to you too, since MSBuild is the engine used to execute all builds.

Dan Moseley recently wrote a post that lists 11 propositions for future MSBuild features (though they numbered from 1 to 12 with number ten missing - I guess ten is unlucky number for MSBuild :). You can spend virtual $100 to rate the propositions and root for the features dear to you.

I urge you to go over there and vote with your money!

Changeset - a unit or set of items?

I came across this post on forums, and thought it is worth to elaborate a bit.

In a nutshell - when you merge from path X to path Y, and specify certain changeset to merge, will all files in the changeset will be merged from X to Y? The answer: no, only files that both under X and in the changeset will be merged.

From one point of view, it is not very logical, since when you select a changeset you probably trying to merge all changes in it. On the other hand, you explicitly specify source and destination path and expect to merge items only under path, so if you look at changeset as a specification of versions to include in the process, rather than as a "container" unit of sorts, the results are logical.

Another changeset usage that I have found to be puzzling for some users, is specifying changeset for "Get specific version". Again, many people assume that changeset here behaves as a unit, and expect to get only files included in the changeset. But changeset instead behaves as mere date/time specification, and therefore versions relevant for that changeset timestamp will be retrieved for all files in the specified path.

Overall, those nuances are pretty important to be aware of (especially if explained to the users in advance).

How to extend TFS-related menus in VS

I wrote a while ago about extending TFS-related menus, and as a follow up just wanted to elaborate a bit.

Usually, the problem with adding menus related to TFS is that the parent menu GUIDs/command IDs are not well known. For example, the following post describes typical problem.

But once the GUID:id pair is known, adding the menus is a no brainer. The easiest approach I have found so far is to use EnableVSIPLogging registry setting. That simple setting may save countless hours full of frustration (and I am speaking from experience :).

And those IDs is not something that will change within same version of VS (though for 2008 probably some testing will be required).

Move your TFS stuff around - or get ready for that!

Just wanted to share a little bit of information - there was a release of a pre-release version of TFS to TFS migration tool on CodePlex. Countless were days of waiting for this tool, and here it has arrived (albeit in pre-release version).

I have yet to test it myself, but it appears that one should be able at least move the version control artifacts and work items between different servers.

As it is pre-release, it can probably get better, so I urge you to have a look and let the team know your thoughts.

Further details can be found at Ed Hintz blog.

Orcas Beta 2 VPC expires soon!

It turned out that Orcas VPCs with Beta 2 will expire on November 1st, 2007. So if you have some data inside, get prepared (apparently it is Windows Server 2003 OS that expires).

See Jeff Beehler's blog post for more info.

Automatic shelving, anyone? No, thanks...

As I am catching up with the blog reading (still have some thousand posts to browse through in my blog reader), I came across interesting post by Grant Holliday.

In a nutshell, there is a new project at CodePlex by William Bartholomew, called QuickShelve, a little utility application that may be used to set up automatic shelving on your machine. Initially, I was pretty excited about it - I am a soldier in "small-free-app-save-big-buck" army myself. But then I thought better of it, and become doubtful that auto shelving is (will be) universally needed, and here is why:

• You need to set up the app on your local machine, since this will only work when agent is running locally. Ah, I wish it could be set up at server...


• When one shelves some changes, it is usually files at certain stage of development ("wow, it works now", "hell, it ceased to work", "i am afraid to change this" etc). Auto shelving, on the other hand, will shelve at some point in time and it wont be easy to identify what exactly is inside


• And lastly - people should check in often. Admin (or team lead) can and should enforce that policy, and may be even monitor the shelving so that no one is tempted use shelvesets as substitutes for checked in changesets. And anything that takes you away from that "daily check in is a must" is a devil's work.

So overall while auto shelving in its current form might be a good way to prevent force major circumctances (hard drive crash etc.), I will wait until it can be set up and administered at server level. That would be a nice feature (Rosario people, are you listening?).

Musings on immigration

I am back after long hiatus and this time I'd like to talk about immigration. Just joshing - about migration really (though immigration is a hot topick too :).
I do hope that many shops working with Visual Studio that still do not have TFS in house are considering evaluating/purchasing it. And even if the question of featureset is satsifactory, the issue of migration is bound to arise.

Actually, first question usually is - do we migrate the history and legacy code, retaining the structure, including the artifacts from bug tracking system or should we start with clean slate green field repository?

And at that stage I think some facts and possibilities get overlooked.

History
When talking of history of all changes performed on the certain codebase for whatever number of years it appears people tend to hugely exaggerate its importance. Try to ask average developer - how often do you look up the history revisions? And how often those revisions are truly historical (not the one before latest)? Chances are (if the guy is not responsible for maintenance of legacy code) that the usage is fairly occasional.
Now, let's suppose that history is not migrated, but that previous repository is readily available for whoever needs that data. Would that not be a feasible solution for occasional usage?

Legacy code
Do you want to have all code in the same repository? On impulse, everyone answers yes. But do you really? If there is virtually no maintenance, and putting the code in new repository means that defect fix procedure, build scripts etc. needs to be updated, it might well be time consuming. So would it be better to have all code ever developed in one new repository? Certainly so. But would it be easier to leave maintenance only code in old repository? Probably yes.

Bug tracking
With the great number of bug tracking systems available (and many of them developed in house) question of migration may be very well dependent on the person performing it. But even with such person available, the same question is relevant as with history - are all those closed defects absolutely required? And do we need those 200 fields that anybody hardly ever use?

So by now I think you catch my direction. While migration of all data from one system to another is the best solution, it is rarely available - and that due to multiple reasons. And in my personal opinion (leaving internal company politics aside) some sacrifices can be made and even may be beneficial to the whole process. Just imagine your source code repository without all legacy crap lying around, restructured logically and not forest of folders that are there due to "historical reasons".

Of course the situation I describe is simplified a lot. And it is apparent that in large organization there will be the need to have both history and legacy code transferred to the new system. But instead of trying to take and transfer everything as is, it might be better to consider an alternative. To me the alternative is this - having old system repository online and accessible (perhaps read-only) after new system is introduced, and starting new repository from the ground up. Or at least consider that for some projects.

And that no migration/limited migration scenario may be especially relevant in case where there is no bridge between source/target systems. For example, how do you migrate from MKS to Team Foundation?

Overall, I do not advocate the "throw the old embrace the new" approach. But I felt in several cases (where people passionately demanded revisions history for five years in new system without ever using it in the old one etc) that alternative should be at least examined. And sometimes doing no migration can be actually be for the better! Dont you think so?