[darcs-users] darcs record and huge patches
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 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)
 (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