Om ni följt bloggen så vet ni att vi kör ett projekt med Visual Studio och TFS 2010. Nu finns en videointervju med oss publicerad på Channel9, http://channel9.msdn.com/posts/buzzfrog/Lnsfrskringar-en-av-de-frsta-att-kra-Visual-Studio-2010-p-riktigt

På TechDays i Örebro 23-24 mars kommer ni ha möjlighet att höra mer om våra erfarenheter. Har just fått veta att vi blivit antagna som talare! Ytterligare en anledning att åka dit!?

stockholm street style.

tfs.

tfs via le fashion.

One major draw of this year’s AFA was bring the Tokyo Figure Show to Singapore.  It was also an opportunity for us to catch a glimpse of  Danny Choo, who brought with him a fantastic lineup from Good Smile Company (affectionately known as GSC). For those who are still left lingering in the dark, GSC is responsible for depleting my financial resources as they keep creating and selling lovely pose-able figurines like Nendoroids (and figmas). And in some attempt at keeping track of my purchases, I have created a corner on my sidebar that lists the Nendos that will be joining my chibi army in the following months.

Now onto the figures…

The lovely lady above is the Figma incarnation of  Mirai Suenaga, site mascot for dannychoo.com.

And here we have comrade Kodomut’s itachari. Makes me wish I there was one on a more Nendo scale for my Nendos to play with.

There was the whole Nendoroid lineup, from the oldest to the newest release. Since I have quite a few Nendos in my collection already, I didn’t spent much time taking pictures of them. But I like this picture as it features Nendoroid Melissa Seraphy, who I think is super duper cute! She is one Nendoroid I don’t have and will kill to get. Looks like she is on my wishlist to get while I’m in Japan sometime next week. =)

Mikuru looking good in her Meido outfit. I kind of like Mikuru, but she was a little too wimpy for my taste.

And I have no idea who this is… But I totally adore this backview. I actually like looking at scaled figures but I will never invest monnies to get one because of the lack of display space I have. And my logic is that if I have it, I should flaunt it, and not keep it hidden in a box under my bed.

I have no idea who this is either. But I love the angle and attention to detail.

And lastly, we have the famous Black Rock Shooter figurine. She is simply gorgeous. And I hope I will get a chance to steal her from *someone*, so I can get upclose and personal with this alternate version of Hatsune Miku.

More dollies tomorrow. Stay tuned. =D

Configuring user security in Team Foundation Server can be confusing, since security has to be set at three levels: TFS, SharePoint and Reporting Services. Because it’s complex, many people resort to using the TFS Power Tools. The problem with this method is that you don’t ever really have a clear understanding of how security should be configured.

I took a bit of time to boil it down to its simplest form, and the result is this short and easy to follow document: Configuring User Security in TFS 2010.

We’ve been implementing a large TFS 2010 installation and recently started the migration from VSS. I’m writing to say that so far I’m impressed with the migration tool. It’s clearly documented in the MSDN library. A couple of XML configuration files drive the app. After setting up the config files you launch the migration process from the command line. I was surprised to find that you can migrate any subset of projects from VSS at a time. You don’t have to migrate the whole VSS database in one shot. I was also surprised to see that the tool mapped VSS users to TFS users and preserved version history by users. Remember to create the target users in TFS, then edit the user map file to point VSS users to TFS users.

It all works great so far. Now keep in mind we’ve only done a small pilot project. I’ll write back once we get onto larger ones.

We’ve been working in a large organization to install Team Foundation Server and to implement
Agile methodologies. There are a hundred developers and approximately 90 applications developed over twenty years.

We went with TFS 2010 primarily for the 32 bit support and have been pleased so far with the quality. The installation is vastly improved. Gone is the fragility of previous versions. Configuration is straightforward and the config dashboard is a welcome addition.

A couple of caveats. You need the VS 2008 forward compatibility pack to enable connection to tfs 2010. The forward compatibility pack for VS 2005 is not yet released but will be in the new year so VS 2005 clients have to wait until then to connect. VS 2008 does not enable admin functionality so you also will need to install the TFS 2020 client to do admin functions like creating projects.

