Signage for Code Camp Oz 2006!
April 11, 2006
Greg and I got an e-mail today from Anthony Chan letting us know that he had put together some signs for people coming to Code Camp Oz 2006! There has also been a UHF radio channel setup at CSU (Channel 1 – Duplex), all you need to do is ask for Code Camp Oz and someone will respond and help you find your way.
I love community! Thanks Anthony – thanks CSU!
Team Foundation Server Upgrade Matrix
April 11, 2006
This post by Rob neatly summarises the upgrade path available to users of TFS based on where they are now, and where they want to be. Unfortunately it confirms the rather crappy position I am in after going out and installing workgroup and having to wait for Microsoft to release their price lists for TFS some time in may.
Teamprise V1.0 Ships!
April 11, 2006
Just helping spread the news about Teamprise. These guys have released a plug-in for Eclipse which allows developers in that environment work against Team Foundation Server. Congratulations guys – a great effort and very useful product!
Martin Woodward has made an interesting post about folder structure in Team Foundation Version control. I recognise the pattern that Martin advocates as being one that I have used with Subversion. What Martin is trying to do with his structure is support a very rich approach to branching and releasing of code, but I wonder if you can’t achieve the same result without any effort.
Major product releases should be tied to sperate team project. For example, version one of Onyx would be in a seperate team project to version two, and they would therefore have seperate areas allocated in version control (in fact the branch capability you get during team project creation supports this approach).
What I then like to see is within the version control area is the first piece of code that is checked in using a dirt simple name – like Onyx. This represents the main branch within the code base, then from that I would allow arbitrary branches, for example, someone might want to run on their own branch for a while because some of the changes they are making could destabilise everyone else – so they might create a branch called “Onyx-CrazyBob”.
Obviously naming is important, so for release drives I would do something like “Onyx-Beta1” and “Onyx-MarchCtp” and eventually stabilising and releasing off the trunk. At which point the next product cycle would kick in (or it may have already) and you take a branch as part of a new team project creation.
Anyway – its interesting to see what the different approaches are – I wonder if there is one correct approach?
