[darcs-users] DARCS pushable repository security question

[David Roundy]

On Mon, Oct 20, 2003 at 12:52:51PM -0400, Sean Russell wrote:
> So... out of curiosity, besides the fact that DARCS "doesn't scale", what
> features -- in your opinion -- does BitKeeper have that DARCS lacks?

Well, one is a nice way to browse the repository.  Darcs has the CGI
script, but it's slow, isn't very nice looking and doesn't allow for
searching.  This may sound small, but it really isn't a small deal, as one
of the best uses of a version control is for tracking down who made what
changes when.

Another feature that BitKeeper has that I lack is a nice merge tool.  I've
just added support for external merge tools.  I've tested it with xxdiff
and opendiff, which is Apple's merge tool.  But I suspect these aren't as
nice as BitKeeper's.  In particular neither of them allow you to edit the
merged file when necesary.

By the way, the scaling issue is mostly dealt with.  There were a number of
O(N^2) operations which really caused problems on large repositories, but
those have pretty much been dealt with.  Currently the only problem I know
of with using darcs on large projects is a memory leak in the ghc RTS.  Of
course, that's a very serious problem.  I'm not sure if it's been fixed or
not.  After spending a week or two trying to figure out what I was doing
wrong, I needed to take a break from tracking down memory problems.
Probably after the next darcs release (which I really should be thinking
about getting around to) I'll verify that the RTS leak is still there and
then package up darcs with a test repository and send it to the ghc
maintainer so he can track down the bug.

But even with that leak, pulling, getting and recording seems to be no
problem on large repos (although you can't pull too many patches at
once--pull holds them all in memory).  I only ran into trouble when running
darcs check, which involves reading the entire repository in one go.  The
leak eventually ran my machine out of swap, but even then there was no
thrashing (since I didn't need to access the leaked memory).

Quite probably there are other things BitKeeper does that I don't, but I
can't think of any more offhand that I know of.  Of course, I can't use BK,
so I haven't bothered reading up much about it.

One thing that darcs supports that BK doesn't is cherrypicking of patches.
This is beceause of the support for commuting patches.

> I had poked around with Haskell before I knew about DARCS, but DARCS -- as 
> proof that Haskell was capable of significant projects -- inspired me to 
> really start learning.  I'm about halfway through "The Craft of Functional 
> Programming" -- I've got some sort of intuitive block against functional 
> languages that makes them difficult for me; ML killed me in college -- and I 
> was playing with the idea of contributing to DARCS as a sort of practical 
> application.

Contributions are most certainly welcome! One area (mentioned above) that
could use a fair amount of work, if you want a reasonably large project,
would be the CGI script.  It's not simple--in fact the code is a mess--but
it is reasonably self-contained, it needs work, and I'm not working on it
(so you wouldn't need to worry about me changing something you're working
on).

Another possibility if you're interested in GUI work would be the
fledgeling GUI interface.  That's much cleaner code (since it's more
recent--I've been improving my skills also, darcs being my first haskell
project), and lends itself much better to small contributions.  On the
downside, it requires using wxhaskell, which is a pretty immature project
and not so easy to figure out.  On the other hand, if you're interested in
GUIs, you might consider learning wxhaskell an upside...  Anyhow, on the
GUI side, there are a number of smaller things that could be done.  The
most pressing is creating a decent "patch display" widget which could be
expanded and collapsed.

Another project would be figuring out an interface for repository
searching/browsing.  This would be more of an infrastructure thing, since
I'd want similar or analagous searching features for a GUI browser, the cgi
script (eventually) and probably command-line searching.  I imagine the
best way would be to come up with some kind of a mini-language like the
find(1) flags, but am not sure.  (note that I don't really like the find(1)
interface, I just mean we're solving a similar problem)

If you aren't interested in a large project, doc fixes are always nice (but
won't help you learn haskell much).  Any other improvements you think of
(or bugs you find and fix) are also welcome.  Additional tests are always
welcome (see shell scripts in tests), but again won't help much with
learning haskell.  You could also create tests for inclusion in unit.lhs,
which would be useful, would involve haskell, and would be limited in
extent, except that coming up with useful tests requires an understanding
of a non-trivial amount of my code.
-- 
David Roundy
http://www.abridgegame.org