Re: [Gnu-arch-users] larger trees slowing down

[Dustin Sallings]

On Jan 27, 2004, at 11:13, Tom Lord wrote:

> For small patches, it's proportional to the number of files in the
> tree.

	I'm curious why this is true, especially on a get.  If I only need to 
patch two files, why do I care about the other 2,367?

> Incidentally, at 22K or so revisions, in a natural setting at least,
> I'd be inclined to be thinking about branching a bit more and, most
> likely, doing some log pruning.

	It's not quite 22k, but 2.2k.  Branching isn't an easy option here as 
this is an automated migration from perforce.  I can manually branch, I 
suppose, but it wouldn't be very natural since the way we do things in 
perforce, and the way we would do them in arch don't really mix.

	In perforce (much like what I've seen in CVS), we work on a single 
head-of-line branch and label release candidates as they go out.  If we 
need to make changes to a release, we branch it at that point for those 
changes.  This is the development I need to follow in my arch tree.

	As far as log pruning, what is the recommended practice here?  Do I 
actually remove the historical patch logs from my project?

--
Dustin Sallings