All in all we are impressed so far with this upgrade to the TFS line and will comment more as we start to implement functionality.

Today we have a single AT and DT. We are planning to create a new environment with database in cluster and use NLB as switch for AT.

Only thing to check if this solution is future safe and this will work in Team Foundation Server 2010.

What is source control?

Sometimes we call it “version control”.  Sometimes we call it “SCM”, which stands for either “software configuration management” or “source code management”.  Sometimes we call it “source control”. 

By any of these names, source control is an important practice for any software development team.  The most basic element in software development is our source code.  A source control tool offers a system for managing this source code.

There are many source control tools, and they are all different.  However, regardless of which tool you use, it is likely that your source control tool provides some or all of the following basic features:

• It provides a place to store your source code.
• It provides a historical record of what you have done over time.
• It can provide a way for developers to work on separate tasks in parallel, merging their efforts later.
• It can provide a way for developers to work together without getting in each others’ way.

Repository and working folder

An SCM tool provides a place to store your source code.  We call this place a repository.  The repository exists on a server machine and is shared by everyone on your team.

Each individual developer does her work in a working folder, which is located on a desktop machine and accessed using a client.

Each of these things is basically a hierarchy of folders.  A specific file in the repository is described by its path, just like we describe a specific file on the file system of your local machine. 

For example, the path for a file might look like this:

$/trunk/src/myLibrary/hello.cs

The workflow of a developer is an infinite loop which looks something like this:

• Copy the contents of the repository into a working folder.
• Make changes to the code in the working folder.
• Update the repository to incorporate those changes.
• Repeat.

The repository is the official place where all completed work is stored.

Let’s imagine for a moment what life would be like without this distinction between working folder and repository.  In a single-person team, the situation could be described as tolerable.  However, for any plurality of developers, things can get very messy.

I’ve seen people try it (Rawad & Adel).  They store their code on a file server.  Everyone uses Windows file sharing and edits the source files in place.  When somebody wants to edit main.cpp, they shout across the hall and ask if anybody else is using that file. 

Because of this separation between working folder and repository, the most frequently used features of an SCM tool are the ones which help us move things back and forth between them.  Let’s define some terms:

• Add:  A repository starts out completely empty, so we need to “Add” things to it.  Using the “Add Files” command in Vault you can specify files or folders on your desktop machine which will be added to the repository.
• Get:  When we copy things from the repository to the working folder, we call that operation “Get”.  Note that this operation is usually used when retrieving files that we do not intend to edit.  The files in the working folder will be read-only.
• Checkout:  When we want to retrieve files for the purpose of modifying them, we call that operation “Checkout”.  Those files will be marked writable in our working folder.  The SCM server will keep a record of our intent.
• Checkin:  When we send changes back to the repository, we call that operation “Checkin”.  Our working files will be marked back to read-only and the SCM server will update the repository to contain new versions of the changed files.

The repository is more than just an archive of the current version of your code.  Actually, it is an archive of every version of the code.  The repository contains history.  It contains every version of every file that has ever been checked in to the repository. 

The ability to travel back in time can be extremely useful for a software project.  Suppose we need the ability to retrieve a copy of our source code exactly as it looked on April 28th, 2002.  An SCM tool makes this kind of thing easy to do.

An even more common case is the situation where a piece of code looks goofy and nobody can figure out why.  It’s handy to be able to look back at the history and understand when and why a certain change happened.

Over time, the complete history of a repository can become large and overwhelming, so SCM tools provide ways to cope.  For example, Vault provides a History Explorer which allows the history entries to be queried and searched and sorted.

Editing a single file

Consider the simple situation where a developer needs to make a change to one source file. 

Two methods:

• checkout-edit-checkin

1. Checkout the file
2. Edit the working file as needed
3. Checkin the file

