With the Beta 3 release of Darcs 2.5 on Hackage (the Haskell library and program repository), the ipatch program I recently introduced could now be uploaded to hackage, too. If you use cabal-install, you can now install and use it with a simple run of "cabal install ipatch".
I also made the program now handle patches that add or remove files, extended the help texts a bit and added a test suite. This means that you can actually make use of ipatch as of now, to split patches into several small patches and to apply a patch interactively. Of course it needs some more testing, and you might have feature wishes – in either case, let me know.
As a Debian maintainer, I often work with patches (files listing changes to text files), for example when tracking the modification I make to some software before I upload the package to Debian. To manage these patches, quilt is a nice tool: It helps you maintain a stack of patches on top of the original code and encourages you to keep your variously modifications separate.
One use case is not supported by quilt at all: Splitting patches. One often has a large patch containing several independent changes. This might happen after you fix a few problems in the upstream code and then run dpkg-buildpackage, which will create one patch of your changes and put it in debian/patches. Before, I had to manually edit the patch and write the hunks, which are the building blocks of patches, into separate file.
There is no such problem when using a version control system, such as Darcs. Especially Darcs is rightly famous for its user-friendly interface and powerful hunk-selection features. You can even split a single hunk (which could be a change to one line) into two separate steps! Have a look at the HunkEditor page on the Darcs wiki to see how that works.
Well, it is not stealing if it is Free Software... Darcs has these nice capabilities and provides them in the context of version control systems, while we need them in the context of patch files. But Darcs is providing an API to its code, so shoudn’t it be possible to create a program that uses the Darcs code to split patch files? As a matter of fact, it is possible: You can see that program in action on this 3min Ogg Theora-Video or directly here if your browser supports HTML5:
The code is a working proof of concept. What you see works. You do not see how it handles patches that create or delete files, patches that do not apply cleanly or are already applied or any kind of error handling. That does not work yet. If you still want to try it, you can grab the code from the Darcs repository at http://darcs.nomeata.de/ipatch, but you need to build the latest development state of the Darcs library first.
I think ipatch could become a very useful and powerful tool with applications in areas where nobody would think of using Darcs. I definitely want some integration into quilt, replacing the splitted patch in the series by the replacing patches automatically. Maybe even a git plugin could be created? But I don’t think I can push this project far enough on my own. So this is an invitation to join me and make ipatch a great tool. This invitation goes especially to the Darcs developers: Please have a look how the code uses the Darcs API and help to improve the collaboration here. I think we can use the darcs-users mailing list until there is need for a dedicated mailing list.
The darcs hacking sprint is slowly nearing its end. As planned, I have worked on integrating DarcsWatch and bugs.darcs.net, and I am satisfied so far. From now on, if someone submits a Darcs patch to patches@darcs.net, the patch will also be tracked by DarcsWatch. DarcsWatch will display a link to the entry on bugs.darcs.net, and also add a comment to the bugtracker with a link to the patch on DarcsWatch. And eventually, if the patch is included in the darcs.net repository, DarcsWatch will change the state of the ticket to accepted, removing one step of work for the Darcs maintainers. Currently, it checks the state of the repository three times per hour, so expect a delay after you applied the patch to the repository before the state is updated.
Today, my alarm clock was set to 4:30, as I was going to Vienna, to attend the Darcs hacking sprint. I’ll be working on DarcsWatch, making it a bit more modular and hopefully integegrate it better into bug tracking systems (especially roundup, as that’s used by the Darcs team). On Monday, I’ll be a tourist until I leave in the evening. If any Debianers or Haskellers want to meet for keysigning or sightseeing, just drop me a mail!
A lot of haskell-related projects use the darcs version control system. Darcs has the nice feature that you can easily submit a patch by e-mail, usually sent to the project maintainer or a mailing list. What has bothered me in the past was that I had to manually check whether my patch was applied yet.
So this week, I wrote DarcsWatch. DarcsWatch receives submitted patches and compares them to the repositories it knows about, whether the patch is missing there or not. You either send your patches to DarcsWeb directly when submitting them, using CC, or DarcsWatch is subscribed to the project mailing list itself, which is the case for the darcs-devel and xmonad lists. Other than that, not much is to do, and you’ll find a nice overview of your patches, like this overview of my patches, with diffs and download links.
If you want to use DarcsWatch for your contributions to other projects, or for your own projects, have a look the documentation. There are probably still bugs around, and the problem of marking patches as obsolete is not really solved yet, so if you have ideas about it, mail me, comment here, or come to #darcs on freenode. Patches are always welcome, you can get the source from DarcsWatch’s repository.
I recently did my first experiments with darcs: A friend of mine and I hacked on the same code, and by giving each other access to one’s darcs repository, we could easily exchange our new code.
One problem I had was that my friend recorded a patch that I did not want applied in my repository. Nothing else depended on it, so I could just say no everytime I use “darcs pull”, but it’s still a hassle. Also, imagine that I’m somewhere else and I suddently decide that I do want the patch?
A similar problem would be if I created some patches that I temporarily don’t want applied. I could branch, and then unpull them, but this is a bit too much work.
In both cases a “patch shelve” would be handy. A seperate storage for patches in my repository that are available, but not applied. I’d imagine that the “darcs pull” command would then allow me to “pull and put on the shelf”, and not offer me this patch again. There would also be “put on shelf” and “get from shelf” commands. So if anyone feels like hacking on darcs, this feature would be appreciated.
Also filed as a withlist bug.
Bilder