Interview: David Roundy of Darcs Revision Control

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."

Comments

Haskell just won't cut it

[PhYrE2k2]

While "Darcs is written in a Haskell, a functional language that is relatively unknown compared to C or Perl", this really does hurt it's common use. Not being able to get a larger group of developers such as C, C++, or even some interpreted projects means that it becomes one or a few developers working on this project which means fewer patches and additions. A community project will ultimately be the versioning system for community projects. -M

Re:Haskell just won't cut it

[QuantumG]

So basically you didn't read the article. He gets more developers because it is written in Haskell than he would otherwise because it's one of the few real applications that are written in Haskell - which means if you're someone who just learnt Haskell for the hell of it you've got somewhere to apply those skills.

Re:Haskell just won't cut it

[Pseudonym]

Just like how nobody uses CVSup because it's written in Modula-3, right?

Re:Haskell just won't cut it

[PhYrE2k2]

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

Re:Haskell just won't cut it

[pnot]

You wrote:

While "Darcs is written in a Haskell, a functional language that is relatively unknown compared to C or Perl", this really does hurt it's common use.

How will the choice of language hurt darcs's use? Why on earth would the users of a piece of software care about the language it's written in?

You wrote:

Not being able to get a larger group of developers such as C, C++, or even some interpreted projects means that it becomes one or a few developers working on this project

From the article:

I've been surprised by the number and quality of contributors darcs has had. There seem to be quite a few people out there just looking for somewhere to use Haskell! :) And in fact, there have also been developers who learned Haskell expressly for the purpose of contributing to darcs. It's such a pleasant language to work with that I think it's more of a draw to developers than a put-off.

So perhaps you should attempt to assimilate some facts before trotting out your tedious, ill-informed prejudices, hmmm?

Furthermore, it's not just about the sheer number of developers, it's about the power of the language. A million monkeys writing code are still only monkeys, and the more developers you have on a project, the more co-ordination is required (read Fred Brooks' The Mythical Man-Month if you don't believe me).

If "number of potential developers" were the only criterion for choosing a project's programming language, everything would be written in BASIC. And Paul Graham makes a good case for coding in less common languages: you'll get people smart enough to learn unusual languages for the hell of it, rather than a mass of monkeys who have little interest in building great software and just want to learn this week's marketable language to improve their employment prospects.

Re:Haskell just won't cut it

[cduffy]

Some people will learn a language because they want to know a language that has that specific set of features, regardless of what applications have already been written in that language.

It's a small group, but if you've the only game in town (in terms of OSS projects for them to work with)... well, that works out pretty well for you!

No, if Darcs has any major issues, it's the RAM and CPU time requirements, some of which the design makes inherently unresolvable.

Re:Haskell just won't cut it

[Pseudonym]

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 companies 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:Haskell just won't cut it

[Mr. Slippery]

Why on earth would the users of a piece of software care about the language it's written in?

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.

Re:Haskell just won't cut it

[Pseudonym]

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 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.

Re:Haskell just won't cut it

[pnot]

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 :-).

Re:Haskell just won't cut it

[Anonymous Coward]

Seriously, you might consider giving Haskell a little more respect. This was the language used for not only the first but also second place winner for the ICFP Programming Contest this year.

http://www.cis.upenn.edu/proj/plclub/contest/res ul ts.php

You don't need as many programmers when you have this kind of tool in your hands.

Re:Haskell just won't cut it

[Chuan-kai Lin]

(arguments that Haskell will not cut it because it does not have a large user community)

I have to say that I am troubled by this kind of attitude, especially on Slashdot. True, open source is mostly about freedom, but it is also about diversity, about innovation, and about trying to do things the right way. Since when do we condemn a project to failure just because it makes a non-mainstream choice, even if the choice was preferred by the developers due to technical superiority?

How do you feel when PHBs assure you that bringing Linux into the server room is sure to fail because it is not mainstream like Windows?

Since when do we let that stop us?

CVS-style development with darcs

[Ashish Kulkarni]

There was a good post on this on the mailing list a while ago.

Re:Decentralization

[cduffy]

Mighty vague, that. What instances is CVS better in?

Compared to modern revision control systems, I don't think CVS is even in the running. It's SVN (in the non-distributed camp), and Arch, Darcs and Monotone in the distributed camp... with plenty of infighting between them.

Darcs is KISS