Followers of the “checkout-edit-checkin” doctrine are effectively submitting to live according to the following rules:

• Files in the working folder are read-only unless they are checked out.
• Developers must always checkout a file before editing it.  Therefore, the entire team always knows who is editing which files.
• Checkouts are made with exclusive locks, so only one developer can checkout a file at one time.

• Edit-merge-commit: the following steps to modify a single file:

1. Edit the working file as needed
2. Merge any recent changes from the server into the working file
3. Commit the file to the repository

The edit-merge-commit rules:

• Files in the working folder are always writable.
• Nobody uses checkouts at all, so nobody knows who is editing which files.
• When a developer commits his changes, he is responsible for ensuring that his changes were made against the latest version in the repository.

There are several reasons why we may need to merge two modified versions of a file:

• When using “edit-merge-commit” (sometimes called “optimistic locking”), it is possible for two developers to edit the same file at the same time.
• Even if we use “checkout-edit-checkin”, we may allow multiple checkouts, resulting once again in the possibility of two developers editing the same file.
• When merging between branches, we may have a situation where the file has been modified in both branches.

An example

Let’s call our two developers Jane and Joe.  Both of them have retrieved version 4 of the same file and both of them are working on making changes to it.

One of these developers will checkin before the other one.  Let’s assume it is Jane who gets there first.  When Jane tries to checkin her changes, nothing unusual will happen.  The current version of the file is 4, and that was the version she had when she started making her changes.  In other words, version 4 was her baseline for these changes.  Since her baseline matches the current version, there is no merge necessary.  Her changes are checked in, and a version of the file is created in the repository.  After her checkin, the current version of the file is now 5.

The responsibility for merging is going to fall upon Joe.  When he tries to checkin his changes, the SCM tool will protest.  His baseline version is 4, but the current version in the repository is now 5.  If Joe is allowed to checkin his version of the file, the changes made by Jane in version 5 will be lost.  Therefore, Joe will not be allowed to checkin this file until he convinces the SCM tool that he has merged Jane’s version 5 changes into his working copy of the file.

In order to resolve this situation, Joe effectively needs to do a three-way comparison between the following three versions of the file:

• Version 4 (the baseline from which he and Jane both started)
• Version 5 (Jane’s version)
• Joe’s working file (containing his own changes)

Version 4 is the common ancestor for both Joe’s version and Jane’s version of the file.  By running a diff between version 4 and version 5, Joe can see exactly what changes Jane made.  He can use this information to apply those changes to his own version of the file.  Once he has done so, he can credibly claim that his version is a merge of his changes and Jane’s.

However, most of the time it will be necessary for the merge to actually happen.  In these cases, Joe has the following options:

• Attempt to automerge
• Use a visual merge tool
• Redo one set of changes by hand

Attempt to automerge

A surprising number of cases can be easily handled automatically.  Most source control tools include the ability to attempt an automatic merge.  The algorithm uses all three of the involved versions of the file and attempts to safely produce a merged version.

The reason that automerge is so safe in practice is that the algorithm is extremely conservative.  Automerge will refuse to produce a merged version if Joe’s changes and Jane’s changes appear to be in conflict.  In the most obvious case, if Joe and Jane both modified the same line, automerge will detect this “conflict” and refuse to proceed.  In other cases, automerge may fail with conflicts if two changes are too close to each other.

Use a visual merge tool

In cases where automerge cannot automatically resolve conflicts, we can use a visual merge tool to make the job easier.  These tools provide a visual display which shows all three files and highlights exactly what has changed.  This makes it much easier for the developer to perform the merge, since she can zero in on the conflicts very quickly.

Redo one set of changes by hand

Some situations are so complicated that a visual merge tool just isn’t very helpful.  In the worst case scenario, Joe might have to manually redo one set of changes.

So I’ve had a play with gated checkins in 2010 and I have to say I’m reasonably impressed. Not massively impressed, but reasonably.

