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

[Scott Bronson]

On Tue, 2004-01-27 at 22:56, Robert Collins wrote:
> > [2] Configs
> > 
> > I can't use configs because:
> > - configs are only 1-deep.  I can identify at least 3 levels in my
> > source tree.
> Bullshit. Sorry for the bluntness, but there it it is. I do 3 deep arch
> configs with tla, and with config manager, and they work just fine.

I should be more clear.  Of course you can check out the source code
wherever you would like.  Heck, put it 10 levels deep.  The problem is
the config file *itself* is only 1 deep.

Here's an example.  Let's say that I have a binary image composed of 10
modules.  Each module is composed of 10 projects (this is a fairly
simple example).  See the problem?  Your one config file has to know
about every leaf in the tree.  That's 100 lines that all have to be
correct.  It's impractical, especially when the code is in heavy
development and branches are flying around.

Allowing a config file to include other config files (as you mentioned
later) would help a bit, but even then all the config files still need
to be stored in the single root project.  The root, which everybody must
necessarily rely on, would be in a constant state of churn.  That
doesn't sound good for reliability.

Here's one solution that I can see: allow configs to recurse.

./src/modules/mail-host  address@hidden/mail-host--main--0  slimconfig
./src/modules/web-host   address@hidden/web-host--main--0  slimconfig

After tla checks out mail-host--main--0, it looks for
./src/modules/mail-host/configs/slimconfig.  If it finds it, then it
runs tla build-configs there.  And so on down the line.

You'd still need a whole bunch of config files in the root directory,
but at least they're small and static.  This sounds manageable and keeps
churn out of the root directory.  Would this be a good idea?


> > - if you tla build-configs, and some sources are already checked out,
> > tla starts scattering ,,dupes around.  You can't keep multiple
> > simultaneous configs in flight.
> File bugs against tla or config-manager. Tell us what you need, and why.
> We'll either show you a better way, or acknowledge the bug and get
> someone to fix it.

Sounds good.  If the multi-level configs file prolem I just mentioned
can be fixed, I'll code or make enough noise to get this fixed too.  :)


> > Configs is fine for flat projects with a small number of relatively
> > static source imports.  But it doesn't scale up and it doesn't fix the
> > fundamental problem of exactly how to organize your source.
> No it doesn't. But neither does conflating source code projects with
> related project organisation.

True.  I'm definitely against that.  A multi-hundred-megabyte tree is
fundamentally a crime against nature.  Right now, though, conflating the
projects appears to scale up much easier than the alternative...


> In fact, the latter does significant harm,
> which I'm sure you'll see if you try to merge across a few dozen of
> those conflated projects in a different RCS system.

Um, not really.  Like I said previously, it took me all of 20 minutes of
my time (and a few hours grind time) to bring my CVS source tree into
Subversion.  I used to sling source between CVS and Perforce all the
time.  The one time I used BitKeeper, the entire tree (smaller than this
one) went in without a hitch.  These project layout issues do appear to
be specific to Arch.

    - Scott


P.S. For the record, I'm still using Arch for all my other stuff.  I
just had to go back to CVS for the big tree.