In case you hadn't guessed, I like muddle. I was formally convinced (i.e., by practice rather than theory) a few weeks ago, when I had to work on a system that already had a muddle description (in fact, the same system into which "george" was being incorporated). With muddle, it was quick and easy to add new software to the system, trivial to update all the packages (muddle update is your friend for updating all the packages in a system from their individual revision control systems - having worked with a "build" system that didn't have this facility, that is so refreshing), and easy to rebuild individual parts. If we hadn't had muddle for this system, we'd still have had to build Makefiles or some other ad-hoc scripting mechanism to make the builds reproducible (been there, done that, ick). With muddle, that step can be avoided (it saves time, in deciding what to do), and the same mechanism can be used for multiple projects (again, it saves time, in learning an individual setup).

(There's a lot to be said for a solution that is ready-made, and avoids the need for deciding what solution to use this time - it's where ASCII, UML and XML have all scored in their time. It's not that the solution need be perfect, just that it be a decent solution that you could have chosen independently, and that everyone is already predisposed to agree on. Such can save months of discussion and reimplementing the wheel.)

Using file-system based tags is useful, too. If you look in the .muddle/tags/packages directories, you'll find the status of each package made visible. Delete one of the tag files, and muddle will believe you that that step is undone (so deleting all of them is one way of making it rebuild a package from scratch). Since checkout and deployment are intrinsically separate from the normal building process, they have their own tags, outside the above. And that's the right thing, too. Perhaps the biggest lesson, though, is to keep going back to the muddle README (this is the first section in the sphinx-ified documentation). It's a good read (it's what made me think muddle2 was really on the right track), but it is also quite information dense - almost everything in there is stuff that you will want to refer back to.