I can finally see how the implementation may actually help. It pushes a lot of the problems back to the developer in a way that’s offline, so that the problems aren’t sorted out by mashing trunk, you just have to mash your workspace instead. And mash it you may.

First and foremost, the thing that wasn’t clear to me, is that the checkin process is properly separated into 2 stages. 2 things normally happen on checkin:

1. Your changes are collated and sent to the server.
2. Your workspace is updated to mark your files as no-longer changed by updating the ‘base’ revisions of the files in your workspace.

This second part is basically like a get operation on your changes and is what is delayed when gated checkins are used. With gated checkins, the process is much more complex:

1. Your changes are collated and shelved.
2. A build job is queued against the shelveset.
3. The shelveset is merged onto trunk.
4. The merged result is built.
5. The shelveset is merged with trunk again (it could have moved on whilst the build was going on) and committed.
6. An agent on the client machine notices the commit and runs around your working copy marking files as being at the new revision. No changes appear to be made to your code during this step.

It was step 6 that was the missing part of the story for me. The obvious way to do it is just to hold open the commit, but 2010 makes it a separate job with its own monitoring process. After commit, whilst the build is going on, by default your workspace still shows all your files as having been changed. You can continue to work and it looks like your coding on top of the changes you just sent up. When the commit completes, you get the option to reconcile and all the relevant changes disappear and diffs suddenly show the changes since the commit, instead of the changes including the commit.

Obviously, since there’s more steps, there’s more opportunity for failure. Failure at any point leaves the shelveset in tact and you’re notified via the daemon that watches the build on your workstation. Failures include anything other than a truly trivial merge in steps 3 or 5, and of course, any failures you define in the build.

Things can get a little messy on failure. Your first option is to simply ignore it. If you’ve carried on working, your workspace still shows the pending changes from the commit plus the changes you’ve made since so you can just push up a larger commit next time. Your other option is to try to fix the actual problem, to do this it feels like you’d typically shelve your current changes and revert them, then unshelve the failed commit. Fix it as you normally would and commit again. At which point you can switch back to the shelveset you originally made and carry on where you left of. Do this, however, and reconciliation will fail and you’ll be left to sort out the mess manually.

The second option gets quite messy, since the code you committed has diverged from the code you’re working on. It can’t be resolved by the reconciliation process, and you need to sort it out yourself with a get latest. This leaves you to resolve the merges in the normal way. Now, your merging fixed code with unfixed code, so it’s up to you to remember where the fixes where and ensure that they get merged in properly. Good luck.

By default the commits are queued sequentially, but I can see it would work just as well by building everything in parallel as well, since any merge conflict at any point will cause a commit failure (and the related heart-strain). I still maintain that this will be a major issue if anything makes the queue length build, but I’m generally more optimistic that it could work. I did get into a bit of a mess trying to fix shelveset in some scenarios, especially when the reconciliation failed.

Essentially, you really need to excerice the 3rd option and stop work and wait for the build to complete before you carry on working. In reality, that’s what tends to happen with CI anyway. Most CI’s work in what TFS calls Rolling Builds – which means that there’s no queue, so you have to wait a maximum of 2x the build time to see if your commit is good, unlike gated checkin. Also remember that even though you’ve resolved conflicts before commit, if something was queued up before you, that may still conflict and your otherwise perfectly good change will get rejected anyway.

So keep your builds quick and your queues short and gated checkin works quite nicely.

–

Update:

The process for initiating a gated check in containing a locking check out has been improved for RTM!

The default is now to display the options expander, with the ‘Preserve my Pending Changes’ check box unchecked and greyed. A tooltip is supplied on hover for the check box which states “The pending changes being checked in contain one or more locks. The build service cannot unshelve or check in your changes if your local changes are preserved.”.

The following therefore only applies to Beta 2 of TFS 2010.

—-

Working with gated check-ins can save you time by verifying your changes before committing them to the repository. This is great in terms of keeping your code base healthy and enabling team development. Recently I’ve seen teams start to use this feature and struggle with a consistently breaking gated check-in build. What I noticed was common across these builds was the cause – a locked file.

