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

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

RE: [Gnu-arch-users] Re: recent changes


From: Andy Tai
Subject: RE: [Gnu-arch-users] Re: recent changes
Date: Sun, 20 Nov 2005 01:12:00 -0800 (PST)

Well, Arch 1 may always suck in some way in this regard... I remember people 
complaining about the need to manually specify the use of the revision 
libraries... and every 50th
is just a heuristic.  Anyway, maybe after the next release we may then adapt 
the baz behavior,
with the number of 50 as default but adjustable, and then we can further 
explore if even better
algorithms can be applied on top of the Arch 1.x archive formats... 

Based on my understanding, I am afraid performance on large trees will be a 
continuous headache
for tla... why, say, tla was not a good choice for the Linux kernel...


--- Derek Zhou <address@hidden> wrote:

> One thing that have frustrate lots of newbies (including me) is the fact that 
> to get reasonably
> good performance in any realistic sized tree, you have to have a revision 
> library. So why do we
> just enforce this policy in the software so nobody accidentally say arch 
> sucks?
> Derek  
> 
> > -----Original Message-----
> > From: Andy Tai [mailto:address@hidden 
> > Sent: Friday, November 18, 2005 1:56 PM
> > To: Matthieu Moy; Derek Zhou
> > Cc: address@hidden
> > Subject: Re: [Gnu-arch-users] Re: recent changes
> > 
> > 
> > Yes,  cache reversions every 50th one may be useful but 
> > should be done in a smarter manner...  if
> > the baz algorithms can be applied in a less disruptive way 
> > that would be great...
> > 
> > --- Matthieu Moy <address@hidden> wrote:
> > 
> > > address@hidden (Ludovic Court�s) writes:
> > 
> > > >> * cacherev every 50 revisions and every tag even within the same
> > > >> archive. Disk is cheap
> > > >
> > > > While I agree this should be the default, I think it should not be
> > > > hard-wired.
> > > 
> > > In particular, cachedrevs for all tags are a bad choice if you
> > > microbranch a lot. It does not only cost disk space, it also costs
> > > bandwidth: if you have a close ancestor in your revision 
> > library, it's
> > > cheaper to apply a few changesets to it than to get the cached
> > > revision. Bazaar has clever algorithms to chose which full tree
> > > revision to start with (a cachedrev, the initial import, or in your
> > > revision library), but that's relatively deep changes, I don't think
> > > this will ever be merged into tla. 
> > > -- 
> > > Matthieu
> > 
> > 
> 
> 




reply via email to

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