[darcs-users] darcs record and huge patches

Aggelos Economopoulos aoiko at cc.ece.ntua.gr
Tue Jan 27 20:36:58 UTC 2004


I was feeling bored this afternoon so I hacked up a simple script that
runs cvsps on a local cvs repository, applies each patchset to a darcs
repo and records it preserving date, author and cvs log.

After testing it on a temporary cvs repo, I tried running it on the
DragonFly[0] repository. It's about 420M, only the initial patches are
very large (it's the FreeBSD import). Currently, it's at PatchSet 54,
which is huge (the file list in the cvs log is ~5000 lines, roughly
equal to the previous 53 PatchSets summed up). However, unless 'record'
time grows faster than linear with patch size, it's taking way too long;
the darcs process sits at RUN state, consuming >90% cpu when the system
is idle, with SIZE and RES staying fixed at 336M and 250M respectively.
I've got 7 snapshots of /proc/darcs_pid/map in the last three hours,
which show that there are 33 vm objects (22 of which are mapped files)
belonging to the process. The addresses of the kernel vm_object
structures, as reported by /proc/.../map have remain unchanged (of
course, it could just be different vm_object structs being allocated at
the same address - not likely) and since, unlike linux, the proc files
don't report the name/inode of the mapped file I can't tell if darcs is
making (slow) progress or if it's stuck.

So, has anyone tried running record on a large tree with many local
changes? If it isn't supposed to work I'll just kill the process, but
if is, how long should it take?

(yeah, I realize this is a stupid way to do the import; I should just
write a unidiff -> darcs patch converter, only this would take me more
than a couple of hours)


[0] (in case you've never heard of it before:)
DragonFly is a fork of FreeBSD-stable. I've been using it ever since
my second disk crashed earlier this month, at first out of necessity,
now because I'm completely satisfied with it :-)

More information about the darcs-users mailing list