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, 28 Jan 2004 17:56:28 +1100

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

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

> I still hadn't given up on Arch so last week I wrote my own configs
> command that overcomes these shortcomings.  And it didn't get me very
> far.  The config files are large require a lot of maintenance.  If I
> want to branch some sources, I need to ensure that *all* affected
> configs files are updated.

You need configs that support includes. Someone (sorry the name escapes
me) has done a patch for that - but the exact syntax and semantics are
still in discussion.

>   Otherwise, I need to track down why binaries
> on one architecture are showing different bugs/features than binaries on
> another arch -- they were all supposedly compiled from the same source. 
> "tla update" in the root directory doesn't just sort all this out the
> way it does in CVS and svn.

For quite good reason. cm examine | cm update will do analogous to what
cvs update does though - without a config.

> My biggest problem with configs, though, is that there's no way to get a
> feel for the organization of your project.  It takes a lot of reading
> and diffing config files to see how the different components
> interrelate.  This is the sort of information that is immediately
> apparent when the source code is arranged in a hierarchy.

Thats not a problem of configs per se - it's a problem of your layout.
Honestly, look closer at this one.

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

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]