[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-users] Monotone scripting question
From: |
Richard Levitte |
Subject: |
Re: [Monotone-users] Monotone scripting question |
Date: |
Sat, 04 Jun 2011 08:42:53 +0200 (CEST) |
Have you looked at the cluster push hook? In the current source, it's
extra/mtn-hooks/monotone-cluster-push.lua, and it gets installed in
DATADIR/monotone/hooks (where DATADIR usually is /usr/local/share or
/usr/share).
Cheers,
Richard
In message <address@hidden> on Fri, 3 Jun 2011 13:26:57 -0700, Judson Lester
<address@hidden> said:
nyarly> Is there anything already existent that can be used to run tasks in
Monotone?
nyarly>
nyarly> I ask because I've found several times that I want to do things with
Monotone that wind up locking
nyarly> on the database and need to be spawned off and then *that* causes it's
own issues, etc etc.
nyarly>
nyarly> What I have in mind to build is a registered command that inspects the
database variables in a
nyarly> "tasks" domains, and then attempts to run those tasks, which would be
defined most likely as lua
nyarly> scripts in a tasks directory inside of hooks.d or something.
nyarly>
nyarly> As an example use case, synchronizing databases:
nyarly>
nyarly> - in note_netsync_revision_received, do something like "mtn set tasks
<unique_id> "sync_dbs
nyarly> remote_db_name branch.to.sync"
nyarly> - in note_netsync_end, spawn "mtn run_tasks"
nyarly> run_tasks fires up, loads tasks.d/*.lua, "list var tasks", matches task
names against task values,
nyarly> and runs them with arguments. In this case: sync_dbs("remote_db_name",
"branch.to.sync") which
nyarly> would look up the remote db in it's own table of dbs, and start a sync
of branch.
nyarly>
nyarly> Specific use cases I have in mind:
nyarly>
nyarly> I use a central DB on my dev box and had been using a central DB on my
mtn server - I've been
nyarly> switching to usher/indefero, and would like to be able to still just
"mtn sync" in whatever
nyarly> project. Maybe the right solution is to split out into single dbs as
each project makes its way
nyarly> to IDF, but amongst other things I like to be able to do mass
propagates, since these projects
nyarly> have a fair amount in common. So, I'd like to still sync from central
db to central db, and have
nyarly> the rc on the server sync the main db to the project db, and vice
versa.
nyarly>
nyarly> I would really like to be able to maintain an offsite backup, ideally
one that syncs with every
nyarly> push, pretty much likewise.
nyarly>
nyarly> I have a set of branches that represent static websites - in the past
I've had them set up to
nyarly> republish the files when the branch was committed. The solution I set
up wound up being very
nyarly> fragile, but this seems like it could be more durable. Likewise, it
seems like it might make a
nyarly> nice basis for a deployment solution for full fledged web apps.
nyarly>
nyarly> Judson
nyarly>