Gated Check In Build - Locked File Failure

This occurs when your check-in involves a binary file, which TFS automatically forces into a locking check out. This means that when your gated build goes to ‘get’ the file into it’s build workspace it clashes with the lock you have locally.

The fix here is to un-check the “Preserve my pending changes locally” option on the gated build initiation screen. This will undo your local changes and allow the build to get the binary into it’s workspace. The thing to remember here is if the build breaks, you’ll need to know the name of the shelve set to get it back down locally and fix the issue. Luckily it’s right there on the build initiation screen for you, and you can either screen shot or copy it out for later.

Your other option is to use the dialog that pops up with the build results to un shelve the changes…

Results Dialog

Last night I hosted a session about the Visual Studio 2010. Speaker was Gerard van der Pol from Microsoft NL. This time it wasn’t about what’s new with the (obviously) improved IDE and .NET Framework 4, but it was all about the features regarding Team Foundation Server (TFS). Of course, there are lot of new features to talk about and so little time. I’ll describe some features Gerard was demonstrating.

First, let me say that the title of this post is a bit wrong. The brand Team System will disappear, so it is only Visual Studio 2010.

Also, the editions will change a bit:

Regarding to Team System (or should I say ALM) there are 2 new products: Visual Studio Test Elements and Visual Studio Team Lab Management.

With Lab Management it is possible to create and configure your environments to help testers more easily test a variety of configurations in a virtual lab environment, and help developers more easily repro bugs by delivering snapshots of those virtualized environments after bugs are discovered. For more information, watch this Channel9 video.

With Test Record & Playback you can actually record and playback your test plan and steps. The video’s will be accessible for the developer from the work item. For more information, watch this Channel9 video.

Do you recognize this:

• You’ve received reports of a crash from a tester, but on your local box you can’t get the bug to reproduce.
• You’ve received a crash dump from the tester along with the bug. But the call stack that actually caused the crash was just a cascading effect and you can’t trace the bug back to the root issue.
• The bug that you are currently working at resolving has an extremely long set of reproduction steps and you just accidentally stepped over the function that is returning bad data.

IntelliTrace, formerly known as Historical Debugging, can help you out now! IntelliTrace is similar to that of a black box in a plane. It’s keeping track of important points in your programs execution and allow you to play back what happened at those points at a later time. For more information, click here.

With the new Profiler you get a really great look at how your code is performing. It comes with couple of new features for developers:

• CPU Sampling
  Measures CPU-bound applications with low overhead.
• Instrumentation
  Measures function call counts and timing.
• .NET Memory Allocation (Sampling)
  Track managed memory allocation.
• Concurrency
  Detect threads memory for other threads.
  • Collect resource contention data
  • Collect thread execution data

Profiler includes a new page called the Function Details page, which will depict the caller/callee information in a graphical way along with the performance metric. You can also view your code which includes the line-level performance measurements.

To end this post, I want to tell you about Gated Check-in. We all have colleagues who are checking in their code and you end up with a non building solution. With Gated Check-in you can prevent users to check-in their code unless it all builds! And it is also possible to run your tests too, before allowing to check-in.

For more information, click here.

I was truly amazed with all the new features of Visual Studio 2010 regarding ALM and had a great night. Go explore for yourself!

The new Team Foundation Server (currently in beta 2) has the option to connect TFS project to an existing SharePoint site. This also allows you to specify on which SharePoint server to create new project sites. For us this is important, because a lot of our projects start way before the TFS project gets created. Then we end up moving all files to the TFS project site, or we have two project sites for the same project. When we go live with TFS2010, we no longer have to transfer files. And we can host the TFS project sites on our company SharePoint implementation, which means 1 WSS server less to maintain. With one of my colleagues we managed to get this working in our test environment. This post shows you how we have set it up.

via Connecting TFS 2010 projects to SharePoint sites – Weblog Ton Stegeman [MVP].

