I hope you don't mind all these drafts! I could try and be a big boy about this, but especially in these sensitive times, I don't mind a little extra help controlling my communications :-)
====================== Hi Claus, On Sat, Aug 16, 2008 at 21:01:19 +0100, Claus Reinke wrote: > So, as far as I can tell, windows releases are all in pieces, none > up to date, and it isn't immediately clear how to get there, either. Yes! You have put your finger on one of the bigger holes in the darcs community: we need a dedicated Windows release maintainer, somebody to ensure that there is always a fresh build of the latest stable darcs for Windows users. So far, we have been getting by with the generous contributions of a few users, namely Zooko and Simon, it would be really great if we could name somebody to this role. Any volunteers? Darcs users: please see for details http://wiki.darcs.net/index.html/BuildingUnderWindows Also, Claus, we hope eventually to implement the automated building of nightly packages via our buildbot infrastructure http://bugs.darcs.net/issue997 This will make it much easier for people on all platforms to try a very recent darcs. Thanks to Zooko for the suggestion! For what it's worth: > (is there even one right way to build? what about those bytestring > fixes in Simon's executable? These are in the 2.0.2 release and the darcs darcs repository. > what about those discussions on the darcs lists about neither 6.8.2 > nor 6.8.3 being quite the right compiler to build darcs? GHC 6.8.3 is perfectly fine! With 6.8.2 you may experience some performance problems with the hashed and darcs-2 repository formats. We are working on a solution to this, either a workaround or a nice big warning in the configure script. > what about other little things, like mmap apparently affecting darcs > functionality on windows, #443/#320, but it only being disabled in > unstable? This has long been fixed. Sorry for the confusion! I have corrected the status of that bug. We are still learning how to make the most effective use of the bug tracker. Not updating the status is a definite fumble! > If darcs developers are serious about addressing those issues, > there's no way around them having their own ghc head repo, > pulling perhaps weekly to see what goes wrong, and reproducing > any incoming bugs by synching their repo to the reporter's (at > least, you don't have to build ghc, just pull it, and imagine that > you have your own important source changes in working). Point taken. I suspect that the issue at hand is not GHC per se, but Windows support in general. In addition to a Windows release maintainer, I would love to see somebody acting as a general Windows Czar. Claus, for the next release (darcs 2.1 in Jan 2009), we are going to focus on performance issues for a while, but soon after that Windows will be top priority. We will work something out. In the meantime, I bet it would help a lot if we could get automated nightly builds up and running as soon as possible. As you can see, there is lots of infrastructure work to do, buildbots to extend, bug trackers to tidy, scripts to write, wikis to garden. It looks like our community has been growing recently, so with a little extra help and a lot of enthusiasm, we will get there! > |Particularly, darcs will exit if it has trouble applying the patch to > |its internal pristine cache... but if it is having trouble applying a > |patch to the working directory, it tries to do the most robust thing by > |emitting a warning and moving on. > > Having skimmed over the ticket relating to "moving on", that > seems to have been a shortcut/workaround, rather than a feature > (#434, where the suggested fix was to make darcs actions atomic: > either they succeed or not, but nothing in between). Darcs 2 and up has atomicity in the most sensitive bits, that is, its pristine cache and inventory. This makes it a lot harder to bring darcs into an inconsistent state. On the other hand, this does not extend to the working directory, which as you point could, could lead to failures applying patches to the working directory being intermixed with the user's changes. The new "moving on" feature limits the effect of this, but it could still be better. > In particular, darcs should be able to recognize that it has taken > that shortcut, which means recording a flag "pristine and working > out of sync because <warnings here>", and repeating the warnings > for every darcs command until the user addresses the issues and > resets the flag. Currently, darcs doesn't distinguish between its > own messing up and the user editing working, which isn't good, > especially if there are real unrecorded user changes in working. Thanks for the feature request. I have filed it in our bug tracker as http://bugs.darcs.net/issue1010 Best regards, -- Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow> PGP Key ID: 08AC04F9
pgpgaqmO4Bx6l.pgp
Description: PGP signature
_______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
