For the first time svn has built in support for repeated merges without spurious conflicts or manually managing the list of previously merged revisions.

This is _fantastic_ news. The basis of the merge tracking feature in 1.5 was svnmerge.py which means that many svn users will already have a reasonable idea how it works. (List of merged revisions are stored in svn properties on a branch). 

I’ve been watching the development of svn 1.5 for the last 18 months (give or take) crying everyday that I have to manually manage merging work as I oggle the feature list. 

TortoiseSVN has a significantly enhanced release as well. I’m particularly excited about this because it supports caching the change log which will make a huge difference for me given that my svn server it 2 continents and 300ms away.

It also looks like there may be some progress on cleaning up the working copy implementation.¹. Which would involve fixing the whole every folder with .svn folders problem (a la git or svk). 

1. http://subversion.tigris.org/roadmap.html

Here’s a couple of great quotes (It’s worth noting that he’s talking about large projects):

Not everything is going to be well designed.

You may have a part [of a system] which is not complex – or is just straight forward data collection. You’ve got a lot of screens , a lot of fields. You’ve got to put it into the data base and do a simple report on it.

Don’t spent a lot of effort modelling these things. Just find some simple technology that’s good at that stuff.

The idea that the entire system is going to be based on an object oriented model is I think is a highly questionable assumption.

It’s a really interesting perspective – and a great antidote to some of the discussion at the moment which almost treats DDD as a silver bullet.

Anyone who’s feeling guilty because they don’t have their solutions structured into Core, Model, Services, Presentation, UI layers – or even worse is using a SqlDataSource control in their app – should watch it. It’s an excellent dose of pragmatism.

One massive advantage of my current job is that I work two desk’s down from a team of copy writers. Over the last couple of years I’ve come to realise what an asset this is. There’s a famous quote along the lines that there are only two unsolved problems in computer science. Cache invalidation and naming things.

Often when I’m working on a feature I get stuck with what to call a class, interface, feature, UI element etc. Previously when this happened I’d talk it through with another dev/project manager/product owner. Sometimes this helps and they’re able to provide just the word your looking for. Other times it doesn’t.

About a year ago – I realised that the copy writers whole job is finding words to fit concepts that other people describe.

Now I just walk 10 steps and describe the type of word (phrase/whatever) I’m looking for and they start giving me alternatives. I pick one I’m happy with and I’m on my way.

e.g. Yesterday – I needed to describe an attribute of a Question in this form builder thing (the wufoo like beast mentioned above). The properties of this type of question are that there is a correct answer/s. If you don’t answer the question correctly – then “something” happens. I was flailing around trying to find a succinct way of describing this in my model (IsFailableQuestion, PassFail etc.. ) after an unsuccessful conversation with another developer and the product manager – I asked one of the copywriters and they said: ummm… killer question?Perfect!

(If this seems like a strange naming choice then it’s because of the specifics of the domain that this makes sense – no – no one ever dies).

Whats interesting to me about all this is the description of Workdays application architecture:

Workday runs on an in-memory database [...] it uses a relational database (mySQL) only for persistence [...]. This persistent database has exactly three tables, one for data, one for metadata, and one for instructions. Yes, that’s right. All data–the employees, the positions, the organizational structure, and even the layout of a screen–is stored in the same table. – From: Workday: Forget ERP, start over

I wonder how this compares to Xero’s architecture. Knowing Craig Walker – I’d be surprised to here there wasn’t at least some meta-modelling in Xero.
It seems like the traditional relational/OLTP approach of having strictly defined, highly normalised schemas which you hydrate/dehydrate into runtime objects is losing currency. Pat Helland – Jim Gray’s protege – is back at Microsoft and preaching heresy about traditional views around OLTP. Here’s some of his recent stuff that’s got me thinking:

• Life Beyond Distributed Transactions: an Apostate’s Opinion
• Accountants Don’t Use Erasers
• Normalization Is for Sissies

It seems like the more I think about this – the more this seems like the future. Here’s some other stuff I’ve read recently along similar lines:

• One Size Fits All: An Idea whose Time has Come and Gone
• Joe Gregorio’s Mega data post
• Scaling from 0 to 40 hits per second in 3 days

More Info at:

• The end of ERP?
• Workday unveils Financials and Work Tags

• Who’s using what features?
• Where are the users coming from?
• How long does it take subset X of users to perform action Y?

Some of these are closely related to traditional web analytics, but many of them cannot be answered without application level event logging. Ron’s papers describe how Blue Martini did this within their e-commerce framework and what a huge advantage this gave them when doing BI. One of the insights of the paper above is that having a meta-model for your application is really important for later analysis. You need to know:

• When you changed the default answer for question X on the registration form?
• When did you add question Y to the checkout process?

If you keep a metamodel and use that for updating your live DB¹) then you can capture these changes as you change the data store. Ron’s team went further and built a data warehouse²) and ETL process automatically from the meta model – that was automatically updated as the live DB evolved.

I’ve been using some of these ideas independently for a long time (e.g. Event logging is a good idea) – but it’s the combination of of a meta model – including change history – and event logging that really provides the power here.

Short version. How I’m thinking about building business apps is changing. As I think about the business requirements, data model etc.. I’m now considering how we are going to capture/store/analyse the meta model and the business event stream. This seems like a significant evolution in my thinking.

1. (Blue Martini used a highly optimised/denormalised datastore for it’s e-commerce front end because of the performance requirements.
2. (Including slowly changing – aka type 2 – and hierarchical dimensions

Git is a distributed SCM system – Linus wrote it in two weeks. It seems like it’s getting some traction among some of the Rails crowd. Mozilla seriously considered adopting it for Mozilla 2 work but the lack of a finished win32 client was a show stopper (although progress seems to have been made there).

There’s nothing like Tortoise for it (yet) – but it’s still pretty new – it’s been used by the kernel developers for the last two years – but it seems like it’s only in the last few months that it’s got easy enough for newbies to pickup.

Distributed SCM’s really take some brain twisting to get your head around – and Git in particular breaks with most conventions that people used to traditional centralised, file based systems are used to. Linus says that he thinks the only reason he’s been able to build git was because he didn’t have brain rot caused by exposure to traditional scm tools.