[Haskell-cafe] Re: darcs 2.4 release candidate 2
Hi, Ben Franksen benjamin.frank...@bessy.de writes: 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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Anyone up for Google SoC 2010?
Hello! [snip] We're particularly interested in three things: (i) making Darcs faster (ii) building nice GUI tools and (iii) working seamlessly with SVN/Git repositories [snip] Both of these roles are called mentor in the Google system. Putting together a good team of mentors before applying as an organisation is helpful towards us being accepted into the programme. I'll volunteer as a mentor if it helps. Darcs users: if you have a few spare hours this summer, this would be a most excellent way to participate. Stick your hand up :-) I am volunteering as a mentor as well. My schedule is too crammed to go the student way this year (and, probably, any future year). I am particularly interested in mentoring (i) kinds of projects mentioned by Eric above, but other will do, depending on what prospective students come up with. Yours, Petr. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Darcs and NFS Resolution
trentb...@gmail.com (Trent W. Buck) writes: I'm also puzzled as to why this works -- surely mv(1) assumes POSIX semantics, too? I would be interested in seeing the exact error transcript, preferably as an issue on bugs.d.n. I'm not sure the problem has been diagnosed correctly. Well, not really: mv will try harder than just calling rename(2). E.g. mv also works across mount points, where it'll go as far as doing a copy and unlink. I definitely think this SHOULD NOT be enabled by default, unless you're going to ONLY enable it in the specific scenario of CIFS on Linux. Well, we can always catch the rename(2) error and try unlinking and renaming again (carefully, unlike current Workaround's renameFile which just does that on any error). Yours, Petr. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: ANN: darcs 2.3.0
Salvatore Insalaco kirb...@gmail.com writes: Great! Just a little note: MSYS isn't required to install Darcs with cabal on Windows, just to develop or run tests. Oh, good to know. I had no idea you could use cmd.exe to run cabal and darcs and that it would work. Yours, Petr. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: darcs 2.3.0
Hello!
I'd like to announce immediate availability of a new stable release of darcs,
2.3.0. There is a number of improvements and bugfixes over the previous stable
release, 2.2. Moreover, work has been done to improve performance of darcs
whatsnew for large repositories.
As in the past, there are two source tarballs available. As of this release,
the cabal-based build is preferred, and the autoconf build is deprecated. You
can obtain the source tarballs at these addresses:
* http://repos.mornfall.net/darcs/darcs-2.3.0.tar.gz
* http://repos.mornfall.net/darcs/darcs-2.3.0_autoconf.tar.gz
The build instructions are available in the enclosed README file in those
tarballs.
Moreover, if you have cabal-install available, you can install latest stable
release of darcs by issuing the following commands (no tarballs needed):
$ cabal update
$ cabal install darcs
This should give you a darcs binary in `~/.cabal/bin` -- you should probably
add this to your PATH. More detailed instructions for installing on Windows are
available near the end of this announcement.
What's New
--
This is a summary of important changes since the last stable release (2.2):
* Lots and lots of documentation changes (Trent).
* Haskeline improvements (Judah).
* Cabal as default buildsystem (many contributors).
* Fixes in darcs check/repair memory usage (Bertram, David).
* Performance improvement in subtree record (Reinier).
* New option: --summary --xml (Florian Gilcher).
* New option: changes --max-count (Eric and Petr).
* Fix changes --only-to-files for renames (Dmitry).
* Performance fix in darcs changes (Benedikt).
* Hardlinks on NTFS (Salvatore).
* Coalesce more changes when creating rollbacks (David).
* New unit test runner (Reinier).
* Inclusion of darcs-shell in contrib (László, Trent).
* Author name/address canonisation: .authorspellings (Simon).
* Working directory index and substantial darcs wh optimisation (Petr).
* New command: darcs show index (Petr).
* Gzip CRC check and repair feature (Ganesh).
A number of issues has been resolved since 2.2 as well. See
http://bugs.darcs.net/issueN for details on bug number N.
* 948 darcsman (Trent)
* 1206 countable nouns (Trent)
* 1285 cabal test v. cabal clean (Trent)
* 1302 use resolved, not resolved-in-unstable (Trent)
* 1235 obliterate --summary (Rob)
* 1270 no MOTD for --xml-output (Lele)
* 1311 cover more timezones (Dave)
* 1292 re-encoding haskeline input (Judah)
* 1313 clickable ToC and refs in PDF manual Trent)
* 1310 create merged \darcsCommand{add} (Trent)
* 1333 better cannot push to current repository warning (Petr)
* 1347 (autoconf) check for unsafeMMapFile if mmap use enabled (Dave)
* 1361 specify required includes for curl in cabal file (Reinier)
* 1379 remove libwww support (Trent)
* 1366 remove unreachable code for direct ncurses use (Trent)
* 1271 do not install two copies of darcs.pdf (Trent)
* 1358 encode non-ASCII characters in mail headers (Reinier)
* 1393 swap darcs mv and darcs move (Trent)
* 1405 improve discoverability of global author file (Trent)
* 1402 don't phone home about bugs (Trent)
* 1301 remove obsolete zsh completion scripts (Trent)
* 1162 makeAbsolute is now a total function (Ben F)
* 1269 setpref predist - exitcode ignored bug (Ben M)
* 1415 --edit-long-comment, not --edit-description, in help (Trent)
* 1413 remove duplicate documentation (Trent)
* 1423 complain about empty add/remove (Trent)
* 1437 Implement darcs changes --max-count (Eric)
* 1430 lazy pattern matching in (-:-) from Changes command module (Dmitry)
* 1434 refactor example test (Trent)
* 1432 refer to %APPDATA%, not %USERPROFILE% (Trent)
* 1186 give a chance to abort if user did not edit description file (Dmitry)
* 1446 make amend-record -m foo replace only the patch name (Dmitry)
* 1435 default to get --hashed from a darcs-1.0 source (Trent)
* 1312 update and reduce build notes (Trent)
* 1351 fix repository path handling on Windows (Salvatore)
* 1173 support hard links on NTFS (Salvatore)
* 1248 support compressed inventories for darcs-1 repos (Ganesh)
* 1455 implement darcs help environment (Trent)
The question of GHC 6.8
---
Using GHC 6.10.3 or newer is *strongly recommended*. You may compile darcs with
GHC 6.8, but there are several caveats. If you are using 6.8.2 or older, please
disable mmap support (pass -f-mmap to cabal install or runghc Setup
configure). Note that the GHC 6.8.2 that ships with Debian Lenny is not
affected and it should be safe to keep mmap enabled. It is also recommended to
disable use of Hackage zlib when compiling with GHC 6.8.2 (including the Debian
Lenny version): pass -f-zlib to cabal. When using zlib, we have seen occasional
crashes with error messages like openBinaryFile: file locked -- this is a
known GHC 6.8.2 bug (and is fixed in GHC 6.8.3). Last, if you are using a
64-bit system, darcs may hang when you exit a pager when compiled with GHC
older
[Haskell-cafe] Re: cheap in-repo local branches (just needs implementation)
Hi, Grant Husbands darcsus...@grant.x43.net writes: 1. When you unpull old patches or reorder patches, Darcs alters existing patch files. This will break other branches that share the same files. Not true, since the filenames are fully determined by the file content. Hashed repositories will just create a new file for the modified patch. 2. Similarly, when you pull patches in different contexts, you end up with slightly-different patches with the same name. Same as above. 3. With enough unpulling on one branch, you probably break the root for another branch, by removing the shared inventory behind the head. This can be addressed by a GC policy. It's probably not feasible with current darcs, but keeping around root pointers to inventories is not much different from keeping extra roots for pristine. 4. Pushing and pulling between branches would be very hard to implement without heavy Darcs involvement. The method in the proposal will not work, as Darcs in either branch can't necessarily understand the context produced by the other branch. I'm not sure I follow your argument here. The proposed thing is the exact mechanism behind darcs push -- grab context of remote repository, commute patches you have to a common point and create a bundle, then use apply on that bundle... 5. Updating the working copy correctly for many branch operations entails knowing how to handle all of the darcs patches that are different between the branches. Even if you force the user to have no working copy changes, what about the unversioned extra files, especially in renamed folders? The switch problem wouldn't be any easier whether implemented inside or outside of darcs. This basically entails unapplying patches up to a common point and then applying missing ones. This may or may not work, depending on how much changed the working copy is. I presume we would abort without doing any changes may this break. 6. As noted in the proposal, it's not known how to make it play nicely with lazy fetching. I don't expect any problems here. I also don't see the original note? 7. The branch-knowledge synchronisation requires almost as much knowledge about how to handle remote Darcs repos as Darcs has. This is likely true. Yours, Petr. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: cheap in-repo local branches (just needs implementation)
Grant Husbands darcsus...@grant.x43.net writes: The original note that I should have quoted was from Max Battcher: : Additionally, there would be other useful management tools : (``darcs-branch list``, ``darcs-branch remove`` (or unfreeze)). I think : that these four commands could be done with no darcs interaction at all : (unless the branch being switched to has an incomplete/lazy pristine). Ah, OK. This is mistake on Max's part, since there's no such thing as incomplete/lazy pristine. I.e. this is a non-issue. Overall, I'd say this just feeds back into my original point, though; I fully expected that many points could be answered, and I think I can raise more, given a bit of thought. (I won't unless I'm asked to, though, as I'm trying to raise a useful point, not trying to wield pedantry to kill a project.) Well, the problem with that point is that maybe half of your points were trivially untrue, which sort of puts a dent into the argument itself. :) However, take even just the above into account and things are now more complicated. We're no longer simply switching a pristine and an inventory here and there, we're applying and unapplying patches for the working copy (which is non-trivial if you want to get the contexts correct), and rolling back on failure (something even Darcs has historically had trouble with). We're extending the added GC roots to include the full inventory chain (and whatever else comes up). We're doing something interesting with a new kind of context to make patch migration between branches work. I think it will become at least as much work as it would take to implement the right mechanisms in Darcs itself. No-one says it is going to be less or more work to do this within or outside of darcs. No doubt, some darcslib usage is quite likely (for patch application and unapplication, eg.). However, it is still relatively manageable, and in a limited form also relatively easy (but that's true of almost anything, the 80/20 rule). There's also the strong possibility that the system would get mostly implemented, with a few gotchas here and there and a few incomplete features, and then there'd less impetus for writing a good, integral branching system. You are probably overdoing the integral part of the equation, given that the only difference is administrative. You can import parts of darcs from outside of darcs just fine, these days. Anyway, the 80/20 problem is equivalently applicable to in-darcs as it is to out-of-darcs implementation. Yours, Petr. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: darcs 2.3 beta 4
Hi again! We have decided to delay the release cycle slightly for 2.3 and release another beta. The primary reason for this is our Windows support -- I would like to invite all Windows users to install darcs-beta and give it a ride. If you have a working cabal-install, all you need to do is run: $ cabal update $ cabal install darcs-beta (this works on all platforms; you may need to use -f-curl, if you don't have the cURL headers available -- this is often the case on Windows). If you do not have cabal-install, please follow the instructions near the end of this message, Installing on Windows. In addition to using cabal-install, you can also download a tarball from http://repos.mornfall.net/darcs/darcs-2.2.98.4.tar.gz and build manually (see the build instructions in README inside the tarball). Feedback To make the darcs 2.3 release a good one, we still need testing feedback: please drop a note to darcs-users@ if you have installed darcs-beta, or failed to install it. If you run into any bugs, we need to know about them. Thanks! The question of GHC 6.8 --- Using GHC 6.10.3 or newer is *strongly recommended*. You may compile darcs with GHC 6.8, but there are several caveats. If you are using 6.8.2 or older, please disable mmap support (pass -f-mmap to cabal install or runghc Setup configure below). Note that the GHC 6.8.2 that ships with Debian Lenny is not affected and it should be safe to keep mmap enabled. It is also recommended to disable use of Hackage zlib when compiling with GHC 6.8.2 (including the Debian Lenny version): pass -f-zlib to cabal. When using zlib, we have seen occasional crashes with error messages like openBinaryFile: file locked -- this is a known GHC 6.8.2 bug (and is fixed in GHC 6.8.3). Last, if you are using a 64-bit system, darcs may hang when you exit a pager when compiled with GHC older than 6.10.3. Although this is harmless, it is quite inconvenient. Overall, the status of GHC 6.8 is semi-supported: for many cases, things will work just fine, especially if you take a little extra caution with compilation flags. Installing on Windows - To install darcs on Windows systems from scratch, please download the Haskell Platform and MSYS: * http://hackage.haskell.org/platform/2009.2.0.1/HaskellPlatform-2009.2.0.1-setup.exe * http://sourceforge.net/projects/mingw/files/MSYS+Base+System/MSYS-1.0.11-rc-1.exe/download After installing both, you should have an MSYS icon: run MSYS and in the terminal window type: $ cabal update $ cabal install darcs-beta -f-curl This should download, compile and install all required dependencies and darcs-beta itself. The resulting darcs executable will be placed into the Haskell Platform executables folder, and should be accessible from the MSYS shell (just type darcs --version to check). Yours, Petr. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: darcs 2.3 beta 2
Hello! Two weeks passed and it is about time to release darcs 2.3 beta 2 (it's already a day late, sorry about that). As with beta 1, there is only a single installation package for this release of darcs: cabalised source. (Please note that the final version with also come with the legacy autoconf-based buildsystem, for the last time.) You can either download a tarball from http://repos.mornfall.net/darcs/darcs-2.2.98.2.tar.gz and build manually (see the build instructions in README inside the tarball), or, alternatively, you can use cabal-install to obtain a copy (the beta release is now available on Hackage): $ cabal update $ cabal install darcs-beta This, if successful, will give you a darcs binary in `~/.cabal/bin` -- you should probably add that to your PATH. What's new since beta 1 --- There are basically two relatively intrusive changes since beta 1. First, I have added index upgrade functionality to hashed-storage and this is now used by darcs, so that any bad or incompatible indexes are recreated transparently by darcs. Moreover, the index format is now architecture-independent, meaning that repositories shared across multiple architectures should not suffer from excessive index rebuilding. Second, Ganesh has done further work on his gzip CRC correction code. There is a very slight risk of regressions, so if you have around any repositories with broken CRCs in them, please test this functionality. Moreover, there is now an option to limit the repair to current repository, avoiding changes in related branches or caches. Trent, Thorkil and Eric have done cleanup work and a number of minor fixes for this release, improving overall quality and polish. One bug in the new indexing code has been found and reported by Eric and Guillaume independently, and is fixed in hashed-storage 0.3.4 (which required by this beta). You can track the release plan and progress at our wiki: http://wiki.darcs.net/development. The question of GHC 6.8 --- Using GHC 6.10.3 or newer is *strongly recommended*. You may compile darcs with GHC 6.8, but there are several caveats. If you are using 6.8.2 or older, please disable mmap support (pass -f-mmap to cabal install or runghc Setup configure below). Note that the GHC 6.8.2 that ships with Debian Lenny is not affected and it should be safe to keep mmap enabled. It is also recommended to disable use of Hackage zlib when compiling with GHC 6.8.2 (including the Debian Lenny version): pass -f-zlib to cabal. When using zlib, we have seen occasional crashes with error messages like openBinaryFile: file locked -- this is a known GHC 6.8.2 bug (and is fixed in GHC 6.8.3). Last, if you are using a 64-bit system, darcs may hang when you exit a pager when compiled with GHC older than 6.10.3. Although this is harmless, it is quite inconvenient. Overall, the status of GHC 6.8 is semi-supported: for many cases, things will work just fine, especially if you take a little extra caution with compilation flags. Yours, Petr. -- Petr Ročkai | http://web.mornfall.net A physicist is an atom's way of knowing about atoms. (George Wald) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: darcs 2.3 beta 1
Hi!
I'd like to announce immediate availability of a first beta release of darcs
2.3. There is a number of improvements and bugfixes over the last stable
release (2.2). Moreover, work has been done on performance of darcs whatsnew
for large repositories. This has also introduced a slight risk of regressions,
but please note that all of the disruptive changes are in read-only code
paths: the new code will never touch your repository, so it is unable to cause
permanent harm. The worst that could happen is that you get no or bad diff from
darcs whatsnew. (This is also a reason why we need your testing!)
There is only a single installation package for this release of darcs:
cabalised source. (Please note that the final version with also come with the
legacy autoconf-based buildsystem, for the last time.)
You can either download a tarball from
http://repos.mornfall.net/darcs/darcs-2.2.98.1.tar.gz and build manually (see
the build instructions in README inside the tarball), or, alternatively, you
can use cabal-install to obtain a copy (the beta release is now available on
Hackage):
$ cabal update
$ cabal install darcs-beta
This should give you a darcs binary in `~/.cabal/bin` -- you should probably
add that to your PATH.
(Note: The package name on Hackage is different, since people installing darcs
from Hackage are expecting a stable version. The name change means that you
cannot use the Hackage version to build other packages that depend on the darcs
library: you either need the tarball for this, or you can use the stable
version from Hackage.)
There is a quick (possibly incomplete) list of important changes:
* lots and lots of documentation changes (Trent)
* haskeline improvements (Judah)
* cabal as default buildsystem (many contributors)
* fixes in darcs check/repair memory usage (Bertram, David)
* performance improvement in subtree record (Reinier)
* --summary --xml (Florian Gilcher)
* changes --max-count (Eric and myself)
* fix changes --only-to-files for renames (Dmitry)
* performance fix in darcs changes (Benedikt)
* hardlinks on NTFS (Salvatore)
* coalesce more changes when creating rollbacks (David)
* new unit test runner (Reinier)
* darcs-shell in contrib (László, Trent)
* .authorspellings (Simon) -- I find this to be controversial though
* working directory index and substantial darcs wh optimisation (myself)
* gzip CRC checking and repair feature (Ganesh)
and there is a number of issues that has been resolved since 2.2:
* 948: darcsman (Trent)
* 1206: countable nouns (Trent)
* 1285: cabal test v. cabal clean (Trent)
* 1302: use resolved, not resolved-in-unstable (Trent)
* 1235: obliterate --summary (Rob)
* 1270: no MOTD for --xml-output (Lele)
* 1311: cover more timezones (Dave)
* 1292: re-encoding haskeline input (Judah)
* 1313: clickable ToC and refs in PDF manual Trent)
* 1310: create merged \darcsCommand{add} (Trent)
* 1333: better cannot push to current repository warning (Petr)
* 1347: (autoconf) check for unsafeMMapFile if mmap use enabled (Dave)
* 1361: specify required includes for curl in cabal file (Reinier)
* 1379: remove libwww support (Trent)
* 1366: remove unreachable code for direct ncurses use (Trent)
* 1271: do not install two copies of darcs.pdf (Trent)
* 1358: encode non-ASCII characters in mail headers (Reinier)
* 1393: swap darcs mv and darcs move (Trent)
* 1405: improve discoverability of global author file (Trent)
* 1402: don't phone home about bugs (Trent)
* 1301: remove obsolete zsh completion scripts (Trent)
* 1162: makeAbsolute is now a total function (Ben F)
* 1269: setpref predist - exitcode ignored bug (Ben M)
* 1415: --edit-long-comment, not --edit-description, in help (Trent)
* 1413: remove duplicate documentation (Trent)
* 1423: complain about empty add/remove (Trent)
* 1437: Implement darcs changes --max-count (Eric)
* 1430: lazy pattern matching in (-:-) from Changes command module (Dmitry)
* 1434: refactor example test (Trent)
* 1432: refer to %APPDATA%, not %USERPROFILE% (Trent)
* 1186: give a chance to abort if user did not edit description file (Dmitry)
* 1446: make amend-record -m foo replace only the patch name (Dmitry)
* 1435: default to get --hashed from a darcs-1.0 source (Trent)
* 1312: update and reduce build notes (Trent)
* 1351: fix repository path handling on Windows (Salvatore)
* 1173: support hard links on NTFS (Salvatore)
* 1248: support compressed inventories for darcs-1 repos (Ganesh)
* 1455: implement darcs help environment (Trent)
Yours,
Petr.
--
Petr Ročkai | http://web.mornfall.net
A physicist is an atom's way of knowing about atoms. (George Wald)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] [ANNOUNCE] Darcs 2.2.0.
Hi all! I am happy to announce general availability of darcs 2.2.0. Getting the release --- For this release, we have decided to provide two flavours, depending on the build system used: 1) The source tarball, http://www.darcs.net/darcs-2.2.0.tar.gz, which can be built using the traditional autoconf-based system. This is the fully supported version. After downloading and unpacking, you can issue: $ ./configure $ make and possibly # make install More detailed instructions inside the tarball (file README). Please note that we had at least one report of build failure, with quickcheck-related message. The currently best workaround, if this happens to you, is to use the cabal version of the package instead, see below. 2) Cabalised source. You can either download a tarball from http://hackage.haskell.org/packages/archive/darcs/2.2.0/darcs-2.2.0.tar.gz and build manually (see the build instructions in README inside the tarball), or, alternatively, you can use cabal-install to obtain a copy: $ cabal update $ cabal install darcs This will give you a darcs binary in ~/.cabal/bin -- you should probably add that to your PATH. In addition to source tarballs, we expect binary packages for various UNIX platforms will be available in due time. For Windows users, Salvatore Insalaco has prepared a binary build, available from http://homepage.mac.com/kirby81_it/darcs/darcs-2.2.0-win1.zip. You just need to unpack the directory somewhere and add it to your path (if you like). Moreover, an experimental TortoiseDarcs release for darcs 2 has been made available by Kari Hoijarvi hoijarvi-at-seas-dot-wustl-dot-edu and is looking for home. It can be found at http://datafed.net/darcs (unfortunately, at the time of this writing, the site seemed unreachable... If you can help with hosting, please mail Kari.) What's New -- The summary of changes since version 2.1.2 (released last November) follows: * In interactive record, it is now possible to get a list of currently selected hunks (command 'l'). (Christian Kellermann) * It is now possible to specify --in-reply-to when using darcs send, to generate correct references in the mail header. (Pavel Shramov) * New repositories with --no-pristine-tree can no longer be created. This only has effect on legacy darcs-1 repositories. * Improvements in Windows support. (Salvatore Insalaco) * Performance improvements in `darcs repair` and robustness improvements in `darcs check`. (Petr Ročkai) * Extensive manual and online help improvements. (Trent W. Buck) * Support for GHC 6.10. * Overhaul of the make-based build system. (Trent W. Buck) * Cabal is now supported as a build method for darcs. (Duncan Coutts, Petr Ročkai, Gwern Branwen) * First stab at libdarcs -- when building through Cabal, all of darcs implementation is now exposed in modules. No API guarantees whatsoever. (Eric Kow) * Additions to Haddock documentation of the existing darcs modules for improved development experience. * Improvements in the testing infrastructure. (Christian Kellermann, Gwern Branwen) * Low-level optimisations in filesystem code. (Ganesh Sittampalam) * Numerous major and minor bug fixes, refactorings and cleanups by David Roundy, Eric Kow, Jason Dagit, Dmitry Kurochkin, Thorkil Naur, Salvatore Insalaco, Christian Kellerman, Florent Becker, Duncan Coutts, Reinier Lamers, Ganesh Sittampalam, Petr Ročkai. And a summary of issues that have been fixed in darcs since version 2.1.2 (compiled by Thorkil Naur): 525 amend-record = darcs patches show duplicate additions 971 darcs check fails (case sensitivity on filenames) 1006darcs check and repair do not look for adds 1043pull = mergeAfterConflicting failed in geteff (2.0.2+) 1101darcs send --cc recipient not included in success message 1117Whatsnew should warn on non-recorded files 1144Add darcs send --in-reply-to or --header In-Reply-To: x...@y.z 1165get should print last gotten tag 1196Asking for changes in /. of directory that doesn't exist gives changes in entire repo 1198Reproducible mergeConflictingNons failed in geteff with ix 1199Backup files darcs added after external merge 1223sporadic init.sh test failure (2.1.1rc2+472) 1238wish: darcs help setpref should list all prefs 1247make TAGS is broken 12492.1.2 (+ 342 patches) local drive detection on Windows error 1272amend-record not the same as unrecord + record 1273renameFile: does not exist (No such file or directory) 1223sporadic init.sh test failure (2.1.1rc2+472) I would like to thank all contributors for making this release possible. Future -- The next release will be 2.2.1, fixing low-risk issues found in 2.2.0, or those that have been excluded for 2.2.0 due to freeze. This release will appear in two or three weeks time, depending on
