Monthly Archives: January 2006

The Podcast Network and Azure

I happen to be staying in a hotel tonight that has a wireless hotspot (amazing). Anyway I noticed on the Azure (thats their network provider) sign-in page that you could opt to listen to podcasts by The Podcast Network.

Unfortunately I hadn’t been aggregating these guys feed so I wasn’t aware what their latest news was – but its pretty cool. You can read more about it here.

I thought that $20 a month for 400MB was a little bit steep in the pricing given the number for shows that the TPN has and how big podcast files tend to be, but I guess its a start. Maybe they could reduce costs by pushing some of the data out to caches on the hotspot nodes – hrm.

Anina to stop blogging?

I picked up this link to to Anina’s blog from Scoble. Up until today I had no idea who Anina was but she seems pretty cool. She is a model but also a geek – so she is into gadgets and apparently posing with gadgets!

What I can’t understand is why her agency doesn’t want her to blog. Agencies demand that models provide portfolios to get work – and a blog is a kind of portfolio, but it just proves that whilst you may have legs that go all the way up to there, you also have a brain and an opinion. Maybe its having an opinion that is the problem.

Personally I think a gadget company (or group of companies) need to pick her up as a spokes person to not only model, but also to write about her digital lifestyle – in essence, do what she does now, except allow her to charge BIG$$$ for it.

XHTML 2.0 – I hope its not more of the same.

This interesting article on XHTML 2.0 up on the IBM developerWorks site got me thinking. For me the acid test for XHTML 2.0 will be how strictly it parses content and how reliable the renderings are across the various browsers that are out there today.

I know a guy who works on a fairly popular web-browser at the layer between the abstract model that sits on top of it and he pointed out that the W3C really hasn’t had a good set of test cases for how things should work and render.

In fact, in one scenario they had to take test cases from a later specification and dumb them down to conform to the older spec, and even then there was a lot of wriggle room.

SW50ZXJuZXQgbWVtZT8=

VGhpcyBpcyBhIGNvZGVkIG1lc3
NhZ2UuIEl0IHdhcyBkb25lIHdp
dGggYmFzZSA2NCBlbmNvZGluZy
wgbm90IGV4YWN0bHkgY3J5cHRv
LCBidXQgSSB3b25kZXIgaG93IG
1hbnkgcGVvcGxlIHdpbGwgcmVh
ZCB0aGlzIG1lc3NhZ2UuIExldH
Mgc2VlIGlmIHdlIGNhbiBtYWtl
IGl0IGFuIEludGVybmV0IG1lbW
UsIHBvc3QgdGhlIHNhbWUgbWVz
c2FnZSB0byB5b3VyIGJsb2cgYW
5kIHRyYWNrIGJhY2sgdG8gdGhp
cyBvbmUu

In Sydney for the Week

I am in Sydney for the week presenting the first delivery our latest course – PROFESSIONAL .NET. I’m looking forward to getting into some of the material although funily enough this first pass is in VB.NET and those who know me will know how amusing that is.

Anyway – I’m looking forward to getting along to the Sydney Deep .NET User Group on Thursday evening and meeting up with the usual suspects!

Branch Structures at Microsoft

I love it when the crew from Microsoft post up details about their internal processes. This time its Brian Harry who has posted up about their existing source branch structure and what they hope to do when they move to TFS internally.

One thing that they do is break up the feature development into branches to reduce contention and the risk of someone inadvertantly breaking the build of another group in DevDev (Brian outlines some good stats why this is a real issue). If you want to know more about branching you can read my recent posts on the subject (1, 2, 34) which cover off some of the techniques that the guys at Microsoft are doing to control the complexity of building what they do.

Anyway – some of the comments in Brian’s post are worth reading, including some of the critical ones. All in all however I think that once a development team reaches a certain size branching is inevitable and if you ever want to produce patches for your software without slipping in lots of bugs you are going to need it – even for a one man development band!

TFS is a repository for strongly typed design artifacts.