[Earlybird]

Among the plethora of emerging version control systems -- Subversion, Arch, Monotone and so on -- Darcs stands out for its simplicity and thoughtful design.

Like CVS, you can get productive within minutes; the same cannot be said for Arch or even Subversion. Let's see:

john@somewhere$ cd ~/myproject
john@somewhere$ darcs init

You now have a Darcs repository! Let's do something with it:

john@somewhere$ darcs add -r *
john@somewhere$ darcs record -am "Initial import."
Finished recording patch 'Initial import.'

Now your repository contains all your files. Let's look at the changelog:

john@somewhere$ darcs changes
Thu Nov 25 06:26:19 CET 2004 johndoe@example.com
* Initial import.

Now, where's the server? You need a server to share your repository, right? Nearly -- every repository is a potential server, as long as it's accessible either through the file system, through SSH/SFTP, HTTP or email. Let's go to another machine and check out the repository we just made:

jane@elsewhere$ darcs get john@somewhere:~/myproject
Copying patches...
.
Finished getting.

We now have a repository on Jane's box. Let's make a modification:

jane@elsewhere$ echo "#include <foo.h>" >>foo.c
jane@elsewhere$ darcs whatsnew --summary
M ./foo.c +1
jane@elsewhere$ darcs whatsnew
{
hunk ./foo.c 2
+#include <foo.h>
}

This last output, by the way, is Darcs' patch format. A "hunk" is a line-based diff. Other types of changes that may be contained in a changeset include renames, moves and binary changes. (Yes, you can also get a GNU-patch-compatible output similar to "cvs diff".)

Now let's commit and push the changes back to John's repository:

jane@elsewhere$ darcs record -am "Added a missing include."
jane@elsewhere$ darcs push -a
[...]
Finished applying...

Now we can go back to John's machine and look:

john@somewhere$ darcs changes
Thu Nov 25 06:26:10 CET 2004 janedoe@example.com
* Added missing include.

Thu Nov 25 06:26:19 CET 2004 johndoe@example.com
* Initial import.

(Note how Darcs generates a GNU-style changelog for you automatically.)

Where are the revision numbers, you ask? Well, they don't exist, because they're not needed. Darcs is changeset-oriented, not file-oriented. You can refer to a changeset by name, date, or a special hash identity.

Darcs changesets aren't just GNU patches; they have context, which means, for example, that someone can check out a repository, move a file "foo.c" into the directory "bar" and commit; meanwhile, another person, working on an older copy of the same repository, edits foo.c (which is still in its old location) and commits that. Darcs know that this edit should apply to foo.c in the new location -- and unlike CVS, you don't need to do anything similar to "cvs update" if you're committing files that have been changed on the server. In other words, people can freely commit changes, and the only kind of visible "conflict" will occur when you actually edit the exact same line.

Unlike CVS and Subversion, but like Arch and Monotone, Darcs is a distributed version control system. Repositories are islands which are constantly out of sync with each other, and Darcs' patch commutation system takes care of integration the changes that flow between them.

This system has several extremely useful effects:

• Offline mode. You can commit changes even if you're on the road with no access to the server. That's because your own working directory is a repository in its own righ

Re:Darcs is KISS

[mindstrm]

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.

Re:Darcs is KISS

[jbert]

Yup.

svn co svn+ssh://user@host/path/to/repo repo

will check out a repository, tunnelled over ssh. No need to run a subversion server to do that.

One of the nice things about subversion (recently converted user, very happy so far) is the support for multiple url formats and communications methods.

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

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.

Also, bitkeeper has some powerful gui tools (and probably the kitchen sink too). Haven't really used arch/darcs.

Re:Darcs is KISS

[Earlybird]

• Subversion runs through Apache/2, so if you've got ssl setup in Apache, you have SSL on your repository ...

Sorry, but we were talking about simplicity here. Apache 2.0, SSL, authentication, WebDAV... Setting up a repository with what you suggest is more than one step -- it's usually a lot of steps, especially considering Subversion's external dependencies.

Setting up a Darcs repository consists of doing this:

$ darcs init

And Darcs works over SSH:

$ darcs get bob@example.com:/some/project

This gives you security (leveraging the public-key encryption system of OpenSSH) without having to set up Apache, SSL, virtual hosts, WebDAV or authentication.

You can also use Darcs read-only over HTTP (the following will check out the Darcs sources):