Jakob Ehn over at GeeksWithBlogs has written up a great list at http://geekswithblogs.net/jakob/archive/2009/05/23/tfs-team-build-2010-whatrsquos-new.aspx.   I’m particularly excited about the possibility of using templates for build definitions (I remember many an hour spent duplicating an existing build definition “the long way” with TFS 2008.)  It’s very cool that Microsoft decided to add gated check-ins as a core feature; we were able to get it working in the previous version, but it required a lot of creative engineering to get it working correctly.

I’ve just finished getting my local VM TFS sandbox up and running, and I have to say I’m very impressed with the new installation and configuration process.  There still seem to be the usual arcane permissions magic that needs to be done in order to get everything playing together nicely, but nothing that you can’t figure out with a bit of trial and error and/or making service accounts domain administrators.

Recently I’ve been helping a fellow Readifarian get started on a brand new project using TFS and VS 2010. As always, we’ve seen a few teething issues along the way. Yesterday he was attempting to get his database project to build on his shiny new Windows 2008 R2 x64 build server and was having some issues with the SqlBuildTask failing. The stack trace was pointing to an unresolvable reference to the SQL CE assemblies.

Error Stack Trace

After doing some digging around the MSDN forums and broader web I found some older posts on x64 issues with SQL CE. While this wasn’t my issue, it led me down the right path. What’s happening here is that there is a minor issue with locating the x64 version of the mentioned assembly cause by a bug in the setup of Team Build. The workaround here is to set the MSBuild framework to x86, which in turn makes the database project locate and use the x86 version of the SQL CE assembly.

Important Note: This work around will only be needed in the Beta 2 timeframe for 2010, as the underlying cause of this issue has been fixed for RTM.

Craig Tadlock (over at the Tadlock Enterprises Blog) made a couple good posts recently about Team Foundation Server and Team Build 2010:

Work Item Classifications
Work Item Relationships

He also came across this great blog that is focused on doing automated testing:

http://blogs.msdn.com/vstsqualitytools

as well as this link discussing custom workflow items:

http://blogs.msdn.com/jimlamb/archive/2009/11/18/how-to-create-a-custom-workflow-activity-for-tfs-build-2010.aspx

I’m setting up a local TFS test environment for myself now and hopefully soon should have some interesting information on setting up Lean build systems using this great platform.  I was lucky enough to work at a company that used the previous incarnation of Team Foundation Server and I have to admit I’m pretty excited to see what goodies Microsoft is giving us on this go-around.

Back when I was working with subversion, I was at one point writing a hook script to check that a given commit was good. You know the kind of stuff: Have you added a comment, are you trying to change a tag, are you trying to hack the server, have you brushed your teeth, and so on.

It’s a fairly obvious thought when you’re in that environment to think … is this going to build? After all, here’s the perfect opportunity find out, and if it doesn’t we can just reject the commit and it’ll be as if it never happened – no-one else gets affected, nothing bad polluting the trunk, better chance of having a 1:1 workitem/changeset ratio, it’s all good.

It turns out that this idea is called gated checkin, and it’s available as a checkbox in TFS 2010. But despite my glowing report, I’m yet to be convinced of gated checkin as something that isn’t just a nuisance, compared with CI. I rejected it on the subversion side of things because our builds always took forever, and whilst a build was being checked, no-one else could commit. Not only that, but because I used a single repository for everything, it meant that no-one else could commit even if they were on a different project entirely. Thinking about this differently, this could be the best argument I’ve found for using individual repositories per project with subversion.

It’s much the same argument with TFS – the checkin is held open until the build and any other checks you use have completed, preventing anyone else from doing anything commit related. I mean they can’t even resolve any commit conflicts reliably, because they may or may not need to incorporate the changes that are being tested. This means your builds must be quick. This means they must be small. This means the projects must be small. Allegedly gated checkin becomes a requirement when you have >~60 people on a branch, as just by the laws of statistics, the branch is more often broken than healthy. Having 60 people on a single branch doesn’t sound small to me. If you’ve got 60 developers checking in every 2 hours, that’s a commit every 2 minutes. That’s your timeslot before your start impinging on developer productivity.

