Re: [Gnu-arch-users] etla [Was: Testbed for OverArch]

[Clark McGrew]

This is fantastic!  I was truly hoping that somebody else had already started 
something.  

What are your plans for etla?  Would you envision it becoming a complete
command line impementation of the overarch idea?

I hope that you update libarch-perl to use tla rather than have native
support for archives.  

The etla doesn't seem to have any method to delegate actions to outside
scripts, or to allow package and project based extensions.  Is this a
design decision, or just not something that has been considered?  My
thinking is that individual projects will want to define default
behaviors to match the specific development environment.  For instance,
a project using a tla-pqm will probably want different newbie
configurations than a heavily disbursed project without a well defined
mainline.

Thanks,
Clark




Does etla include the possibility for the package, user and site to
define commands and stash configuration information?  I'd like to have a
way for projects (in my case a physics collaboration) to define default
behaviors (like archive locations, tagging-method conventions, &c).  My
idea was to have a search path for "tool scripts", but that was just for
proto-typing.

-Clark

On Thu, 2003-11-13 at 09:30, Andrew Suffield wrote:
> Months ago, I started creating a command-line frontend for larch, to
> reduce all the things I frequently ran to minimal commands (via a
> combination of heuristics, guesswork, and arbitrary decisions - all
> the things that are inappropriate for tla). The idea was "We don't
> have overarch, and we have no idea how to build it, so let's build
> something we do know how to do" - this was "lurch".
> 
> Unfortunately tla came along shortly after, and I never got around to
> converting it.
> 
> I've now resurrected it, removed the things that no longer make sense,
> and redubbed it "etla". This is available from
> address@hidden/etla--main--0
> 
> etla depends on libarch-perl; this is available from
> address@hidden/libarch-perl--main--1.0
> 
> libarch-perl has not yet been updated for tla. It has native support
> for archives accessed via local files and ftp, but uses with-ftp for
> other schemes. This needs to be replaced with native support or
> suitable calls to tla; it's on my todo list.
> 
> As an example of the sort of thing etla currently does, here's how I
> tagged libarch-perl into address@hidden :
> 
> address@hidden:~/arch/libarch-perl$ etla tag gluck-2003/
> * creating category address@hidden/libarch-perl
> * creating branch address@hidden/libarch-perl--main
> * creating version address@hidden/libarch-perl--main--1.0
> * from import revision: address@hidden/libarch-perl--main--1.0--base-0
> ...
> * patching for revision: address@hidden/libarch-perl--main--1.0--base-0
> * made tag address@hidden/libarch-perl--main--1.0--base-0 => 
> address@hidden/libarch-perl--main--1.0--patch-15 
> address@hidden:~/arch/libarch-perl$
> 
> Everything else was picked up from context. (Note that tag is a "push"
> operation when only given one argument; I'll add clone as a "pull"
> operation, mimicing "bk clone", once I've done a couple other things).
-- 
Clark McGrew                    Univ. at Stony Brook, Physics and Astronomy
<address@hidden>        631-632-8299