$ darcs get http://www.abridgegame.org/repos/darcs/

All that's required is a web server mapping the URL to your repository -- any one will do.

I'm sure Subversion works similarly, though.

Re:Darcs is KISS

[Earlybird]

• 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.

Re:Darcs is KISS

[o1d5ch001]

You can run Subversion using the svnserve tool as well. To start the server:

svnserve -d -c /repo

To access it:

svn co svn://somehostname

or with ssh

svn co svn+ssh://somehostname

Self-hosting

[Earlybird]

I believe the term you're looking for is self-hosting. Subversion, for example, was originally maintained in CVS, and has a CVS gateway for maintaining redundant systems.

For pilot-testing a migration to Darcs, there are scripts available that convert other repository formats (Subversion, CVS, possibly others) into Darcs (and back, actually), so you avoid losing history when making the transition.

Its the clients and API that matter

[monkeyboy87]

no matter what the change set "theory" are implemented into the product if it's not easy to do things with it, it will languish. VSS and CVS are still used widely becuase there are lots of clients and tools that make it useful. the draw of SVN (loved or hated) is that it has a good client and the command line client is easy to drive with scripting tools

Interesting app. non-troll questions

[mattr]

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:Interesting app. non-troll questions

[Earlybird]

I can't answer all of your questions. The mailing list 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, which has a "server interface", and possibly even with ghc (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. Scary, eh?

Re:Interesting app. non-troll questions

[David Roundy]

1. It's actually hard to use the patch commutation code to do any good outside the concept of a darcs repository.

1.5 I've thought about creating a C library for manipulating/querying darcs repositories, but haven't gotten around to it. The hard part would be of course designing the API. Ideally I'd like the interface to be such that programs using the library couldn't accidentally corrupt the repository.

2. Darcs requires ghc, since it uses some library code only available in ghc to do more efficient IO, string manipulation and to access zlib. It turns out to be a pain on many systems to link with the necesary libaries when using the interpereted version of ghc. So probably accessing darcs from perl will have to go through the executable until a C library is written (which could of course have perl bindings).

3. Rewriting darcs in perl (or parts of it) would be possible, but would be a pain. In particular, the commutation of patches which have conflicts is pretty complicated.

Re:CVS

[stoborrobots]

The Future was here in 1996 - Check out Reliable Software's Code Co-op.

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

Needs wider adoption

[haeger]

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:Needs wider adoption

[Anonymous Coward]

CVS works on all platforms

... for an appropriate definition of "works".

CVS doesn't have atomic check-in, it's directory handling is crap, etc. etc. Still, like you said, it's probably still the best bet if you want to do development on both UNIX and Win32, although Subversion(!) is catching up fast.

Re:Theory of patches

[Earlybird]

• Let me summarize the "theory of patches": you reverse patches in the opposit order of applying them.

No. Darcs can, and will, apply patches out of order. From the Darcs manual:

• The development of a simplified theory of patches is what originally motivated me to create darcs. This patch formalism means that darcs patches have a set of properties, which make possible manipulations that couldn't be done in other revision control systems. First, every patch is invertible. Secondly, sequential patches (i.e. patches that are created in sequence, one after the other) can be reordered, although this reordering can fail, which means the second patch is dependent on the first. Thirdly, patches which are in parallel (i.e. both patches were created by modifying identical trees) can be merged, and the result of a set of merges is independent of the order in which the merges are performed. This last property is critical to darcs' philosophy, as it means that a particular version of a source tree is fully defined by the list of patches that are in it, i.e. there is no issue regarding the order in which merges are performed.

A distributed version control system that required all patches to be applied in order would be painful indeed to use.

• I have to agree with many other comments: the use of haskell eliminated it as a choice for me.

Why? Are you a Subversion contributor?

Re:Theory of patches

[IrvineHosting]

Wow, that actually sounds really cool! I just be happy if I could get my SourceSafe repository to stop corrupting.

Choose the development tool you prefer

[curne]

It seems to me that a LOT of people in these comments are remarking that David's choice of Haskell makes darcs a no-go. I would make this comment:

If someone told you to use <Tool X> for a project, you would say, "No way, <Tool Y> is more suitable for this job, and it's what I want to use." (substitute X and Y with whatever - C/Java/Perl/VB - you want).

