Weekly Edition
Return to the Development page
| |||||||||||||
|
| |||||||||||||
Darcs 2.4 released
Version 2.4 of the Darcs revision control system is out. "The darcs team is proud to announce the immediate availability of darcs 2.4. darcs 2.4 contains many improvements and bugfixes compared to darcs 2.3.1. Highlights are the faster operation of record, revert and related commands, and the experimental interactive hunk editing." More information can be found in the release announcement.
(Log in to post comments)
Darcs is still worth a look Posted Feb 27, 2010 22:50 UTC (Sat) by stevenj (guest, #421) [Link] My feeling is that Darcs still has the nicest user interface of the modern distributed version-control systems. Partly because it doesn't store "versions", but rather lists of patches, and understands inter-patch dependencies, so selectively sharing ("cherry-picking") patches between branches is natural from the get-go. Partly because I think the command-set and user-interaction model was well thought-out. (Since I don't work on Linux-kernel scale projects, the performance has never been an issue for me, but I can understand how this might be an issue for some users. Also, as a friend of mine of mine commented to me, If a purely imperative task exists at all, it is version control. The choice of Haskell for this task makes me seriously wonder about the sanity of the author.) That being said, one of the most informative comparisons of Darcs, Git, Mercurial, and Bazaar was this comparison by the GHC developers when they considered switching away from Darcs for Haskell development, since they go through the commands and pros/cons in each environment for typical cherry-picking workflows. (I had thought they decided to switch to Git, but apparently they are still using Darcs.) It doesn't seem like the FLOSS world is moving to a One True DCVS any time soon, as there seems to be a critical mass of support for multiple alternatives. But I do hope that the different DCVS systems continue to look at one another from time to time, including the lesser-known ones, to see if they can learn from one another.
Darcs is still worth a look Posted Feb 28, 2010 0:43 UTC (Sun) by Cyberax (subscriber, #52523) [Link]
"It doesn't seem like the FLOSS world is moving to a One True DCVS any time
soon"
On the contrary, OpenSource world has moved to Two True DVCSes: Git and
Other DVCSes are a niche: bzr for Ubuntu-related projects, DARCS for
Darcs is still worth a look Posted Feb 28, 2010 7:30 UTC (Sun) by topher (guest, #2223) [Link]
I would partially agree. However, there are actually a pretty good number of
projects outside of Ubuntu using Bzr, so I would say the Open Source world has moved to three major (mainstream) DVCS's, Git, Mercurial, and Bzr. The rest are niche players. However, I still see interesting features showing up first in some of the niche project DVCS's that eventually make their way to the Big 3, so they still provide a lot of value.
Darcs is still worth a look Posted Feb 28, 2010 12:57 UTC (Sun) by maro (subscriber, #34315) [Link]
It would be nice if you would mention some examples to back up that "pretty
good number." I don't recall having seen it outside of Launchpad either.
Darcs is still worth a look Posted Feb 28, 2010 13:06 UTC (Sun) by quotemstr (subscriber, #45331) [Link]
GNU Emacs uses Bazaar.
Darcs is still worth a look Posted Feb 28, 2010 13:17 UTC (Sun) by maro (subscriber, #34315) [Link]
Thanks, that was one good example I was unaware of, not being an addict of
the Eighty Megs And Constantly Swapping operating syst^W^W text editor. :-)
Darcs is still worth a look Posted Mar 6, 2010 0:39 UTC (Sat) by bronson (subscriber, #4806) [Link]
You're swapping after 80 megs?? Either you're running old kit
or you need to increase your smackronym by two orders of magnitude... Eight gigs and constantly swapping?
Darcs is still worth a look Posted Feb 28, 2010 13:31 UTC (Sun) by maro (subscriber, #34315) [Link]
Upon further investigation, it seems the web interface[0] linked to from
their project page[1] is broken, and using the command from the same page gives this:
[mark@mjollnir src]$ bzr branch http://bzr.savannah.gnu.org/r/emacs
I wonder if their use of Bazaar-NG (bzr) is simply because they jumped too
[0] http://bzr.savannah.gnu.org/lh/emacs
Darcs is still worth a look Posted Feb 28, 2010 15:34 UTC (Sun) by TRS-80 (subscriber, #1804) [Link] I believe it's because bzr is a GNU project, so other GNU projects are encouraged to use it.
Darcs is still worth a look Posted Feb 28, 2010 15:54 UTC (Sun) by nix (subscriber, #2304) [Link]
I don't know of any others that *do*, while I could name many GNU projects
that use Git. There are good reasons and bad reasons to pick one VCS over another, and "the VCS is a GNU project" is surely a bad one.
Darcs is still worth a look Posted Feb 28, 2010 16:36 UTC (Sun) by TRS-80 (subscriber, #1804) [Link] gnu, gnome, and the fsf is a good summary of the technical leadership (or lack thereof) of GNU these days.
Darcs is still worth a look Posted Feb 28, 2010 22:00 UTC (Sun) by tzafrir (subscriber, #11501) [Link]
IIRC at the time it was considered, all three (bzr, git, hg) were considered goot enough. Thus being a GNU project was a tie-breaker for bzr.
Darcs is still worth a look Posted Feb 28, 2010 22:44 UTC (Sun) by foom (subscriber, #14868) [Link]
That raises the question: Why is Bzr "a GNU project". Does it even mean anything for something to
be a GNU project, other than RMS declared it such? (it doesn't seem to).
Darcs is still worth a look Posted Feb 28, 2010 23:47 UTC (Sun) by butlerm (subscriber, #13312) [Link]
Presumably it means that copyright has been assigned to (or originated with)
the Free Software Foundation.
Darcs is still worth a look Posted Mar 1, 2010 1:04 UTC (Mon) by foom (subscriber, #14868) [Link]
You might think -- but it doesn't mean that at all. On the contrary, contributions to Bzr require
copyright assignment to *Canonical*.
Darcs is still worth a look Posted Mar 6, 2010 0:47 UTC (Sat) by bronson (subscriber, #4806) [Link]
Really?? That's rather... disturbing.
Darcs is still worth a look Posted Mar 1, 2010 0:06 UTC (Mon) by anselm (subscriber, #2796) [Link] Bzr derives from and is the bona-fide successor to Tom Lord's arch/tla system, which used to be a GNU project (probably by virtue of being the only system of its kind around at the time whose author was amenable to the idea). Arch is way older than either git or Mercurial, and was one of the first, if not actually the first, freely available DVCS. In its time it was considered quite groundbreaking, but it enforced a number of strange and rigid conventions regarding repository setup and revision naming and its UI was very baroque, which scared off many prospective users and ultimately prevented it from gaining traction.
Darcs is still worth a look Posted Mar 6, 2010 1:05 UTC (Sat) by bronson (subscriber, #4806) [Link]
Oh, I had the misfortune to try to use Arch back in the day. Its bizarre
design constraints were only one of the many reasons it failed to gain traction.
It was slow and unreliable. Hope you don't mind repository surgery when
Arch was written against his personal oddball hacklib instead of a regular
And, of course, there were the temper tantrums and flakiness -- the
I only spent a week seriously wrestling with Arch but it felt like years...
Darcs is still worth a look Posted Mar 1, 2010 18:42 UTC (Mon) by zooko (subscriber, #2589) [Link]
The Tahoe-LAFS project uses darcs even though Tahoe-LAFS is written mostly in Python with some C and C++ for the CPU-intensive parts.
Darcs is still worth a look Posted Mar 1, 2010 0:45 UTC (Mon) by vonbrand (subscriber, #4458) [Link] Most criticisms levelled by the comparison against git have been resolved by now.
Darcs is still worth a look Posted Mar 4, 2010 15:43 UTC (Thu) by droundy (subscriber, #4559) [Link]
Alas, the most serious problems with darcs, however, are very far from being
resolved... and I suspect aren't even being looked at since I stopped working on darcs.
Darcs is still worth a look Posted Mar 5, 2010 12:31 UTC (Fri) by bpearlmutter (subscriber, #14693) [Link]
Whoa! If that were cryptographically signed, it would be about as
strong an indictment of the continued viability of darcs as a project as you could see.
So, um, could I ask you to elaborate: what are the fundamental
Darcs is still worth a look Posted Mar 8, 2010 4:02 UTC (Mon) by droundy (subscriber, #4559) [Link]
The main issue is that we still have no idea how to handle merges that
involve conflicts. The current code works fine, as long as you don't have a conflict with the resolution of a conflict, and often it works even then. But it's not that hard to cause it to fail completely, and then you're stuck merging a lot of changes without darcs' help. And alas, it's not an easy problem, so far as I can tell.
Darcs is still worth a look Posted Mar 1, 2010 5:13 UTC (Mon) by njs (guest, #40338) [Link]
> Also, as a friend of mine of mine commented to me, If a purely imperative task exists at all, it is version control.
I found this statement a bit striking; can you elaborate? Modern VCS is all about immutable/append-only data stores and tricky mathematical formalisms; at the conceptual level they're very functional. You don't mutate your source, you just produce a new immutable snapshot! (Well, ironically, darcs is the exception to this.)
I personally still prefer imperative languages for the task because they're much more transparent wrt speed and memory usage (which is also very important for modern VCSes), but it's not at all obvious to me that this is a natural or inevitable choice.
Darcs is still worth a look Posted Mar 1, 2010 18:17 UTC (Mon) by stevenj (guest, #421) [Link] Maybe the answer is that a purely imperative task doesn't exist. You're right that, once the problem of tracking versions of a mutable state has been transformed into the problem of determining relationships among a growing list of immutable states (whether snapshots or, in Darcs' case, patches), the problem begins to look more functional. (Although the VCS commands still interact mostly through side effects on the filesystem.)
Darcs 2.4 released Posted Mar 1, 2010 15:47 UTC (Mon) by xxiao (subscriber, #9631) [Link]
do we really need these many version control tools?
at work i use accurev and just hated it
this is why diversity is helpful Posted Mar 1, 2010 18:10 UTC (Mon) by stevenj (guest, #421) [Link] That's why we need this many version-control tools. If you have just one, it may suck and it may not be clear whether anything better is possible. Worse, it may suck and you may not even realize it because you've never seen anything better. Having a variety of alternatives exploring different possibilities helps the whole VCS ecosystem to evolve. And it seems there a critical mass of users large enough to keep even niche systems alive and flourishing (especially free ones, which can survive on many fewer users than a commercial system).
it would take a sea-change to get me back Posted Mar 2, 2010 4:02 UTC (Tue) by b7j0c (subscriber, #27559) [Link]
i was once a happy user of darcs for my personal work. i dropped it in favor of git. besides being fast and powerful, git also has the cultural zeitgeist. knowing git very well is now something you want to put on your resume...can the same be said for darcs? i'll keep darcs installed and keep cheering the team on...but the limited time slices i can dedicate to mastering a dvcs are just better spent on git at this point. for me to re-adopt darcs as my tool of choice would require a real game-changing development from the darcs world that would induce some kind of sea-change among developers. given the relative size of their hacker communities, i don't expect that to happen but i'm still rooting for darcs anyway.
it would take a sea-change to get me back Posted Mar 2, 2010 9:06 UTC (Tue) by quotemstr (subscriber, #45331) [Link] git also has the cultural zeitgeist. knowing git very well is now something you want to put on your resume...can the same be said for darcs?That's a very insightful comment. It's rather humbling to realize how many of our technological choices are completely arbitrary: popularity is self-reinforcing, and can eventually even drive technical excellence. A prominent early adopter, a mention in the technology media, personal contacts in certain areas (*cough* San Francisco *cough) can make a greater difference in a program's popularity than any degree of technical excellence. Or, your mousetrap has to be much better than something else to compensate for social inertia.
it would take a sea-change to get me back Posted Mar 4, 2010 4:53 UTC (Thu) by thedevil (subscriber, #32913) [Link]
"It's rather humbling"
Humbling? You must be a true gentleman; the word that comes to my mind is "infuriating".
it would take a sea-change to get me back Posted Mar 4, 2010 15:41 UTC (Thu) by droundy (subscriber, #4559) [Link]
I must disagree that git's win over darcs isn't purely arbitrary. It's way
better designed, and deserves to win. Darcs was a neat idea, but I never was able to figure out a sane way to deal with merging conflicting changes, which is never a problem in git.
it would take a sea-change to get me back Posted Mar 4, 2010 18:26 UTC (Thu) by djc (subscriber, #56880) [Link]
git's ui still sucks monkeyballs, though.
it would take a sea-change to get me back Posted Mar 4, 2010 20:40 UTC (Thu) by vonbrand (subscriber, #4458) [Link] Details? I know many git developers would love to make it more inuitive/easy to use. But that requires detailed criticism (i.e., UI bug reports).
it would take a sea-change to get me back Posted Mar 5, 2010 0:36 UTC (Fri) by nix (subscriber, #2304) [Link]
Well, the inconsistent use of --index versus --cache versus --staging in
many git commands is horrendously confusing (in some commands --index does what --cache does in others, and then you have commands which have *both* of them). Every single person I have ever shown git to has complained about this, but Junio has already ruled out fixing it because it would annoy existing users too much. Sigh.
it would take a sea-change to get me back Posted Mar 12, 2010 17:20 UTC (Fri) by astrophoenix (guest, #13528) [Link]
I'll bite. I can understand the concept of having a local branch that
tracks a remote branch, but the syntax used to say "hey, fetch that remote branch into the local tracking branch" makes no sense at all to me. I've stared at it, and read about it, and decided I would just have to memorize it, screw it up, memorize the special case I screwed up, etc, etc, until I stop hitting new cases.
the syntax for specifying remote branches and which local branch to put
it would take a sea-change to get me back Posted Mar 12, 2010 21:06 UTC (Fri) by bronson (subscriber, #4806) [Link]
You'll be happy to hear that all that rubbish is obsolete. As of Git 1.6.high (5 or 6 or something), if you check out a branch that exists remotely, but doesn't have a local tracking branch, git will make the tracking branch for you.
bronson@lyra:~/executor$ git checkout rails_2_3
I agree, that git checkout -b incantation was horrid.
it would take a sea-change to get me back Posted Mar 5, 2010 12:39 UTC (Fri) by bpearlmutter (subscriber, #14693) [Link]
Git resolves merging conflicting patches by requiring a human being
to do the resolution manually. Practical, but certainly not elegant. Darcs could be pretty easily tweaked to do the same, couldn't it? (New "resolved conflict" patch type, depends on the patches it merges, attain closure by constructing graph and requiring new nodes be created to resolve any ambiguity from overlaps.)
There's even an algebra (incomplete lattice etc) lurking in there.
it would take a sea-change to get me back Posted Mar 16, 2010 16:00 UTC (Tue) by liljencrantz (subscriber, #28458) [Link]
If darcs is technically inferior to git in ways that matter, it should of course not be used.
But it's a shame, the UI is so much better than other systems. I love that darcs doesn't have branches. Branches offer a subset of the features offered by directories in file systems, so why not let the file system handle it? Use cd to "move" to a different branch. Use cp to "create" a new branch. Use rm to "drop" a branch. So much more powerful as well as more familiar. In git, you sometimes seem to create your own branch when a pull fails, or something. I'm no Git expert but I've found myself in a situation where I find myself on an unnamed branch and I sure as hell haven't created it myself. I probably did something wrong, bit the plain truth is that I didn't have these problems in Darcs and I do have them in Git.
I love the darcs commit ui, where you can cherry pick edits interactively, and move back/forward in the list of edits, etc..
Overall, the UI of darcs is just so much better and better thought out than any other dvcs program I've used, and unfortunately, it doesn't seem like git or any other version control system is adopting the darcs features I love the most.
it would take a sea-change to get me back Posted Mar 17, 2010 14:15 UTC (Wed) by sergey (guest, #31763) [Link]
Take another look at Subversion: cp does create a new branch, or a new local working copy
if that's file system cp and not 'svn cp'. The thing is, having multiple working copies, one for each branch, takes up space and makes my dev tools show me five seemengly identical 'myproject' documents in the Recent list :-). If I try to use branches in Subversion in a single working copy, I find myself fighting with a very fragile 'svn switch' command that killed my working copies enough times to stop bothering for all but the cleanest cases. The analogy with file system seemed perfect when Subversion was started, but I no longer think so after Git and Hg came along.
it would take a sea-change to get me back Posted Mar 18, 2010 23:02 UTC (Thu) by nix (subscriber, #2304) [Link] Branches offer a subset of the features offered by directories in file systemsPeople keep saying that, only they don't. If I switch from one branch to another in git with uncommitted changes, it carries them along, so they're now uncommitted changes in the other branch: how could this be implemented with directories? Branches form a graph over time, splitting and merging: how can this be implemented with directories? Directories form a tree in space, not a DAG in time. I have trouble seeing any similarities between branches and directories at all. What similarities do you see?
|
|
||||||||||||