Re: [Gnu-arch-users] FEATURE PLANS: pruning instead of configs

[Tom Lord]

    > From: address@hidden (James Blackwell)

    > Lets suppose tla, hackerlab, pika, and whatever else is rolled into one
    > package and instead of using configs, the --selection additions are
    > added. 

    > Using tla as an example, could you answer the following questions? 

    > 1. Does this mean that in order to work on arch, I'll now effectively be
    > stuck downloading pika as well? (The way I read the get --selection
    > stuff, no, but somebody else said yes)

You will not.   The reason you will not is that I'll make an
(automatically created) tla--devo--1.3 branch which tracks the "all in
one" mainline but deletes everything from that mainline which is not
part of a tla distribution.

What it means is that you will be able to get the same tree you
currently get using "get + buildcfg" with just a single "get".


    > 2. What if there was another project that wanted to use hackerlab. Are
    > they now stuck dealing with all of the arch and scheme stuff, which they
    > don't necessarily care about?

No.  Another auto-created branch will have just hackerlab.

To put hackerlab in _their_ tree they have two choices.  They could
use a config, just as they do now, or they could smoosh together a
hackerlab tree with their tree, creating their own "all in one".

In the latter case, if they want to push hackerlab changes back
upstream, they can make their own (automagic) branch which is their
tree with everything but hackerlab removed.   Merging from that back
into my "everything in one" tree should work fine.


    > 3. What happens to the size of cached revisions if a bunch of projects
    > are lumped together into one super-project?

They get bigger but slightly fewer in number.  The default cachereving
behavior of the `tag' command may require some tweaking.


    > 4. Branching for a small fix is already moderately painful, if one
    > cacherevs a branch from a foreign archive. Wouldn't this superproject 
    > concept mean that cachereving base-0s are no longer practical?

I think you are looking at this from the super-mirror maintainer's
perspective.

My answer, in that case, is that the super-mirror shouldn't be taking
cacherevs from third parties at all.   It should have a custom
cacherev policy.



    > 5. The selection stuff looks like scheme (pika, lisp, whatever -- to me,
    > they all look the same ) to me. Does this imply that in order to stick
    > with arch in the long term, I'm going to have to pick up scheme?

No.

It implies that you'll have to learn the Pika/Scheme syntax for
writing data constants consisting of symbols, strings, numbers, and
lists of those things.  It's an easy syntax and you can already guess
most of it correctly.


-t

----

Like my work on GNU arch, Pika Scheme, and other technical contributions 
to the public sphere?   Show your support!

https://www.paypal.com/xclick/business=lord%40emf.net&item_name=support+for+arch+and+other+free+software+efforts+by+tom+lord&no_note=1&tax=0&currency_code=USD

and

address@hidden for www.moneybookers.com payments.


-----

        The cause of death is birth.
                        -- George Harrison