Re: [Gnu-arch-users] Re: Making microbranches popular

[Scott Bronson]

On Tue, 2004-01-27 at 18:52, Colin Walters wrote:
> On Tue, 2004-01-27 at 18:39, Scott Bronson wrote:
> Weird errors?  Can you explain more?
> > requires scattering my-default-archive and -A everywhere
> Everywhere?  Certainly you don't have to specify -A for very common
> operations like 'changes' and 'commit'.

True.  No, it's the boundary cases that got me.  I should have taken
notes.  I remember getting frustrated while debugging a few scripts
and realizing I could cut the problems out by just cramming everything
into a single archive.  When clean builds take 2+ hours, iteration can
be tiring...   So, there's a good chance that I could have gotten this
working if I'd spent more time on it.


> > ).  And,
> > even if the technical issues were fixed, it's pointless.  Spreading
> > your source among multiple archives doesn't actually _solve_ anything.
> Well, it does give you more of a namespace.

That's exactly what I was referring to.  It gives you exactly 1 more
layer of hierarchy -- instead of a flat namespace, with some effort, you
can now go 2-deep.  Net gain?  Zero.  That's still too flat to keep a
mid-sized project like this understandable.


> It seems to me that overall, what you have is mainly forks of other
> projects.  If those other projects used arch, certainly your life would
> be easier - you could just create your own branches from their
> archives.  But since those other projects don't use arch (yet) - why not
> pretend that you are the upstream vendor?  So you would have a gcc
> archive, for example:  address@hidden  That archive would have all
> the vendor stuff for gcc, perhaps including binutils.

If I understand correctly, you're advocating splitting each vendor
release into its own archive?  Even loosely grouping them with multiple
vendors per archive, that's 30+ archives.  That sounds awful cumbersome
to me, and it doesn't appear to solve anything...?


> ...Arch won't allow
> > gcc--vendor--3.3.1 and gcc--vendor--3.3.2.  Crap.
> Eh?

D'oh, you're right.  3 numbers works fine.  OK, scratch this one.  :)
I can't remember what my issue with GCC's version number was.


> ...everything is listed alphabetically
> > by package name, the most arbitrary ordering possible!
> Well, it is usful if you were asking the question 'what branches of gcc
> do we have'.  So I wouldn't say it's entirely arbitrary.

I don't think I've ever asked myself that.  :)  I'm sure it differs
for each developer.  The questions that I'd like answered run along the
lines of, "which modules use glibc instead of uclibc?"  Or, "what images
will be affected by my changes to the executor?"  Hierarchies seem to
naturally organize themselves to immediately answer questions like this.


> Well, I don't think it's the *amount* of source code at issue - rather
> it's fact that it comes from so many different sources and in different
> forms.  

I'll agree.  But what are the chances of having a large, mature project
that doesn't pull from many different sources?  :)  In my corporate
experience, this this is the norm rather than the exception.


> I don't get that - why can't you check out the various branches into a
> hierarchy like you have now?

Because all the information about all branches for a particular target
needs to be stored in a single file.  I need to write one config file
per target.  The configs file can't query the trees it's importing to
find out what other trees THEY might need, they can't include common
files, etc.  They just don't scale past simple imports.


> Doesn't Robert Collins' config-manager solve that problem?  Although I
> do think that 'update-config' should be in tla.

I agree, I'd like to see update-config's functionality become an
integral part of Arch.  You should have seen the hoops I was jumping
through before I heard about it.  Some of the remnants are still on the
wiki page (now with Ruby equivalents!!).

config-manager is very good at collecting source code from a large
number of different sources and assembling it into a single,
arbitrarily-deep tree.  However, it requires a single static config file
that already knows everything about how to assemble the final tree.  You
need to write 1 config file per target (i.e. 10+ for me), you need to
manually update all affected config files whenever you make a branch, it
can't update its source trees, etc.  It's a very good utility, but it's
designed to solve a different problem than this one.

    - Scott