gnu-arch-users
[Top][All Lists]
Advanced

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

Re: [Gnu-arch-users] towards standards specifications


From: Tom Lord
Subject: Re: [Gnu-arch-users] towards standards specifications
Date: Wed, 27 Aug 2003 19:21:33 -0700 (PDT)

    > From: MJ Ray <address@hidden>

    > > [...] I've tried to give a high-level
    > > overview of the design space questions and sketch in some history
    > > about previous attempts to standardize.

    > Thanks a lot for this.  It certainly helped me, [...]

Cool, somebody actually read it :-)

    > I'm not happy with the current tla implementation of inventory, but 
    > that's probably because I don't understand it enough.  Is it 
    > documented?

Not to be too much M-x doctorish but, "Why are you not happy with the
current tla implementation of inventory, but that's probably because
you don't understand it enough?"

That code _is_ a mess -- I'm slowly working on cleaning it up for the
=tagging-method generalization.  But it's kind of a tricky operation
since to break it in deployed versions creates havoc.


    > >     It _might_ be intersting to factor out `inventory', `mkpatch',
    > >     and `dopatch' into a separate distribution.

    > How easy is it to turn a random changeset into an arch commit?  I'm 
    > sure it should be easy, yet I lack the required magic words.

Well, the rule is that the changeset stored by `commit' should be an
exact changeset against the immediate ancestor revision.   So, while a
"raw-commit" command that trusts the user and stores an arbitrary
changeset is a small matter of hacking, it's not a great idea for
general use.   The magic words would be something like:

        % tla get IMMEDIATE-ANCESTOR
        % tla dopatch CHANGESET IMMEDIATE-ANCESTOR-DIR
        % tla commit -d IMMEDIATE-ANCESTOR-DIR



    > Most of your message makes it look like a refactoring of any arch 
    > implementation notes along these lines would be a good idea.

Internally, that's how its structured with the biggest exception being
auto-changelog foo.  My biggest reason for not proactively separating
out a distinct "changeset-utils" distribution is that arch is tiny
enough and stand-alone enough that I don't think such a separation
would remove any serious barriers.

-t




reply via email to

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