I’m not sure what the solution to this is. Apparently gated checkin is the solution to world hunger. Personally I prefer the idea of having less people on a single branch and merging more. Split the project into components and release them separately. Anything really. But I guess I’m going to have to try these before I can make a decision for sure. After all, they’re easy to setup and take out. If the builds are fast enough, they’ll certainly make the branch history cleaner, and surely that’s a good thing.

One of my main bugbears with source control is knowing where my changes are. I don’t mean just having a good idea, I mean actual empirical evidence that I can look at and easily convince someone else that changes have been moved from the project branch to trunk, and from trunk to release.

Now this is always possible by looking at the code, but that just doesn’t scale – it can easily take days to work out what’s in a particular release, and by the time that’s finished the world will have changed anyway. We need something high level, something that says this branch contains these changes from these locations. TFS goes some way to addressing this with a nifty visualisation in the new 2010 suite. Given a changeset, you can follow the merge history of that changeset across the branches of your project.

This is excellent if you’re looking at a particular change and want to know where it is. You can easily see that it has been flowed in the right direction, and can see how much of a mess you’re getting yourself into. This visualisation also handles partial merges by showing them in yellow for the time that they’re partial (hopefull they’ll get fully merged after a while, letting them go green).

If you want to know where a particular change has made it to, this view is perfect. In my experience, however, we rarely want to know where a single changeset has gone, we’re much more interested in where a workitem has gone. Although we’d all love to think that there’s a 1:1 correspondence between workitems and changesets, it just aint gonna be so, regardless of how you work. MS are working on this, of course, although I’m not holding my breath for the initial 2010 release.

The other problem is again one of scale. Whilst this view is very useful, one thing that we need for a release is a report on all the items which have been merged into this release from trunk (and conversely, what’s missing). Ideally this should be at a workitem level as well, but a changeset level report is a good start. Subversion has this with its mergeinfo command. Tortoisesvn shows each revision and greys out the ones that have already been merged. Git has an incredibly detailed view of all the changes that were made on parallel branches. I’m not sure if that’s any use in telling you what’s missing, but it’s wonderful for knowing what’s in. These all work on the changeset level, however.
I haven’t found anything equivalent in TFS yet. The information is available in TFS, so it’s likely trivial to build it manually.

All of this tracking is of no use, however, if your changesets mean nothing more than it was Friday night and were preparing for the weekend. Also, a commit comment of “some changes” isn’t going to be useful for working out which changesets you’re looking for. If you’ve never felt the need to be disciplined in making a changeset be a single unit of functionality before, perhaps this can inspire you as to why it might be a good idea.

Some of you may know that I’m a strong advocate for using some of the more flexible branching strategies available to us developers, given the advances in source control over the last 20 years. TFS 2010 is adding in some extra branching support that should make this more compelling.

In short, TFS 2010 knows about branches explicitly. That is, you tell it “this folder is a branch” and it can track things around in a nice visual form. You start out with marking your trunk/mainline branch, then branching from that. Visual studio tracks what gets branched where and can show you the relationships between branches in a nice, simple diagram.

This shows the logical structure of the branches. Here we can see that 3 branches came from Dev and an additional branch was made from “Brian”. The logical structure shows where branches came from and, conversely where changes need to be merged back to. The actual meaning is branch dependent of course – release branches would have changes merged into them from trunk, development branches would have their changes merged into trunk.

The physical structure is where the branches are located in Team Explorer and will be completely different to the logical structure.  The recommendation is that folders are made to hold branches of a common type, so that the physical structure tells you the reason for the branches existence, such as private branches, feature work, stable release branches etc. Each branch can have a description, which is useful for finding out detail about an individual branch, but grouping them in folders makes sense.

This screenshot shows the branch structure in physical form. Notice that branches look different to folders. Also notice that here the Dev and QA branches are siblings in the physical structure, where as in the logical diagram QA is a child of Dev.

