[prev in list] [next in list] [prev in thread] [next in thread] 

List:       darcs-users
Subject:    Re: [darcs-users] [OT] Larry McVoy on the Bitkeeper licence
From:       Juliusz Chroboczek <jch () pps ! jussieu ! fr>
Date:       2005-02-16 17:02:58
Message-ID: tpu0oca14t.fsf () lanthane ! pps ! jussieu ! fr
[Download RAW message or body]

>> > No, we're fine [with large numbers of patches]

It's actually pretty hard to get an integer smaller than 30 bits out
of Haskell ;-) (Yes, that's officially 30, although Ghc implements it
as 32.)

>> > --except that there are times when we hold the entire history of
>> > changeset metadata (not the contents, just the names, logs and
>> > dates) in memory, so you'll start running into trouble when that
>> > starts approaching a GB.

Shouldn't checkpoints avoid that?  (If they don't, that's a bug IMHO.)

>> > On the other hand, perhaps by then you'll be running on 128 bit
>> > computers...

Assuming the metadata is 500 bytes per patch, 50 patches a day, that's
slightly over 5 megabytes of metadata a year.  So the original poster
should reach that limit after a mere 200 years of continuous work.  I
would move to a different project after a century or so.

> True, I meant to say (although I *didn't* say) that there's no fundamental
> limit on the number of patches in a repository.  Practically speaking,
> we've got a long way to go before you'll be happy dealing with huge numbers
> of patches.

Do you know of any issues that are *not* solved by checkpointing?  If
you do, that's a bug, and I'll sit down and start hacking straig^Was
soon as I've got time.

(Well, there is one issue people should be aware of.  Darcs likes to
keep all patches in a single directory, so they really should use
filesystems that have O(n log n) directory access time.  Reiserfs, XFS
and JFS good, Ext2, FFS, UFS and FAT bad.  Ext3 depends on the phase
of the moon, NTFS is not documented.)

                                        Juliusz


[prev in list] [next in list] [prev in thread] [next in thread]