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

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

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


From: Robert Collins
Subject: Re: [Gnu-arch-users] Re: Making microbranches popular
Date: Wed, 04 Feb 2004 12:07:10 +1100

On Thu, 2004-01-29 at 15:53, Scott Bronson wrote:
> 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.

Ah, yes thats currently true.

> 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, 

A lot.

> 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.

Several issues here. Firstly, there's no requirement that the configs
all be in a single root. A simple iterator that builds a config, then
looks in each built dir for a well known file and builds that config
could do what you want. A better solution is a buildcfg that knows 'when
an include refers to a path that will be built, defer reading it until
after building that path'.

> 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.

Yah, thats like the well known approach I mention above. I'd prefer a
conceptually simpler:
/src/modules/mail-host <location>
./+include /src/modulues/mail-host/slimconfig

> 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?

I don't see the concern with the root dir. With each developer having
their own branch it shouldn't be an issue. Even if it is an issue,
includes are more generally useful and equally applicable here.

> 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.  :)

In config-manager this can definately be solved.

Rob
-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

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