Sunday, November 23, 2008

darcs weekly news #13

News and discussions

  1. Announcing darcs 2.1.2. Eric has released darcs 2.1.2. You can also find darcs 2.1.2 on hackage.
  2. Character-based patch type. Andrew Robbins is developing a library for character level diffs that would allow for indentation and word patches as well as other fine granularity patches.
  3. Digital Fountain Codes for Patch Distribution. Tom Hawkins has a proposal for using Digital Fountain Codes as a fast distributed protocol for transfering data between darcs repositories.
  4. Camp Update. Ian Lynagh has started an irregular news letter about Camp. Looks like he's accomplished a lot. Take a look at Camp today.
  5. Darcs Oversight Committee (Software Freedom Conservancy). Eric has proposed we create an oversight committee as part of joining the Software Freedom Conservancy.

Reviewers

Thanks to our patch reviewers this week!

  • Christian Kellermann
  • Eric Kow
  • Dmitry Kurochkin
  • Trent W. Buck

Want to receive recognition for helping with Darcs? Add yourself to the patch review team today so that Eric knows to send patches your way.

Issues resolved in the last week (3)

issue1043 David Roundy
issue1101 Christian Kellermann
issue1117 Christian Kellermann

Patches applied in the last week (44)


See text entry for details.

Thursday, November 20, 2008

camp irregular news #1

Reposting a recent darcs-users update from Ian (with some very slight adjustments on my part for the conversion to HTML)




Hi all,

I haven't written about camp in some time, and a lot has happened, so I figure I should send an e-mail. So, here's the first edition of the "Camp Irregular News", if you will :-)

Mailing list


Camp now has a mailing list. I'll probably continue to send things of more general interest to the darcs list, but camp-specific stuff will generally go to the camp list. For details, please see http://projects.haskell.org/camp/contact

Bug tracker


But the main reason that camp has acquired a mailing list is that camp also now has a bug tracker and I wanted somewhere for the ticket change messages to go. Fow now, this is really just a TODO list, with the major missing pieces listed.

Development


And some real work, too. At and around the sprint, I:
  • Implemented "chunky" hunks, which mean that we don't need to break a file up into lines and then join it back together again when applying hunk patches
  • Implemented primitive interactive patch selection. It's nothing fancy, but it makes it easier to work with than the all-or-nothing record that camp had before
  • General improvement, e.g. there is now a repository type, rather than just misusing FilePath
  • Worked out how to pkg-config, libcurl and Cabal to play nicely on Windows/MSYS/mingw
  • Made a darcs2camp tool
  • Implemented the "get" command

darcs2camp

darcs2camp is currently fiddly to build, as it needs to be linked against some of darcs's sources. In the near future it will either use libdarcs, or I'll fork a copy of darcs and wibble it until it just builds darcs2camp.

Due to working on each primitive patch separately, darcs2camp isn't the fastest beast in the world; on the 19766 megapatch (359470 primitive patches) GHC repo it takes me 1 hour 47 mins to convert from darcs to camp format. Then again, the original git conversion took 3 days, so it could be worse! And it shows a patches-converted count to keep you entertained.

The disk usage for darcs's patches directory is
disk usage115M
actual number of bytes49M
actual number of bytes when uncompressed204M


Meanwhile, camp's patch file weighs in at 214M (which is both the actual number of bytes and the disk usage, as it's all in one file). There are a number of things going on here:

  • camp currently doesn't store any meta-data, so it should be a little more than 214M.
  • currently, if we store the primitive patch "name-3" inside the patch "name" then we store the string "name-3" even though we don't have to.
  • We could easily compress individual patches. Presumably if we did this with gzip then we'd get down to about 50M.
  • With a little work we could compress clumps of patches. However, gzipping the whole file only gets us down to 46M, so there is little to be gained there. bzip2ing the whole file gets us down to 38M.

"get"ing repos

And that means we can do timings etc for large repos easily.

