Hi all, The darcs team would like to announce the immediate availability of darcs 2.4 release candidate 2. darcs 2.4 will contain 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. This beta is your chance to test-drive these improvements and make darcs even better. Compared to darcs 2.4 beta 3, the performance of "darcs check" and "darcs repair" has been brought up to the level of darcs 2.3.1.` The easiest way to install darcs is using the Haskell Platform [1]. If you have installed the Haskell Platform or cabal-install, you can install this beta release by doing: $ cabal update $ cabal install --reinstall darcs-beta Alternatively, you can download the tarball from http://darcs.net/releases/darcs-beta-2.3.99.2.tar.gz , and build it by hand as explained in the README file. Interactive hunk editing ------------------------ To try out interactive hunk editing, press 'e' when you are prompted with a hunk patch by 'darcs record'. You will then be shown an editor screen in which you can edit the state you want to record between the last two ruler lines. You can find more information about the hunk editing feature on http://wiki.darcs.net/HunkEditor . Reporting bugs -------------- If you have an issue with darcs 2.4 release candidate 2, you can report it via the web on http://bugs.darcs.net/ . You can also report bugs by email to bugs@darcs.net. What's New ---------- A list of important changes since 2.3.1 is as follows (please let me know if there's something you miss!): * Use fast index-based diffing everywhere (Petr) * Interactive patch splitting (Ganesh) * An 'optimize --upgrade' option to convert to hashed format in-place (Eric) * Hunk matching (Kamil Dworakowski, tat.wright) * Progress reporting is no longer deceptive (Roman) * A 'remove --recursive' option to remove a directory tree from revision control (Roman) * 'show files' accepts arguments to show a subset of tracked files (Luca) * A '--remote-darcs' flag for pushing to a host where darcs isn't called darcs * Many miscellaneous Windows improvements (Salvatore, Petr and others) * 'darcs send' now mentions the repository name in the email body (Joachim) * Handle files with boring names in the repository correctly (Petr) * Fix parsing of .authorspellings file (Tomáš) * Various sane new command-line option names (Florent) * Remove the '--checkpoint' option (Petr) * Use external libraries for all UTF-8 handling (Eric, Reinier) * Use the Haskell zlib package exclusively for compression (Petr) A list of issues resolved since 2.3.1: * 183: do not sort changes --summary output * 223: add --remote-darcs flag to specify name of remote darcs executable * 291: provide (basic) interactive patch splitting * 540: darcs remove --recursive * 835: 'show files' with arguments * 1122: get --complete should not offer to create a lazy repository * 1216: list Match section in ToC * 1224: refuse to convert a repo that's already in darcs-2 format * 1300: logfile deleted on unsucessful record * 1308: push should warn about unpulled patches before patch-selection * 1336: sane error message on --last "" (empty string to numbers parser) * 1362: mention repo name in mail send body * 1377: getProgname for local darcs instances * 1392: use parsec to parse .authorspelling * 1424: darcs get wrongly reports "using lazy repository" if you ctrl-c old-fashioned get * 1447: different online help for send/apply --cc * 1488: fix crash in whatsnew when invoked in non-tracked directory * 1548: show contents requires at least one argument * 1554: allow opt-out of -threaded (fix ARM builds) * 1563: official thank-you page * 1578: don't put newlines in the Haskeline prompts * 1583: on darcs get, suggest upgrading source repo to hashed * 1584: provide optimize --upgrade command * 1588: add --skip-conflicts option * 1594: define PREPROCHTML in makefile * 1620: make amend leave a log file when it should * 1636: hunk matching * 1643: optimize --upgrade should do optimize * 1652: suggest cabal update before cabal install * 1659: make restrictBoring take recorded state into account * 1677: create correct hashes for empty directories in index * 1681: preserve log on amend failure * 1709: fix short version of progress reporting * 1712: correctly report number of patches to pull * 1720: fix cabal haddock problem * 1731: fix performance regression in check and repair * 1741: fix --list-options when option has multiple names Kind Regards, the darcs release manager, Reinier Lamers [1]: You can download the Haskell platform from http://hackage.haskell.org/platform/
Hi All This rc release is still notably slower on some operations than older releases. My test case is a large project named RTEMS (a real-time OS), that we wish to import into darcs (at work) to better track our own additions and modifications. To repeat, download two adjacent releases, e.g. wget http://www.rtems.org/ftp/pub/rtems/4.9.0/rtems-4.8.1.tar.bz2 wget http://www.rtems.org/ftp/pub/rtems/4.9.0/rtems-4.9.0.tar.bz2 unpack, initialize darcs and record in the 4.8.1 tree, then copy _darcs to the 4.9.0 version and try to record -l or whatsnew -l. I have two darcs versions installed: ben@sarun[1]: .../rtems/rtems-4.9.0 > /usr/local/bin/darcs --version 2.2.1 (release) ben@sarun[1]: .../rtems/rtems-4.9.0 > darcs --version 2.3.99.2 (release candidate 2) ben@sarun[1]: .../rtems/rtems-4.9.0 > time /usr/local/bin/darcs whatsnew -l # ...long output elided... /usr/local/bin/darcs whatsnew -l 381,45s user 6,34s system 92% cpu 7:00,90 total whereas with 2.3.99.2 it goes ben@sarun[1]: .../rtems/rtems-4.9.0 > time darcs whatsnew -l Well, it is still running after 18 minutes! Top reports something like PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 5702 ben 20 0 1112m 933m 3628 R 92.2 28.3 18:26.08 darcs One point to notice is that 2.3.99.2 has not yet reported any progress, whereas 2.2.1 almost immediately starts reporting something about pristine trees followed by the usual number/number stuff; and the numbers continually rise. The situation with record is similar. I admit that the huge RTEMS tree with over 7000 changes between the two releases is challenging. However, earlier releases can do it (though it takes long, much longer than with, say, mercurial). At work I tried it with 2.3.1 (on a fast 4 processor machine) and it recorded all the changes in about one minute. I think this regression should be fixed before 2.4 is released. Cheers Ben Reinier Lamers wrote:
The darcs team would like to announce the immediate availability of darcs 2.4 release candidate 2. darcs 2.4 will contain 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. This beta is your chance to test-drive these improvements and make darcs even better.
Ben Franksen wrote:
ben@sarun[1]: .../rtems/rtems-4.9.0 > time darcs whatsnew -l
Well, it is still running after 18 minutes! Top reports something like
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 5702 ben 20 0 1112m 933m 3628 R 92.2 28.3 18:26.08 darcs
FYI, I finally killed it: ben@sarun[1]: .../rtems/rtems-4.9.0 > time darcs whatsnew -l withSignalsHandled: Interrupted! darcs whatsnew -l 2307,92s user 17,33s system 88% cpu 43:49,89 total Cheers Ben
Ben Franksen wrote:
ben@sarun[1]: .../rtems/rtems-4.9.0 > /usr/local/bin/darcs --version 2.2.1 (release) ben@sarun[1]: .../rtems/rtems-4.9.0 > time /usr/local/bin/darcs whatsnew -l # ...long output elided... /usr/local/bin/darcs whatsnew -l 381,45s user 6,34s system 92% cpu 7:00,90 total
Just installed 2.3.1 and tried the same: ben@sarun[1]: .../rtems/rtems-4.9.0 > darcs --version 2.3.1 (release) ben@sarun[1]: .../rtems/rtems-4.9.0 > time darcs whatsnew -l # ...long output elided... darcs whatsnew -l 239,41s user 4,74s system 85% cpu 4:44,33 total Note the differences in user and system time. Darcs-2.3.1 is indeed faster than 2.2.1 (but you already knew that). Cheers Ben
And here are the numbers for record -lam: ben@sarun[1]: .../rtems/rtems-4.9.0 > darcs --version 2.3.1 (release) ben@sarun[1]: .../rtems/rtems-4.9.0 > time darcs record -lam'import release 4.9.0' Finished recording patch 'import release 4.9.0' darcs record -lam'import release 4.9.0' 143,33s user 6,57s system 69% cpu 3:34,22 total vs. ben@sarun[1]: .../rtems/rtems-4.9.0 > /home/ben/.cabal/bin/darcs --version 2.3.99.2 (release candidate 2) ben@sarun[1]: .../rtems/rtems-4.9.0 > time /home/ben/.cabal/bin/darcs record -lam'import release 4.9.0' withSignalsHandled: Interrupted! /home/ben/.cabal/bin/darcs record -lam'import release 4.9.0' 1549,45s user 11,81s system 94% cpu 27:40,50 total (killed by me) Re Petr Rockai: No this isn't critical for us at the moment, so I don't need a workaround. I still think regressions of such a scale should be considered a bug. Cheers Ben
Hi,
Ben Franksen
This rc release is still notably slower on some operations than older releases. My test case is a large project named RTEMS (a real-time OS), that we wish to import into darcs (at work) to better track our own additions and modifications.
To repeat, download two adjacent releases, e.g.
wget http://www.rtems.org/ftp/pub/rtems/4.9.0/rtems-4.8.1.tar.bz2 wget http://www.rtems.org/ftp/pub/rtems/4.9.0/rtems-4.9.0.tar.bz2
unpack, initialize darcs and record in the 4.8.1 tree, then copy _darcs to the 4.9.0 version and try to record -l or whatsnew -l. [snip]
I am not sure about 2.4, but if this is an important usecase for you, I might have some good news. I have cobbled together a simple replacement for the current "summary" code in darcs whatsnew (right now it does not handle moves, but that should be relatively easy to add that without much performance impact). The code in this form never looks *into* files, it just looks at their hashes (which are cached in the index), and for the look-for-adds case, for their presence in the "unrecorded" state (i.e. if they'd be there without look-for-adds). In your rtems example, I get following: with totally cold cache and no index (rm -f _darcs/index ; echo 3 > /proc/sys/vm/drop_caches) about 12 seconds, hot cache & up-to-date index, less than one second. The reported list looks vaguely correct. Unfortunately, this is not going to help you for record -lam "new release" -- which will still need to construct the whole huge patch in memory (and fail). I will eventually look into that problem as well, but this is likely going to be much harder.
I think this regression should be fixed before 2.4 is released.
Either way, I am not sure how serious this is wrt 2.4. I guess we could manage a rewrite of the summary code, but that would probably require another full beta cycle. I would be willing to list this under known issues, advising people that really need this to stick with 2.3.1 for now and upgrade to 2.5 which will hopefully improve matters in this respect (also for rec -lam). Yours, Petr.
Ben Franksen wrote:
The situation with record is similar.
I admit that the huge RTEMS tree with over 7000 changes between the two releases is challenging. However, earlier releases can do it (though it takes long, much longer than with, say, mercurial).
Just for comparison, here are the numbers for mercurial: ben@sarun[1]: .../rtems/rtems-4.9.0 > hg --version Mercurial Distributed SCM (version 0.9.5) ben@sarun[1]: .../rtems/rtems-4.9.0 > hg log changeset: 0:8b3cbc67b25f user: ben@sarun date: Sun Feb 21 21:29:10 2010 +0100 summary: import release 4.8.1 ben@sarun[1]: .../rtems/rtems-4.9.0 > time (hg addremove && hg commit -m'import release 4.9.0') # ... long output elided ... (; hg addremove && hg commit -m'import release 4.9.0'; ) 9,20s user 1,15s system 92% cpu 11,181 total Cheers Ben
participants (3)
-
Ben Franksen -
Petr Rockai -
Reinier Lamers