[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

itla (was Re: [Gnu-arch-users] etla [Was: Testbed for OverArch])

From: Tom Lord
Subject: itla (was Re: [Gnu-arch-users] etla [Was: Testbed for OverArch])
Date: Sat, 15 Nov 2003 08:07:46 -0800 (PST)

    > From: address@hidden

    > Tom, to get it clear for us (well me), where do you feel
    > functionality like the following example should be implemented ?

    > 1) tla
    > 2) oarch
    > 3) distro level (or even company level)

    > My example problem: tla import gives me an error when I forgot
    > an init-tree, I would want a question at that point (at import
    > time) to do the init-tree without typing.

How about:

    1.5) itla

Here's what your example suggests to me:

ITLA is a customizable, extensible, self-documenting, interactive
front-end to tla.  It's useful on its own as a command line program
and, in combination with other tools, it can serve as a "driver"
program for a GUI, curses, and Emacs-based interfaces.

Typical command line usage is illustrated by:

        % itla
        (itla) -!-

Run without arguments, you get an itla prompt (the "-!-" represents
the cursor). 

Self documentation:

        (itla) help

        Help Topics
          concepts      general introduction
          user          user settings
          tree          project tree management
          inv           file inventories
          changes       changeset commands
          transactions  archive transactions

        Use the "glossary" command to look up unfamiliar words.

        (itla) help changes

                   changeset : compute a whole-tree changeset
                     mkpatch : (alias for changeset)
             apply-changeset : apply a whole-tree changeset
                     dopatch : (alias for apply-changeset)
              show-changeset : generate a report from a changeset

        (itla) help changeset
          [ tla changeset -H output passed through a more(1)-style

Interactive Prompting

        (itla) get
        project name?: tla
        branch? (main): devo
        version? (1.1): 
        destdir? (tla--devo--1.1):
        * getting tla--devo--1.1 to directory tla--devo--1.1

Complex Commands

        (itla) cd ~/wd/my-project
        (itla) import
        * Tree not initialized.

          init now (y/n)? y
          category: my-project
          branch (main): 
          version (1.0): 0.1

          tagging-method (TAGLINE,explicit,names): 


Uncommon Options

        # normal invocations ignore them:
        (itla) init-tree
          category: foo
          branch (main): 
          version (1.3):
          * initializing

        # extended invocations don't:
        (itla) init-tree?
          archive (address@hidden):  address@hidden
          category: foo

It can also be used only semi-interactively:

        % cd ~/wd/my-proj
        % itla import
          init now (y/n)? y
        * import complete

It would be a good idea to write the argument prompting parts of itla
as declarations -- and to do the same with the outputs.

For example, if you'll forgive my pseudo-lisp syntax:

        (define-command (init-tree version dir nested?)

          (help-message   (category tree)
                          (% tla init-tree -H))

          (parameters   (version        new-fq-version-name)
                        (dir            (extended existing-directory))
                        (nested?        (extended y-or-n)))

          (output       plain-text)

          (run-tla "init-tree"
                   (if dir (list "-D" dir))
                   (if nested? (list "--nested"))

with all of the prompting such as:

        category: foo
        branch (main): 
        version (1.0):

being driven from declarations like:

        (parameters     (version        new-fq-version-name)

Aside from making commands easier to maintain, a declaration-driven
system like that opens up the possibility of using itla as a
GUI/cursors/emacs driver.

Those "more graphical" front ends don't have to keep being extended
for every new interactive command.  Perhaps they can be for selected
commands but a lot of mileage could be gotten just out of generically 
translating a 

        (parameters     (version        new-fq-version-name)

declaration into a dialog box or comperable form.  No special GUI
support needed for `import' -- just generic support for "prompt for
new version name", "promopt for existing directory", "prompt for

The output declarations:

        (output         plain-text)

have a similar purpose.   A GUI might just display "plain-text" 
but for:

        (output         text-with-arch-revision-names)

scan the output for substrings matching arch revision names and
turn those into hyperlinks.

If the hooks to support GUI/curses/Emacs front ends are really well
done, that solves another problem that Stephen had been complaining
about:  changes to the tla command line syntax.   ITLA would be
a single place where such changes could be fixed for all those
data-driven graphical front-ends at once.

Does this sound doable to you and more importantly, does it sound


reply via email to

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