Regarding 1), it is a great way to do things (never copy files around), but just make sure you have good release tools built around the db records. The approach that we use is that when things are published they automatically have a 'dev' release record for that version for the user that published it (so they can test) and individual versions have to be promoted ultimately to 'prod' for 'everyone'. The version you see is basically the most recent version released to your context (basically you and/or what machine you are on). The key is having great tools built around this process before something blows up and there is an emergency.
This is going to be an opportunity for the community. :-)
I have some plans in this area, but I couldn't guess how to best fit into other people's workflows.
What might be nice is if there was a way to sync a git repository with Riak, and then Nirvana could just pull the relevant code from that. Seems like it would be the best solution, but looking into that- from looking at possibly integrating with a github API (do they have one?) to command line scripts is something I'm punting on to focus on the essentials.
Again, essentially what we do in concept. The dev side is a separate db (git could represent this), and once something is published past dev the record is copied to the production db (Riak in your case). The dbs have in-memory local machine cached versions, for speed, but also for reliability. You don't want your N machines depending on one db point of failure, so the local cached copies exist to mitigate that. (They receive updates via a multicast mechanism.)