I think David chose what he felt was the best tool for the job, taking the problem-to-solve and his own expertise into consideration. In the light of Paul Graham's insights I really think he should be applauded rather than criticised.

Here:

[warrax_666]

I think you may find this page interesting.

Major differences:

1. Darcs is must less strict: For example, it doesn't have a built-in concept of branches/versions (which is necessary in Arch because of the patch ordering/application constraints).
   
2. All working directories are repositories themselves. This can be very useful (for example, it makes it trivial to manage /etc using darcs), but also somewhat dangerous.
   
3. Interactive approval of every recorded diff chunk (change). This may not sound like a big deal, but if you have spurious changes in a tree which you'd rather not record(*) in a given changeset, interactive prompting makes it a a lot easier to achieve clean changesets which only touch one "aspect" of the source at a time.
   

(*) Such as typo fixes, comment fixes, etc. which you just happened to notice while fixing a particular bug.

Re:Here:

[boa13]

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.

Our experience CVS vs. DARCs

[ites]

We are looking at something to replace our ageing CVS system. We have large OSS projects, worked on by teams of 3-10 people. CVS is very good for what it does but we are feeling its limitations. The biggest problems are that forks are too delicate to use, so we don't use them, and that in order to work you need access to the central archive.

Darcs looked like the best choice. We converted and imported some of our archives. Then we tried checking them out. With CVS, 2-3 minutes. With darcs, 30 minutes.

Our conclusion: darcs is not scalable. Admittedly our code base is large and has a huge history, but in order to use darcs we would have had to break our projects into many small pieces, each with their own repository.

Darcs looks good. But it needs to be made much, much faster if it's to work with large projects.

Re:Our experience CVS vs. DARCs

[David Roundy]

Darcs get (equivalent to CVS checkout) is the single least efficient command in darcs. People keep telling me I need to fix this, since it's the first thing users see, but it's really not an important command to optimize (apart from first impressions issues). When run locally (to create a new branch) it's fast.

And comparing darcs get with cvs checkout really isn't fair, since darcs gives you a copy of the full history of the repository, a separate branch on which to record changes before committing them to the centralized repository, and the ability to browse the history offline.

If you want a fast get, just run optimize --checkpoint on the parent repository (assuming you've tagged recently--if not, then tag the current state first), and then use the --partial flag when running darcs get. It'll still give you more flexibility than a cvs checkout, and will be much faster.

If you're currently using CVS...

[Phil John]

...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:Mature RCS?

[David Roundy]

Actually, whether or not an RCS is self-hosting is a pretty useless test of the maturity of that RCS. It is incredibly easy to self-host an RCS, since the users are the developers. Darcs was self-hosting way back before I would even have considered suggesting that anyone else consider using it (as I'm sure was the case with Arch).

The hard part of writing an RCS is dealing with all those users who do things you never would have thought of, uncovering all sorts of interesting bugs.

Re:Mostly agreed, but

[David Roundy]

No, I'm afraid the footnote is dead on. When patches are commuted their content changes, although their meaning remains the same. This happens when people pull (or push) patches from one repository to another.

There is an idea, a repository of patch bundles, which could allow signed patches to be kept, at the cost of either duplication of information or inefficiency. It would "just need to be implemented." It would be a bit tedious, but is simple enough that it could be done (terribly inefficiently) using external scripts.

Re:Darcs vs Svn

[jeif1k]

You need to "learn Haskell and the theory of patches" to use darcs about as much as you need to learn C programming and diff algorithms in order to use Subversion, namely not at all.

Re:why not improve CVS?

[Alioth]

They have. It's called Subversion.
http://subversion.tigris.org/

Patches applied out of order - freedom or folly?

[Anonymous Coward]

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.

Distributed vs. centralized repositories

[Ian Bicking]

I played around with several source control systems a while back; I like Darcs, it was the easiest of the distributed systems to understand, with a concise and easy-to-understand command-line interface.

But in the end I think a centralized repository is right for many (most?) projects: Why Bitkeeper Isn't Right For Free Software (by Greg Hudson) was the most convincing argument to me.

Of course, you can simulate a centralized model with a distributed system (just don't use the distributed bits), but it seems like you are on your own at that point. Subversion is behind when you compare distributed features (of course), but when you compare the other features (usability, access via various method, programmatic access, etc), it's way ahead. As it would be; centralized systems are easier to think about, so they are easier to develop with and on top of.