December 28, 2006
Just a side-note, you shouldn’t try and compile any of the examples, code snippets or examples in this blog. I’m not compiling them or testing them, just using them to illustrate a point. I find writing in a real programming language, rather than using wordy pseudo-code, to be easier. I will freely switch between C++, C#, C and possibly even Java when writing examples.
December 28, 2006
As noted in other posts, I am currently using Subversion for source code control, with TortoiseSVN as the “GUI” client. Recently I’ve been having big performance problems on my machine, particularly with Windows Explorer. Getting rid of most of the network drives that I’ve added helped quite a bit, and then I turned my attention to TortoiseSVN.
Our SVN repository is located in New York, whilst we are in London, and the network between the two sites is not great. For example, when we moved offices our new network was only 10mbit/s rather than 100mbit/s. Gigabit? Tish and pshaw! Combined with the fact that our project is 436Mb means that SVN can sometimes crawl.
I began digging into the TSVNCache.exe process. TSVNCache determines which icons should be displayed in Windows Explorer, indicating modifications, conflicts, etc. I then read this article about possible optimisations. By switching on the TSVNCacheWindow I could see that tens of thousands of directories were being cached.
The first thing was to remove branches that were no longer being used. Despite having no modifications for several months, they were being repeatedly indexed by TSVNCache.
Next was to specify the directories that I wanted icon overlays for. Into the “Include Paths” I added my C:\dev\trunk and C:\dev\Branches\ directories, with “*” after each of them so as to get recursive info. Into the “Exclude Paths” I added C:\*, thereby excluding everything else.
Performance was now significantly better, but I wasn’t satisfied. The final act was to switch on “Show overlays only in explorer”, which disables the overlays in File Open dialogs and other non-Explorer windows. This was an area where I had had particular problems.
The machine is now lightning-fast, far better than it had become and much more like the dual-core, dual-physical 3.2Ghz Xeon with 2Gb that it’s supposed to be.
My settings are shown here.
December 12, 2006
Just in case you don’t spot it, this is intended as humour.
1. Using a Blackberry
I’ve lost count of the times I’ve seen middle-managers and wannabe-important types hunched over their Blackberry. “I’m important enough to need a Blackberry” is their silent cry. “I need to be contactable at all times, I am essential to the firm”.
All a Blackberry really says is that you’re not important enough to have your own secretary. Properly important people never answer an e-mail themselves.
2. Drive a Mercedes S-Class
The only S-Class Mercedes you should ever be seen in is one booked on your behalf to take you to the airport/a client meeting/home in the evening. You should never purchase one of these things to drive yourself yourself, all it says is “I am not important/rich enough to be able to afford my own driver”.
3. Take a Chauffeured Car at the Wrong Time
There are strict times when you can be seen using such a car: 1pm to 3pm is acceptable, as this says “client meeting”. Important people never meet clients in the morning. Likewise after 7pm is acceptable, as long as you aren’t carrying luggage – this says “I am important enough to be driven home”. 5pm, however, is terrible. This says “I am travelling on business but I am not important enough to be able to book a mid-afternoon flight, and have to work all day then take the evening flight”.
4. Leave work at 5pm.
Important people leave early, say 4pm, or leave late, after 7pm. But never on time.
December 5, 2006
Windows isn’t case-sensitive when it comes to filenames. The Subversion Repository, however, is. If you add a file called “FILE.cs” and then replace it with a later copy, but called “File.cs”, you’ll get two files in the Repository. However, if you try and do an SVN Update on a different machine you’ll get an error.
The solution is to go into the Repository Browser, delete both FILE.cs and File.cs, and then re-add your updated file.
December 5, 2006
I am going to write about the number and type of machines required for a development, testing and release environment. I am going to leave out machines dedicated to source code control and any database machines.
The minimum hardware requirements for any non-trivial development project are:
- Developer workstation
- Build machine
- Non-developer Testing machine (SIT)
- UAT machine
- As-Live locked down environment
The developer uses this machine to write code and perform initial testing. Devs need to have a great deal of things open on screen at once – multiple IDEs, documentation, web sites, remote desktop links to test machines – and so need plenty of screen “real-estate”. A minimum resolution of 2560*1024 (two 1280*1024 monitors) should be installed.
- Minimum 1Gb RAM, Preferably 2Gb
- Two lcd monitors, 17″ minimum, preferably 19″
This machine is responsible for building releases of checked-in code, and optionally running automated tests and deployment tests.
- Accessible via Remote Desktop
- Fast CPU, preferably multi-core
- 500Gb of fast disk space, preferably more
Non-developer Testing Machine (SIT)
This machine is used to create an environment that is equivalent to “live” but includes any new changes in the most recent build. Some teams will call this their “SIT” environment. Since this is a group-owned/managed machine it should be accessible via Remote Desktop, and the team must have full Administrator rights on it, including the ability to change Group/Global policy objects. These rights insulate devs from changes that may be pushed out by over-zealous central IT teams who do not understand the development process.
No particular hardware requirements, although it should not be too dissimilar from “live” e.g., 1 CPU of the same class as live, similar level of memory. Hard disk space shouldn’t be such an issue since the machine should hold only the latest copy of the SIT code and any logfiles.
This machine performs a similar function to SIT, although it should be more “locked down”, with an administrative environment that mirrors “live”. Hardware should be similar to SIT. Again, this machine is group-owned so must be group-accessible at all times.
This is one of the most important machines in your rack. It is imperative that you have an environment that is configured in exactly the same way as your “live” environment. It is impossible to track down production problems if you don’t have a stable and working environment. Rolling back the UAT machine to be the previous version is inefficient, and might impact another project’s critical path. Also you are impacted by any admin differences between UAT and live. Plus, if you work in a large enough organisation, your Audit department will love you for it.
Next time we will talk about maximising physical hardware through virtualisation.