Re: Kragen Sitaker on Why Darcs Rocks

On Thu, 2007-07-26 at 10:54 -0600, zooko wrote:
> Dear revctrl folks:
> 
> This is the first quantitative measurement of the benefits of the  
> darcs user interface and workflow.
> 
> Of course, there are obvious limitations to the accuracy of this  
> measurement, but in the absence of statistically significant,  
> controlled empirical data, we should pay attention to ad hoc  
> empirical data:
> 
> http://lists.canonical.org/pipermail/kragen-tol/2007-April/000861.html
> 
> Kragen wrote:
> 
> > I've just been importing the change history for the Bicicleta project
> > (stored as a series of .tar.gz source tree snapshots, stone-age-style)
> > into darcs.  Often I've claimed that darcs is nice because it keeps
> > the user-interface excise to a minimum, compared to other
> > source-control systems; this is a sort of natural experience for how
> > small that excise really is, since I'm currently doing almost nothing
> > but dealing with darcs (and tar).
> >
> > I've just recorded 36 changesets in 82 minutes, so the average
> > inter-changeset interval has been about 2.3 minutes, about 140
> > seconds.  This is on a project with around 1000 lines of code as of
> > the last changeset; the changesets I've currently committed represent
> > about seven nights of work over two weeks.
> >
> > This 140-second excise means that darcs makes it practical to record
> > changesets for work units as small as half an hour.  It looks like
> > most of the changesets I'm currently recording represent about an hour
> > of work.
> >
> > Some of those 140 seconds are consumed by navigating and extracting
> > the tar.gz snapshots, so darcs by itself is even more convenient.
> >
> > Darcs rocks.
> >
> > (P.S. some time after writing the above, I finished all of this
> > importation work, with a total of 80 changesets.  I'll push them out
> > soon.)

This just seems plain awkward to me. I mean, in bzr (with bzrtools
installed), its:
bzr init
for tarball in tarballs do:
    bzr import $tarball;
done

And systems without direct tarball import usually support an
add-and-remove-all - e.g. hg's commit -A.

Frankly 140 seconds sounds like a horrendously slow experience; I'd
expect an import of 80 tarballs of < 1000 lines of code to take less
than 80 seconds: there is no code creation involved, although possibly
there is the extraction of a NEWS entry to become a commit message.

-Rob
-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.

signature.asc
Description: This is a digitally signed message part

_______________________________________________
Revctrl mailing list
Revctrl-lEa0QfImRKayfC07vW7uig@xxxxxxxxxxxxxxxx
http://lists.zooko.com/mailman/listinfo/revctrl