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

[David Roundy]

On Thu, Feb 12, 2004 at 05:57:34PM +0200, Aggelos Economopoulos wrote:
> On Thu, 12 Feb 2004 06:52:22 -0500
> David Roundy <droundy at abridgegame.org> wrote:
> 
> > On Wed, Feb 11, 2004 at 01:47:37PM -0800, Adam Megacz wrote:
> > > 
> > > Sweet.  Any read on how many 0.9.x's there will be before 1.0?  I
> > > know I hate it when people ask me this about XWT, so I feel kinda
> > > hypocritical right now...
> > 
> > No idea how many.  I've been thinking it'd be a couple months for
> > about six months now...
> > 
> > I'd really like to know that darcs works reasonably on large repos
> > before releasing 1.0, but most recently I've had cvsps segfaulting on
> > my bkcvs repo which put an end to its conversion to darcs.
> 
> While I can't provide much feedback these days[0], my problem is
> somewhat relevant so I'll ask anyway. I' ve got a 760M darcs repo[1]
> that's giving me some trouble. Darcs record died with ENOSPC (I had
> temporarily used up most of the free space in the filesystem forgetting
> about the conversion script running in the background) so I thought I'd
> run 'darcs check' before resuming it, only to find out that check
> creates a temporary tree in /tmp which of course is too small for such a
> tree. Could you change it to first try _darcs as a temporary dir and
> only if it's unusable (e.g. read-only) fall back to /tmp?

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

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

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

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

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.

> - hard link the real source tree with _darcs/current and either
>   require the user to only use tools that break hard links (too
>   dangerous IMO) or use permission tricks to prevent accidental
>   edits (also dangerous). Both options are too ugly for words.

I agree.  Not a good plan.
-- 
David Roundy
http://www.abridgegame.org