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: Colin Walters
Subject: Re: [Gnu-arch-users] Re: Making microbranches popular
Date: Tue, 27 Jan 2004 21:52:44 -0500

On Tue, 2004-01-27 at 18:39, Scott Bronson wrote:

> Now, I ask myself, how can I best express this tree in Arch?  First I
> tried creating different archives for the different parts of the tree:
> address@hidden, address@hidden  This was obviously a bad
> call.  Arch doesn't handle multiple simultaneous archives well (weird
> errors,

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

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

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.

Then, you have a config that ties all of this together into a hierarchy
like the one you have now.

> However, there are multiple copies of gcc--vendor--3.3 in the tree
> (thanks to their weird idea of stability).  Arch won't allow
> gcc--vendor--3.3.1 and gcc--vendor--3.3.2.  Crap.

Eh?

address@hidden> tla archive-setup address@hidden/foo--b--1.0
* creating category address@hidden/foo
* creating branch address@hidden/foo--b
* creating version address@hidden/foo--b--1.0
address@hidden> tla archive-setup address@hidden/foo--b--1.0.1
* creating version address@hidden/foo--b--1.0.1

> Good, right?  The problem is, I now have a totally flat source tree. 
> With >50 packages, this means that everything is listed alphabetically
> by package name, the most arbitrary ordering possible!  Well, this
> didn't work out.

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.

> After struggling with arch for a week, I'm back to CVS.  I don't think
> I'm being clueless or lazy. 

I agree - it is true that your setup can be mapped pretty cleanly onto a
hierarchical namespace.

> I'm using Arch for my small hacks right now and I like it a lot.  But, I
> don't think it will ever be useful for mid-sized development projects
> like mine, or for projects that already have a decent amount of source
> code in a traditional SCM.  

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 can't use configs because:
> - configs are only 1-deep.  I can identify at least 3 levels in my
> source tree.

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

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

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

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


reply via email to

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