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

[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)

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?

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

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?

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?


In lists.arch.users, Tom Lord wrote:
>
> Configs will always be useful but ..... the set of features proposed
> in recent manages can help eliminate at least one common use for
> configs.
>
> I have a collection of projects (libhackerlab, systas, pika, tla,
> package-framework, etc).  I currently use configs to assemble one big
> meta-project out of all of those smaller pieces.  I also use configs
> to assemble just subsets of the meta-project to serve as releases of
> projects (e.g., a config for "what goes into a tla release").
>
> Another approach to this will be:
>
>   1) combine all the projects into one big (real) project that 
>      includes al files
>
>   2) use selective commit heavily when working on the big tree
>
>   3) use auto-updated branches that take the combined tree and
>      prune it down (using `remove-selection') to ship sub-projects.
>
>
> Users might branch the auto-updated subproject branches when making
> bug-fixes and the like.  That's ok:  those branches are easy to merge
> into the combined-tree branch.
>
> The upshot (combining many of the proposed features) is that someone
> who wants to, say, fix an error message in tla could work as in this
> example (from scratch to finish):
>
>
>    ONE TIME STEPS:
>
>       % tla my-id "D. Moe Hacker <address@hidden>"
>
>         % mkdir ~/{library}
>
>         % tla my-revision-library ~/{library}
>
>         % tla library-config --greedy --sparse ~/{library}
>
>         % mkdir ~/{mirrors}
>
>         % mkdir ~/{archives}
>
>    ONCE PER PROJECT JOINED:
>
>         % tla register-archive address@hidden \
>              http://gnuarch.org/....
>
>         % tla make-archive --mirror-from address@hidden \
>               ~/{mirrors}/address@hidden
>
>
>         # Let's assume you know you'll want to submit patches 
>         # back to this project.   So, let's go ahead and create
>         # a local archive and a publicly readable mirror of that
>         # archive for publishing changes.
>         # 
>
>         % tla make-archive address@hidden \
>            ~/{archives}/address@hidden
>
>
>
>
>     WHEN CATCHING UP ON PROJECT PROGRESS:
>
>       % tla archive-mirror address@hidden
>
>
>     ONCE PER MINOR FIX YOU WANT TO SUBMIT:
>
>       % tla get address@hidden/tla--devo--1.3 wd
>         # 
>         # 
>         # Note: using the "one big tree" approach,
>         # there is no config to build.   Wd now contains
>         # a complete tla distribution.
>
>
>         % cd wd
>
>       % tla fork --topic "fix spelling in `foo --help' output" \
>             -A address@hidden foo-help
>
>       [hack hack hack]
>         [test test]
>         [hack]
>         [test]
>
>       % tla commit 
>
>       [repeat hacking, testing, and committing]
>
>         % tla commit --announce
>
>         % tla push-mirror address@hidden
>
>
> And that's it -- your changes would be published and bug-goo email
> automatically sent.
>
> -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
>
>
>
> _______________________________________________
> Gnu-arch-users mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gnu-arch-users
>
> GNU arch home page:
> http://savannah.gnu.org/projects/gnu-arch/
>


-- 
James Blackwell          Is this the beginnings of a panic attack?
Smile more!              

GnuPG (ID 06357400) AAE4 8C76 58DA 5902 761D  247A 8A55 DA73 0635 7400