monotone-users
[Top][All Lists]
Advanced

[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> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]