[darcs-users] Re: darcs and patches@ mail

[Aggelos Economopoulos]

On Fri, 13 Feb 2004 09:20:41 -0500
David Roundy <droundy at abridgegame.org> wrote:
> On Thu, Feb 12, 2004 at 05:57:34PM +0200, Aggelos Economopoulos wrote:
[...]
> You can set TMPDIR to control where darcs puts the temporary tree. 
> I'm sure I should add that to the docs somewhere, but I'm not sure
> where...

Thanks. As with EMAIL, TMPDIR is also used by other programs - could you
add a DARCS_TMPDIR override?

> > Also, is there a plan to reduce space consumption, even at the
> > expense of cpu usage or data protection?
> 
> Not really.  It seems to me that a factor of two isn't too bad, if
> you're going to be doing active development on a project.

However active your development activities are, I doubt you'll touch a
significant percentage of a 300M project on a weekly basis so most of
the files in _darcs/current are irrelevant to darcs performance. On the
other hand, I too don't think space consumption is the biggest problem
when using darcs on large trees - just trying to find out if you've got
any long-term plans for it.

> > On my 760M repo, _darcs/patches is only 83M, so shrinking
> > _darcs/current or the actual source tree would make a big
> > difference(tm). Some obvious ideas:
> > 
> > - keep _darcs/current compressed as well
> 
> This could be done, but it would cost us in speed and memory usage,
> and as long as the files are stored separately, if the repo is made of
> many small files the gain would most likely be very small.  Perhaps a
> greater gain (at least for projects with many small files running on a
> filesystem with a non-so-small block size) would come from using a
> database (I'm thinking Berkeley DB) to store _darcs/current.  This
> would have the additional advantage of providing transactions and
> locking, which would be handy, and might be faster as well.

I don't know how easy it would be to do this in haskell, but using an
archiver (e.g. tar) + compression should make a considerable difference.
Using BerkleyDB for current is an interesting idea; I had only thought
about using it for patches till now.

> Switching to using a database to store current is definitely
> appealing, but certainly not for until after 1.0.

Certainly :)

> It would be nice to also store the patches in a database, but then
> serving them up to remote users would be awkward.  :( I guess I could
> pretty easily write a little server that just serves up inventory and
> patches, but I like the current system of not requiring that you run a
> darcs-specific server.

Sure, I enjoy the benefits of using plain http too, but a special-
purpose server would scale up much easier than the current model, so it
seems necessary if you want to really support large repositories.

Aggelos