Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Programming IT Technology

Interview: David Roundy of Darcs Revision Control 173

comforteagle writes "In the aftermath of our last interview with Tom Lord, regardless of personalities, it became apparent that the idea of decentralizing CVS is a big deal. Many mentioned darcs as an alternative to Arch. Mark Stosberg has interviewed project head-hancho David Roundy about darcs, his 'theory of patches,' what's next, and on using Haskell for the project."
This discussion has been archived. No new comments can be posted.

Interview: David Roundy of Darcs Revision Control

Comments Filter:
  • by PhYrE2k2 ( 806396 ) on Thursday November 25, 2004 @01:47AM (#10916256)
    I did read the article, however I do DISAGREE with that comment in the article. People won't learn a language for one program, and there is not a large enough body who know the language to really truly UNDERSTAND the program and enough about it to make modifications and additions to it. Compare that to a bunch of C/C++/Java/Perl developers with a massive community body, it's a lot easier to get people to contribute. -M
  • by Anonymous Coward on Thursday November 25, 2004 @02:20AM (#10916362)
    It's only one major OSS that's written in Haskell, the language itself is all over industry.

    In that case, it should be trivial for you to name several examples.

    By the way, I've started down the path toward installing haskell a couple of times in an effort to try darcs, but gave up an hour or two in each time, because I do not want to run foreign binaries and therefore have to go through a pretty complex bootstrapping process to install haskell.

    If darcs were written in any language that is already installed on my PC and had no other external dependency that I lack, I would probably at least have darcs installed on PC as well by now and might have become a darcs user. Granted, if running darcs were really that important to me (perhaps even if I did not have other doubts about darcs), I would spend a few days to really get Haskell and darcs installed, but it's not that important to me right now, and I think my calculation is probably typical of a potential user population that is probably a multiple of the size of the existing darcs population.

    Now it might be that darcs would not be where it is today technical with the resources that were used to make it because Haskell is so much more super-productive of a language to work in, so the technical decision to go with Haskell really has maximized adoption or development or whatever metric you want to consider, although I would expect Haskell-based programs to be winning all sorts of evolutionary battles against competing projects, as seems to be the case with perl, python, zope, plone, and linux. The decision to use Haskell is a complex empirical judgement call that is not mine to make, but your omission of examples increases my skepticism.

  • by Pseudonym ( 62607 ) on Thursday November 25, 2004 @02:37AM (#10916419)

    I'm not the grandparent poster. I am a long-time Haskell user, though.

    Saying that Haskell is "all over industry" is a gross exaggeration. Anecdotal evidence from Haskell users is that they are all over industry, and they tend to use Haskell in their work, though not necessarily in code that other people see. I, for example, have been known to prototype algorithms in Haskell and then translate them into C++ for our product.

    Having said that, there are several consultants out there who write custom apps for clients in Haskell, and at least two [aetion.com] companies [galoisconnections.com] who heavily rely on it.

    It is fair to say that Haskell is all over academia, being used to solve difficult CS-like problems. However, academic uses tend not to impress people, even if it is the best tool for a particular job.

  • Re:Darcs is KISS (Score:2, Interesting)

    by mindstrm ( 20013 ) on Thursday November 25, 2004 @02:47AM (#10916451)
    Some nice features there... but you open up with saying "Like CVS, you can get productive within minutes; the same cannot be said for Arch or even Subversion."

    Subversion:

    # Create a local respitory & add files.

    svnadmin create /path/to/repository
    svn import * file://path/to/repository

    I'm really not quite sure how that qualifies as "can't be set up in minutes". Easily as fast as darcs, and very simple.

    The distributed features are what make darcs unique.. it doesn't seem to me to be any fundamentally easier or faster for basic revision control than subversion, though.
  • by Pseudonym ( 62607 ) on Thursday November 25, 2004 @02:49AM (#10916454)
    The problem with it is that because it's functional you often end up restructuring half the program for what would have been a trivial change in an imperative language.

    While I don't disagree with this, there are some counter-arguments too:

    • If you find yourself doing that, you may have written your original program in an imperative style in the first place. Alan Holub's argument about getter/setter methods [javaworld.com] applies to declarative programming too. If you wrote in a more language-ideomatic style, you might not be facing a huge restructure at all.
    • Much the same problem can happen in imperative languages, only the class of changes which would trigger such a restructure are different. For example, in a non-GC'd language, you may end up restructuring your program if some critical data lifetime changes. Or, instead of restructuring your program, you might prefer to hack it up instead, making it less maintainable. (It might be argued that languages like Haskell, which discourage this kind of hackery, might be a good thing in the hands of a certain kind of programmer.)
    • Even if you do have to restructure half the program, tools like Haskell's type system make this a less painful task than it would otherwise be.

    Knowing a language also means knowing what kinds of changes are painful and what kinds of changes are not. Knowing this in advance helps you write your programs to be more future-proof.

  • by mattr ( 78516 ) <mattr&telebody,com> on Thursday November 25, 2004 @02:51AM (#10916466) Homepage Journal
    The previous poster who showed how easy it is to use darcs sold me, I am thinking it could be real useful
    right away just for my own work.

    Took a brief look at the pretty site. Personally I've been intrigued by Haskell for a while though never jumped in, and I use Perl. My questions:

    1. Can the elegant quantum reality inspired code be separated off? Though my take is that it is already separate, as a Haskell function.. the reason for the question is that it sounds like it would be useful for a whole lot of things. Instead of implementing app/protocol X over darcs, I am wondering if you could include an (inline) Haskell module in a Perl app that would do the rest.

    1.5 ..or is there another way to access the Haskell theory of patches functionality from outside the app?

    2. Next question, can Haskell be embedded inline in Perl code?

    3. Can the quantum theory of patches be implemented as a Perl module, and ignoring the probably truth that anything not Haskell will not be as elegant as Haskell, would such an implementation benefit/be renedered possible by using the Perl functional or Quantum:: modules?

    3.5 At risk of a flame war I'd love to use this in XEmacs. Anybody? This post written in vim so no flames please!

    4. Reading about the symmetry or lack of it, concepts of physics this is helping me think about an app of my own. I'd like to read more about this does anyone have links?

    5. Time to learn Haskell!! Great!

  • Re:CVS (Score:3, Interesting)

    by stoborrobots ( 577882 ) on Thursday November 25, 2004 @02:58AM (#10916484)
    The Future was here in 1996 - Check out Reliable Software's Code Co-op [relisoft.com].

    The Peer-to-peer Version Control System for Distributed Teams
    Code Co-op is the version control system for distributed development that adds mobility, simplicity, and robust functionality to your Windows development projects.
    • Mobility for collaboration from any location using your existing infrastructure
      - no server required;
    • Simplicity to give you quick access to project files and history regardless of a network connection;
    • Robust functionality to give you all the control and security you require for managing your software assets.

    With Code Co-op you can:
    - Collaborate from anywhere using Email, LAN, and VPN
    - Access your project files and history without a network connection
    - Review file changes with the built-in Visual Differ or Beyond Compare Differ
    - View, compare, or restore any iteration of your project or file regardless of a label
    - Integrate with your favorite development tools
    - Forgo costly server maintenance
    - Rely on a secure, fully transactional database with automatic back-ups
    - Implement source control in minutes for only $159 per user

  • by pnot ( 96038 ) on Thursday November 25, 2004 @03:05AM (#10916507)
    me: Why on earth would the users of a piece of software care about the language it's written in?

    you: If your users are FOSS developers, they quite likely care about the ability to modify the tool, which includes caring about the languate in which it is written.

    Interesting point. Certainly FOSS developers care about being legally allowed to modify code, but I'm not sure that they care, on the whole, about the language.

    emacs, for example, is largely written in elisp -- hardly a mainstream language. Yet it's extremely popular, even among people who don't know any lisp. People who find the need to extend it get a good excuse to learn lisp in a well-motivated, incremental way.

    Speaking personally, I'd be ''more'' inclined to hack on a project written in something interesting like Haskell, ML, Smalltalk, or Lisp. (In fact I chose my current main project partly as an excuse to learn Lisp.) A lot of people like having a motivation for learning a new language, or a practical use for an "academic" language they happen to know. (I learned Haskell in university, so I'd be quite keen to get to use it in the "real world".)

    I think the only time I'd care about the language of a program I'm using would be if it were written in something particularly horrible -- "urgh, if I ever want to modify this I'll have to learn befunge!" But perhaps that's the way some people view Haskell ;-).

    It's a matter of taste, I suppose. I do acknowledge that I'm a bit of a language nut.

    I still maintain that quality is more important than quantity, though. I've been teaching C and Java to second-year undergraduates this year -- having seen some of their code, I can safely say that if I were starting an OSS project, I'd rather have one seasoned Haskell hacker on board than the entire lot of 'em :-).
  • by Earlybird ( 56426 ) <slashdot @ p u r e f i c t ion.net> on Thursday November 25, 2004 @03:06AM (#10916508) Homepage
    I can't answer all of your questions. The mailing list [abridgegame.org] would be the place to ask.

    • 2. Next question, can Haskell be embedded inline in Perl code?

    Not that I'm aware. However, all you need is an embeddable Haskell interpreter. I believe this is possible with Hugs [haskell.org], which has a "server interface [haskell.org]", and possibly even with ghc [haskell.org] (the native compiler that Darcs is compiled with). You'd probably have to write the C/Perl interface yourself.

    • 3. Can the quantum theory of patches be implemented as a Perl module ...

    Certainly.

    • 4. Reading about the symmetry or lack of it, concepts of physics this is helping me think about an app of my own. I'd like to read more about this does anyone have links?

    More than anything it's mathematics. But David Roundy, the author of Darcs, is a physicist, and may have some pointers for you.

    • 5. Time to learn Haskell!! Great!

    If you're a Perl hacker, you might be interested in this [gla.ac.uk]. Scary, eh?

  • Needs wider adoption (Score:5, Interesting)

    by haeger ( 85819 ) on Thursday November 25, 2004 @03:07AM (#10916514)
    While darcs is nice it needs wider adoption. When it comes to a project that people are working on, you have almost as many boxes as you have developers and for a revision control program to be adopted and used there has to be binaries for all those devels. AFAIR there are some issues with the win32 binary? One of our devels had major problems with it and now we're living with both a cvs and a darcs repository, and noone really knows where to send patches. I think it's safe to say that our project is dying, if not dead already.

    Not that I blame darcs or anything, just that one need to be sure that darcs work for everyone before commiting to it. CVS works on all platforms and is well tested. Darcs will hopefully get there.

    And yes, I did my part and created a package for my platform. It's linked from the binary download page.

    .haeger

  • Re:Darcs is KISS (Score:5, Interesting)

    by Earlybird ( 56426 ) <slashdot @ p u r e f i c t ion.net> on Thursday November 25, 2004 @04:53AM (#10916845) Homepage
    • One of the nice things about subversion (recently converted user, very happy so far) is the support for multiple url formats and communications methods.

    Darcs and Arch both have this. (Arch undoubtedly has the most extensive protocol support of any revision control system.)

    • Another notable thing (for windows users) is TortoiseSVN, (an explorer shell extension) which is just great.

    Tortoise is quite nice indeed -- I used TortoiseCVS for years.

    • I can see how the distributed, multi-repo model of bitkeeper/darcs/arch is superior but svn looks good if you only need single-repo.

    Need is just one aspect of the development process; right now CVS gives most people what they need, despite the cracks in the lacquer. Darcs doesn't just erase the cracks, but improves the process.

    For example, I occasionally submit patches to certain open-source projects. The easiest way to do this is to check out the CVS repository, make my changes, and do "cvs diff -u" to get the patches in that format, which I tend post to some Bugzilla server or email to somebody. But I can't commit them. I don't mean to the master repository -- I mean locally. There's no way I can bundle my file patches in a changeset and keep its history. I'm basically managing a CVS working directory where my changes are never checked in.

    With Darcs, I just do "darcs get" to get the master repository, make my changes, commit them locally. I can use "darcs send" to submit my changes to the project maintainer. Anyone else can grab my patches with "darcs get" or "darcs pull". I can be Alan Cox to some Linus without breaking my back over patch management.

  • by Phil John ( 576633 ) <phil.webstarsltd@com> on Thursday November 25, 2004 @06:42AM (#10917105)
    ...why not make the jump to a system meant to replace CVS's centralized model, such as subversion. Forks are very easy to do, truly atomic commits, CVS to SVN repository converter, similar command line params to CVS etc. etc.

    Our current repo is 9 gigs and works beautifully.
  • Re:Here: (Score:4, Interesting)

    by boa13 ( 548222 ) on Thursday November 25, 2004 @07:13AM (#10917190) Homepage Journal
    One important feature is missing from the page:

    Support for signing patches and archives

    Allows to verify who created/commited the patches. Allows to verify the integrity of a repository in case of compromise.

    * Arch: Excellent. Each patch can be signed, repositories can be fully verified.
    * Darcs: Incomplete. Patches sent by email can be signed so the recipient can verify the identity of the submitter. No support for verifying repository integrity. [1]
    * Subversion: N/A

    [1] Problem is: You can only sign something that will not vary once distributed, Darcs patches vary once distributed.
  • Linus opinion (Score:1, Interesting)

    by Anonymous Coward on Thursday November 25, 2004 @07:30AM (#10917241)
    Do you see Darcs as a viable version control system for the Linux kernel?

    How do you view Linus opinion on version control systems?
  • by Anonymous Coward on Thursday November 25, 2004 @07:56PM (#10920953)
    Having designed,implemented and supported an enterprise-wide (1200+ user) Configuration Management services for over 3 years, I find that the number one thing that most developers want is version control that STAYS OUT OF THE WAY. They DON'T want every bell and whistle. They have to concentrate on their code, not some "neat" (or read pain in the a$$) way to do something.

    I support ClearCase/ClearQuest worldwide for a large corp. I deal with the helpdesk calls, the support, the engineering efforts the "best practices", and sometimes the teaching of best practices.

    Why would anyone want to deliver a patch out of sequence? It should make sense in the simplest sense, i.e. "if I apply this I get that". Most developers don't concentrate that deep.

    I personally think ClearCase is great if your industry is software development, but for regular development, it's like driving a tank to the store for a loaf of bread. and it's EXPENSE!!!!!

    If I had to move to another product, I would at this time choose Subversion. It's super simple, fast, distributed (for world-wide development efforts or content submissions) and well supported. It has support for Eclipse, a Windows client and a good security model.

    I looked at other systems and was always amazed by the convoluted version models.

    And why would I let developers "declare" a set of files as a "change"? It's hard enough to get the concept of a baseline into their heads. They always look at it as "I only changed 2 files, why do I have to label everything?" and I always have to ask "How do you tell what made up a version?".

    There's a LOT more than neat ways to do things involved in configuration management.

    I would LOVE to see a simple application that could track defects/Change Requests and link them to a version or baseline SIMPLY. Simple is not easy, because the truth is that managing change in a distributed model is very difficult. By simple I mean simple to use, simple to manage, and simple to maintain.

    I haven't found it yet, but I have found parts. I may have to roll up my sleeves soon.

Anyone can make an omelet with eggs. The trick is to make one with none.

Working...