Branches can be made quite easily by dragging and dropping from the logical diagram or right clicking a branch on the physical diagram and choosing “Create new branch”. The whole branch process has been streamlined as well. Apparently old TFS checked out all the files onto your machine and waited for you to check them in as a pending change. HUGE waste of time, effort and bandwidth. Now it just makes the branch on the server and you can check it out when you see fit.

Sikke da et vejr! Har lige været ude på en 2×5 min’s cykeltur, og jeg er nu GENNEMBLØDT, trods vandtæt jakke!

Nu jeg vaske tøj, og i aften får jeg gæster…

Ciao, Stina

Source: thefashionspot

It’s been a while since I added to my series on VSTS 2010 in action, and a lot has happened since I posted Part 2.

For starters, VS2010 Beta 2 has been released. This refresh contains much more content around the Process Guidance for the MSF 5 process templates, and so I’ve taken a slight pause in transmission on this series in order to absorb this and to reboot, if you like, my series on VSTS2010. When I post again, I’ll be using, and referring to, the features in Beta 2.

This does mean that I’ll go back over what I’ve already covered too, and update it for the new bits. Conceptually it’s still the same, but it’s a chance for me to tidy up what I’ve said already so that it actually makes some sense!

As well as this, the company I work for, Optimation, has re-launched it’s web presence, and the new website includes a company blog, which I will be contributing to. In fact, these posts will be submitted to that blog also, and cross posted here. I can’t guarantee the order in which this will happen though, so I recommend that if you’re really hanging out for a new fix of VSTS2010 goodness from me, you check both places.

Also, as I’m not the only person who’ll be contributing to the Optimation blog, a whole range of content will appear there, from some really smart cookies, so do go and check it out!

So, to summarise, I’m re-starting the series, and it’ll be cross-posted (hopefully – depends on approval from the “editorial team” at work) on the blog of the company I work for, Optimation.

У меня есть solution, в котором находятся разнородные проекты – C#/C++, EXE/DLL/Library. В общем, практически весь букет. Да, и самое главное – там ещё есть Сloud Service, т.е. Azure. И всё это собирается при помощи Team Build 2008.

В какой-то момент мне очень захотелось получать в результате сборки готовый пакет для развёртывания в Azure. Для этого надо выполнять target “Publish” для .ccproj проектов. Добавил в tfsbuild.proj следующую строчку:

<SolutionToPublish Include=“$(SolutionRoot)\MySolution.sln“/>

Всё было бы хорошо, но:

1. По-умолчанию MSBuild считает необходимым публиковать все EXE проекты. Сделано это было для .Net приложений. В этом случае он генерирует ClickOnce manifest.
2. Начиная с версии 10, в Visual Studio все C++ проекты перешли на MSBuild (ура, VCBUILD  прощай!), но в данном случае это помешало.

В силу вышеперечисленных обстоятельств, некто, не будем показывать на него пальцами, пытается построить ClickOnce manifest для C++ EXE. Естественно, с достаточно предсказуемым результатом – манифеста то нет!

Внимательное исследование файла ‘ Microsoft.Common.targets’ показало, что проблему можно вылечить указав

<PublishableProject>false</PublishableProject>

в файле .vcxproj. Я вставил определение этого свойства сразу после определения _ProjectFileVersion:

<PropertyGroup>
  <_ProjectFileVersion>10.0.20728.1</_ProjectFileVersion>
  <PublishableProject>false</PublishableProject>
  <OutDir Condition=“‘$(Configuration)|$(Platform)’==’Debug|Win32′“>..\..\bin\$(Configuration)\</OutDir>
…

Всё вышесказнное справедливо для Visual Studio 2010 Beta1/Beta2.

В конце октября в Москве прошла международная конференция SECR 2009, на которой я читал доклад Team Foundation Server – роскошь или средство передвижения? Практический опыт разработки «коробочного» продукта. Презентацию можно скачать здесь.

TFS