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

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

Re: [Gnu-arch-users] Some issues


From: Colin Walters
Subject: Re: [Gnu-arch-users] Some issues
Date: Wed, 09 Jun 2004 11:44:46 -0400

On Wed, 2004-06-09 at 10:03, Florian Weimer wrote:
> I've finally collected a few issues that might be the reason why I
> back away from tla each time I start using it again, despite being
> always excited by it when reading about it.
> 
>   <http://www.enyo.de/fw/software/arch/design-issues.html>

I will respond to the rest later, but:

> GNU arch does not support a centralized development model which lacks
> a single, designated committer.

Did we not *just* have this discussion the gcc list?  Why do you
continue to perpetuate this completely false idea?

For Rhythmbox we have a centralized archive with multiple commiters.  It
works *perfectly*.   I even created a whole Wiki page about how to set
it up:

http://wiki.gnuarch.org/moin.cgi/Centralized_20Development

At most you have some handwaving about "changeset rates" and "log
pruning".  The log pruning is a solved problem - simply delete older
logs.  I've already done that once, by doing a "grep" for logs from
2003.

Actually let me respond to your paragraph now:

> I'd love to look at a project which uses tla, hasn't got a designated
> patch integrator, and has a significant changeset creation rate.

Define "significant".

> There are quite a few interesting questions: How do they trim logs (to
> cut down the inode waste)?  

Via "grep", "rm", and "tla commit".

> Is the lack of versioned branch creation
> (or the complete lack of branch removal) a problem?  

No.

> Is "tla
> push-mirror" fast enough for mirroring new changes from the central
> repository?  

It has never been a problem.  It could certainly be faster though.

Anyways, there is a huge difference here between "does not support" and
"maybe isn't fast enough for me, even though I haven't really tried", or
"takes up too many inodes for my taste".

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


reply via email to

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