[Monotone-devel] 'in-repo' macros, example attached (mt.26 only)

[Marcel van der Boom]

There has been some talks before on 'macros' or 'custom commands'  
inside a monotone repository. I glued together an example of  
implementing such a thing with mt.26. What is attached is a zip file  
which contains 2 lua scripts:

1. job - the actual macro
2. mt-wrapper - optional, a wrapper around mt, so the macro can be  
called with mt job ...etc...

The mt-wrapper is not that interesting, just catches the cmdline and  
spawns the macro instead of mt if appropriate.

The example macro provided implements a simplistic 'job/issue'  
tracking system, using mt as its storage and using metainfo from the  
roster for it's job properties.
I created the example to play with a couple of things:
1. storing 'programs' inside a repo, so they are available to anyone  
pulling that repo (in the example, stored in <mt root>/.mt-macros and  
as such managed like anything else inside that repo.
2. using monotone as a 'backend' to possibly useful things, in the  
case of an example something which remotely resembles a bug tracker.  
where both the metainfo and the content (not much in the example) are  
revision controlled and distributed.

The macro implements a commandline roughly as follows:
$ mt job help
   SYNOPSIS
       mt job <operation> [options]

   OPERATIONS
       mt job [create]                  -- Create a new job.
         Determines the next available jobid and creates a NEW job
         New status: NEW

       mt job note <jobid>              -- Add a note to a job (new  
comment)

       mt job accept <jobid>            -- Accept responsibility for  
a job
         Register the responsibility for <jobid>.
         New status: ASSIGNED

       mt job offer <jobid>
         Release <jobid> for other people to accept.
         New status: NEW

       mt job resolve <jobid>           -- Register a resolution for  
a job
         Resolve <jobid>. If the job was not accepted yet, it will  
be accepted
         and resolved in sequence automatically. Input will be asked  
to register
         the resolution:
         One of: FIXED, INVALID, WONTFIX, LATER, REMIND, DUPLICATE
         (cfr. bugzilla resolutions)
         New status: RESOLVED

       mt job reopen <jobid>            -- Reopens a resolved job
         Reopens a previously resolved job for re-inspection.
         New status: ASSIGNED

       mt job close <jobid>             -- Close (drop) a job
         Close a resolved <jobid>. The job will be dropped from the  
working
         directory.
         New status: CLOSED

       mt job list                      -- Show a list or registered  
jobs
         Shows a listing of registered jobs in the format:
           000000 [  STATUS] Short description

       mt job info <lastn>              -- Show details of 1 job
         Shows a 'page' of info about 1 job. By default the last 5  
changes
         to the job are shown. If <lastn> is specified, that many  
changes
           are specified (if any).

       mt job get <jobid> [<attr>]      -- direct access to job  
attributes
       mt job set <jobid> <attr> <value>
         Sets/gets the attribute <attr> of <jobid>. If <attr> is not
         specified on the 'get', all attributes are shown

       mt job help                      -- show usage info (this text)

   BUGS
       - job resolve does not force fixed set of resolutions, which  
it should
       - job info is very incomplete e.g:
          'owner' (author of new->assigned state) is not shown (use  
'attr_mark' from roster?)
          'submitter' (author of n/a -> new state) is not shown (use  
'birth' from roster?)
       - this is all experimental anyway, so the code is not exactly  
clean

If you want to try it, you'll need lua 5. put the job macro somewhere  
and open the file, at the top there are some things you can  
configure, should be self explanatory. I've only tested it on osx.

It's not exaclty scaleable to thousands of jobs, but i think you'll  
find the usage of the roster and attributes interesting.
Perhaps someone finds this useful, if only for inspiration.

The 'jobs' are stored as files inside a directory in the repo (.mt- 
jobs in the example). Their names operate as the job-ids. A new job  
gets assigned a name automatically (sequence number). [Note: what  
would be interesting to see is how this operates when multiple people  
start using this, since obviously the names will collide on pull and  
push, just as a normal conflict would arise when 2 people create a  
file with the same name) The only attribute which is manage by the  
macro explicity is the "status" attribute implementing a very simple  
NEW,ASSIGNED,RESOLVED type state transition table.

I'd be interested in hearing your comments

marcel

job-macro.zip
Description: Zip archive

--
Marcel van der Boom
HS-Development BV               --   http://www.hsdev.com
So! webapplicatie framework  --   http://make-it-so.info

smime.p7s
Description: S/MIME cryptographic signature