Brian Sherwin has posted up an insightful piece about VSTS not being able to help you unless you change your habits. In many respects Team System is a bit like SAP (except heaps cheaper) in that it offers an amazing opportunity to customise and thats what a lot of early adopters are going to do.

Once again, like SAP users, VSTS users are going to hit a stumbling block, but in this case I don’t think its going to be upgrade blockers, instead I think its going to be the fact that they have tried to graft their old processes onto a product which may have served them better in its default configuration.

One of the things that I have tried explaining to people is that VSTS provides an opportunity to reduce the dead tree usage in your organisation and store design and project management information as first class (and strongly typed) entities in the various TFS data stores.

If you insist on using the tools the way that they are supposed to be use AND continuing to produce your out-dated design artifacts then you are just wasting your time.

TFVC: Reducing Source File Contention with Branching

Note: This is the fourth post in a series of posts about branching in Team Foundation Version Control. You can get the other posts here (1, 2, 3).


Have you ever sworn at a collegue because he or she repeatedly didn’t check in source files before the nightly build? Have you ever contemplated homicide because someone has checked out the project or solution file and then gone on holiday?

I have, and even though it is usually possible to get someone to go in with administrative rights and undo the check-out it still doesn’t make it easier to put up with that kind of behaviour. The problem is that the source code repository is a shared resource and we are essentially using a cooperative algorithm to dish out access.

While I think that a pre-emptive check-in/out system would be fun to watch as developers scramble to make their changes before their time-slice ends I think that ultimately everyone would spend all their time context switching.

The Hardware Guys are Laughing at the Software Guys

There is a certain element of truth in the saying that “there is nothing new under the sun”. In this case our issue with source file contention is something that the hardware guys solved when they started machines with multiple processors.

When a CPU starts executing instructions a small amount of data is moved from main memory into a highspeed cache. There is one cache per CPU so on multi-processor machines concurrency is achieved by copying relevant data into a seperate work area and executing on that rather than having processor go back to main memory (an expensive and slow resource comparitively speaking).

Obviously there are a few subtleties in the analogy that I have skipped over here but the point is that contention can be reduced by duplicating data (branching) and in the case of Team Foundation Version Control merging those changes back in.

Funily enough, the hardware guys can’t just merge their data back in, I bet they would love to have access to our intelligent merge tools – who’s laughing now?

Patterns for Branching to Reduce Contention

Creating a branch is like creating an easy to access cache just for you (or your small team) but if you are going to take this approach you need to think about what pattern you are going to use and the impact that is going to have on your source code repository.

Unlike mainstream branching approaches used for versioning and patching branching to reduce contention is far more risky because its something that your configuration manager is going to have a harder time keeping on top of (because of the volume). In order to be successful individual developers are going to need to understand branching.

There are three different branching strategies to reduce contention that I have identified and you can use one or a combination of them depending on your scenario.

  • Branch per Task
  • Branch per Developer
  • Branch per Feature

Each strategy has a slightly different impact on Team Foundation Version Control and the kinds of things that you are going to need to keep on top of them.

Branch per Task

One of the central features in Team Foundation Server is the ability to track project progress by updating a series of work items, and when it comes to code cutting activities we are specifically talking about Tasks. If source file contention and code stability is an issue on your project you may consider using the Branch per Task  strategy.

The Branch per Task strategy involves creating a branch of the source code for each coding related task that you are assigned. Working on that coding task until the coding is complete and then integrating the changes or additions back onto the main version branch.

BranchPerTask

The diagram above shows six different branch per task invocations staggered over time and I have highlighted keypoints in the branches lifecycle. The first step is creating the branch and what I like to do here is create the branch off an appropriate piece of the source tree and check-in the branch while associating it with the task that was allocated from work item tracking. This immediately creates a connection between the work item and the branch that the work was performed on.

In the second step the code is completed and code from the main version branch is forward integrated into the task branch. This allows the developer to ensure only minimal stabilisation work will need to be done after reverse integrating. It also provides an opportunity to ensure that any new unit tests that were written continue to pass successfully (both from the task branch, and the version branch). Once forward integration is completed successfully you can go ahead and reverse integrate.

