I'm sure you've all seen David's
announcement: darcs 2.0.0 is out!
what's good
In short, darcs 2.0 is safer and faster.
Particularly, the dreaded exponential-time merge bug has now been largely resolved. Let me say it more carefully: while it may still be possible to run into exponential time merges, our improvements to conflict-handling should make it considerably less common. We hope that nobody ever runs into such a situation in practice.
Other key points are improved the hashed inventory and pristine cache which darcs more robust (you no longer have to worry about third party tools like Eclipse or Unison messing things up by mucking around with darcs internals), the ssh-connection mode which speeds up SSH-issues a lot and kills the typing-your-password-ten-million-times issue dead (at most you'll have to type it in twice).
what's bad
On the one hand, darcs 2.0.0 should be much smoother and faster for most users. On the other hand, people with large repositories (e.g. GHC-sized) might find certain operations to be somewhat slower. David does not (yet) have ideas on how to make things better for such users, and is even recommending them to switch to something else. If you've got a repository of darcs' size (over 5000 patches, 6 years, 131 contributors) or smaller, you should continue using darcs, because we still think it works better: we're still the only ones around to offer
deep cherry picking... something which we think would be hard to do without radically changing the way other VCSes work. If you would like to prove us wrong, please do so and we would be most grateful!
Also, taking advantage of darcs 2 will require you to upgrade your repository to the
darcs-2 format (see
darcs convert), which unfortunately, is not compatible with older versions of darcs. People with new repositories should definitely start using this format. People with old repositories should probably do so at the earliest convenient moment, although this means your users will have to upgrade. Please switch to the new format. It will make everybody's lives easier.
The final piece of bad news: we're going to have to shift to a lighter weight development model, something which puts less strain on David and the rest of the contributors. The consequences are that patches might get less review [one maintainer and not two], and that you'll be seeing less of David on the mailing lists. The good news in the bad news is that our lighter weight development model is now being supported by increased automation of the administrative stuff. For example, our bug tracker is now integrated with the darcs repository so that it automatically knows when a ticket has been resolved by a patch. This increased automation gives us extra rigour and more time to think about making darcs better. The only thing we need is more of us. If you want a place to hone your Haskell, Perl or C... or if you think you know a thing or two about user interfaces, please spend some time with us.
to sum up...
Have you been hesitating to try darcs out? Well, now is a good time to do so, as our killer bugs have been fixed as well as the kind of minor nuisances that get most of us. Or... are you looking for something to work on? Uncle David needs you!
[note: Thanks to David Roundy for comments on a draft of this post]
I'm sure you've all seen David's
announcement: darcs 2.0.0 is out!
what's good
In short, darcs 2.0 is safer and faster.
Particularly, the dreaded exponential-time merge bug has now been largely resolved. Let me say it more carefully: while it may still be possible to run into exponential time merges, our improvements to conflict-handling should make it considerably less common. We hope that nobody ever runs into such a situation in practice.
Other key points are improved the hashed inventory and pristine cache which darcs more robust (you no longer have to worry about third party tools like Eclipse or Unison messing things up by mucking around with darcs internals), the ssh-connection mode which speeds up SSH-issues a lot and kills the typing-your-password-ten-million-times issue dead (at most you'll have to type it in twice).
what's bad
On the one hand, darcs 2.0.0 should be much smoother and faster for most users. On the other hand, people with large repositories (e.g. GHC-sized) might find certain operations to be somewhat slower. David does not (yet) have ideas on how to make things better for such users, and is even recommending them to switch to something else. If you've got a repository of darcs' size (over 5000 patches, 6 years, 131 contributors) or smaller, you should continue using darcs, because we still think it works better: we're still the only ones around to offer
deep cherry picking... something which we think would be hard to do without radically changing the way other VCSes work. If you would like to prove us wrong, please do so and we would be most grateful!
Also, taking advantage of darcs 2 will require you to upgrade your repository to the
darcs-2 format (see
darcs convert), which unfortunately, is not compatible with older versions of darcs. People with new repositories should definitely start using this format. People with old repositories should probably do so at the earliest convenient moment, although this means your users will have to upgrade. Please switch to the new format. It will make everybody's lives easier.
The final piece of bad news: we're going to have to shift to a lighter weight development model, something which puts less strain on David and the rest of the contributors. The consequences are that patches might get less review [one maintainer and not two], and that you'll be seeing less of David on the mailing lists. The good news in the bad news is that our lighter weight development model is now being supported by increased automation of the administrative stuff. For example, our bug tracker is now integrated with the darcs repository so that it automatically knows when a ticket has been resolved by a patch. This increased automation gives us extra rigour and more time to think about making darcs better. The only thing we need is more of us. If you want a place to hone your Haskell, Perl or C... or if you think you know a thing or two about user interfaces, please spend some time with us.
to sum up...
Have you been hesitating to try darcs out? Well, now is a good time to do so, as our killer bugs have been fixed as well as the kind of minor nuisances that get most of us. Or... are you looking for something to work on? Uncle David needs you!
[note: Thanks to David Roundy for comments on a draft of this post]
darcs 2 at last!
7 comments:
What exactly is “deep cherry picking”? I can't seem to find any such reference to it on Google.
Deep cherry picking is a term I made up for darcs's ability to provide cherry picking in basically every revision control operation (for example, pulling a patch from another repository, undoing a patch, reverting only some of your uncommitted changes by not others). Maybe "pervasive cherry picking" would be a better way to say it, but I used the word "deep" to convey that it was really an integral part of how darcs works, everything that goes on in darcs, in other words, being a consequence of the one operation (patch commutation) that makes darcs darcs and offers us this kind of cherry picking ability.
Does that make any sense?
That is more understandable. Using the word “deep” kind of makes it seem like it's a semantics that has no equivalent in other SCMs, which made me wonder if it was something I had never heard of before. I like darcs, but this kind of cherry picking can be done without too much trouble in other SCMs as well.
Of course you probably know that git supports cherry-picking with git add -i (git cherry-pick is actually a different kind of operation). But also, since git allows for all kinds of history editing, you can cherry pick any other operation by checking out the revision and then cherry picking changes back in (or just using rebase to do it for you). For example, instead of cherry picking patches as they come in from another repo you pull patches from another repository and then edit them, or instead of doing a cherry pick undo just undo and then cherry pick changes back in. It's really not that complicated, it just isn't a default behavior. Example scenario: I want to pull a bunch of patches from another repo but I want to ignore some patches and selectively cherry pick from others.
git pull
git rebase -i HEAD{1}
# presented with a list of patches in a text editor. annotate them with edit/squash/etc, rearrange them, delete them, whatever. save, and git will reapply those patches in the manner you specified. if you marked anything to edit, it drops you back to shell, you cherry pick your changes (even to the point of turning one patch into many smaller patches), and then run git rebase --continue
This kind of process also gives you the opportunity to also test your code as your cherry pick if you wish.
I somehow missed the phrase “patch commutation” in your response. That, I agree, is the significant part, and no other SCM that I know of does it quite this way.
Thanks for the info! I was vaguely aware that other SCMs implement some form of cherry picking, and it is gratifying to see that the kind can be applied over all operations.
I also quite like the easy-breezy fashion you describe of being able to edit a list of patches in a text editor.
But yeah, the commutation does help.
Cool post; I'm quite excited darcs 2 is out now (the pre-releases seemed to move very quickly.) I've been looking for a haskell project I could work on with some other people, perhaps darcs would be a good fit considering it's quite crucial to the community, and needs help. Is there an IRC channel or mailing list I can get involved in to start off?
There is indeed! You'll want to have a look at the #darcs channel on irc.freenode.net as well as the darcs-devel list http://lists.osuosl.org/mailman/listinfo/darcs-devel
Post a Comment