Some timings for get and the ghc repo:
  • With darcs 1.0.9rc1, get takes around 5.5 seconds. However, I believe it's copying the pristine directory rather than actually applying the patches, which isn't safe if you can't lock the repo. However, "darcs check" takes 1 minute 45 seconds, and that does essentially the same work that "get" is supposed to
  • with darcs 2.1.0, get takes 1 minute 29 seconds (and looks like it's behaving safely)
  • with camp, get takes 1 minute 37 seconds


I haven't looked at optimising get with camp yet, but one thing that should definitely make a big difference is batching up multiple changes to a single file. It is common to get a megapatch which contains a sequence of n patches which change a hunk the same file. When applying such a megapatch, camp currently reads and writes the whole file n times, which obviously isn't optimal! IIRC that made a significant difference when we added it to darcs, and I expect it will for camp too.

camp is also cheating slightly, as it doesn't do a syntactic-validity check of the patches it is given before applying them. This means that it'll fail less prettily than it ought to. However, I'm not sure if darcs also cheats, and I don't expect that it will make much difference to the time taken anyway.

Camp's space usage while "get"ing is currently higher than it should be because of http://hackage.haskell.org/trac/ghc/ticket/2762 so I can't get good figures for that at the moment.

What next?


The above is mostly development stuff, mainly due to being at the sprint. I plan to focus more on theory stuff next. As you may have seen on the darcs list, I've started thinking about conflict marking, and I also have some patch theory proofs in my head that I need to get written down in the paper.

Thanks
Ian

Monday, November 17, 2008

darcs 2.1.2 released!

We are pleased to announce the release of darcs 2.1.2, which you can
download from

http://darcs.net/darcs-2.1.2.tar.gz

This is deliberately a very modest release, containing as few changes
from darcs 2.1.0 as we can manage. The changes we have included are
GHC 6.10 support and a bugfix for Windows (notably, one which makes
darcs help work from the DOS prompt without the need for MSYS or
Cygwin). See the attached ChangeLog for details.

So what's next? We have been doing a lot of work and we're eager to
show you some of the results. Our next release is scheduled for January
of 2009, with performance improvements from the darcs hacking sprint,
improved Windows support, a new optional Cabal-based build and a first
cut at libdarcs.

darcs weekly news #12

News and discussions

  1. Reasons to delay upgrading. Nathan Gray gives feedback as to why his team cannot yet switch to darcs2. Let's fix Nathan's bugs!
  2. darcs roadmap proposal. Eric has given us a roadmap for next six months of development. Get hacking!
  3. FYI: user-manual status. Trent W. Buck is making steady progress with revamping the user manual.
  4. New extension syntax -WError? How do you want to solve this? Managing compiler warnings is now a social requirement instead of a technical one.
  5. Buildbot uploads. Don't let the typos scare you away! Jules Colding, Zooko and others have the buildbots setup to upload the binaries as they build them!
  6. transitioning to cabal. Darcs now builds with cabal.
  7. announcing darcs 2.1.1rc2. Try out our newest release candidate today.
  8. growing the darcs team again! Welcome Alexander Suresh Kerr Sittampalam to the world and congratulate Ganesh Sittampalam.
  9. new Windows Czar and Review Team. Salavtore has taken the title of Windows Czar and we have an official review team now. Join today!
  10. Software Freedom Conservancy agreement. The Darcs project may be joining the Software Freedom Conservancy.
  11. [ANNOUNCE] darcs-fast-export. Miklos Vajna has put together a fast export from darcs to git.

Reviewers

Thanks to our patch reviewers this week!

We had a lot of reviewers this week, I hope I didn't miss anyone.

  • Don Stewart
  • Duncan Coutts
  • Jason Dagit
  • Trent Buck
  • Petr Rockai
  • Ganesh Sittampalam
  • Lele Gaifax
  • Christian Kellermann

Issues resolved in the last week (5)

issue525 David Roundy
issue844 David Roundy
issue864 Tommy Pettersson
issue1189 David Roundy
issue1223 Eric Kow

Patches applied in the last week (282)


See text entry for details.

Friday, November 7, 2008

darcs weekly news #11

News and discussions

  1. Sad news and steady changes. David will be stepping down from leadership of the darcs project, with Eric taking over in these new roles.
  2. Planet darcs. New aggregator for blogs from the darcs community. Posts to the planet are mainly but not necessarily always related to darcs
  3. Standard darcs benchmarks. Let's get serious about numbers.
  4. Haskell talk at Columbia Area Linux Users Group. Andrew Robbins talks about "How the Haskell programming language promotes bug-free software.by enforcing heavy restrictions on source code, and on several open source software projects that use Haskell for this purpose (darcs, parsec, xmonad, yi)."
  5. How does conflict marking work? Ian peers into the heart of conflict marking.
  6. New camp trac and mailing list!

Reviewers

Thanks to our patch reviewers this week!

  • Trent Buck
  • Jason Dagit
  • Florent Becker

Issues resolved in the last week (1)

issue1183 Thorkil Naur

Patches applied in the last week (99)


See text entry for details.

Followers