Once reverse integration has occured it is possible that stabilisation is still required because of code that slipped in after forward integrating, however there should be minimal problems. Using this approach allows developers to work freely on the entire code base and not be impacted by others that have checked out critical solution and project files.

If you are going to use this strategy there are some rules of engagement:

  1. Follow a naming convention; what you don’t in your version control repository was a whole heap of branches like “ProductX-IWasHere95” and “ProductX-YickityYack”. It’ll just make it impossible to highball the source tree and find what you want. I would suggest doing something like “ProductX-Task3967” to keep it nice and orderly.
  2. Keep those branches short; when you branch, you branch per task. Don’t try and squeeze tasks on to a branch where it doesn’t belong and make sure that the tasks are small enough in size (but not too small) that you can close the task off in a day or two.
  3. Be reasonable; you don’t need a branch to remove a carriage return from the end of a file. Understand the difference between stuff that can be done without consequence and things that are going to affect other developers on the team.
  4. Clean up after yourself; if have finished on a task let the branch lay around for a little while but make sure you clean it up. If you combine the Branch per Task strategy with the branch per major version approach and you don’t clean up then branching from a Team Project’s area will result is a whole heap of files being duplicated uncessariliy.

While I have taken the time to describe this branching strategy, its not necessarily my favorite, especially on large teams (small teams of five to ten developers should be OK).

Branch per Developer

The Branch per Developer strategy involves developers creating a branch when they start work on a version and maintaining that version throw a series for forward and reverse integrations through the course of a development cycle. Each task assigned to the developer during the cycle is work on in their branch and is then integrated once the task is complete. When the next task is started it continues on the same branch.

BranchPerDeveloper

There are a few advantages and disadvantages of using this approach. One disadvantage is that the longer the branch is active the harder it is to synchronise it with its parent so this strategy definately relies on developers being very disciplined. Having said that, if you have ever worked with CVS some developers manage to keep their sandbox clean for extraordinary periods of time and there is nothing stoping you scratching the branch and creating another one.

Two advantages that I can see is that when compared to the Branch per Task strategy there are a whole lot less branches created and once a developer knows what their branch is they are less likely to make a mistake and start working on one they shouldn’t. As a side effect it becomes possible to ease new team members into the project by allowing them to branch and throw away their code as they get familiar with the code-base.

Branch per Feature

Finally, lets have a look at a more hierarchical approach to branching inside a development cycle which I like to call Branch per Feature. Many organisations including Microsoft use this approach to seperate the work of the various teams until they are ready to integrate.

With Branch per Feature each team creates a branch for the portion of code that they are responsible for in the development cycle. The team works on that branch until their code reaches a level of stability that it can be integrated with the main product. Integration would normally happen on significant milestones like just before a BETA release.

BranchPerFeature

I actually used the diagram above in my second post on branching terminology (just in case it looks familiar). I think that Branch per Feature is probably by favorite branching strategy if I had to pick one because it kind of reflects the work breakdown structure of your average project and it is inclusive in that developers and testers can all work on the same sub-branch and even produce a common build for that feature which can help with communication about issues from smoke tests.

Summary

Here I have presented three similar but different options for branching to avoid source file contention. Which one you use or whether you need to use one at all will depend largely on the way you and your team want to work. If you are a one man band there isn’t much point branching beyond what is required to support patching but as the size of a team grows it gets harder to stop treading on peoples toes (especially when a physical barrier such as the Pacific or Indian Oceans are put in the way.

Speaking at the Patterns and Practices Summit

If you are going to the Patterns & Practices Summit in Sydney between the 21st and 23rd of February – then I’ll see you there! I’ll actually be presenting on the upcoming Language Integrated Query (LINQ) features that will be integrated into C# 3.0 and VB.NET 9.0.

I’m really looking forward to it because I feel this kind of language innovation is what keeps a platform relevant and fresh!