As part of the work I’ve started doing on Stateless Linux, I’ve found myself hacking on device-mapper‘s snapshot support. It’s actually been really good fun to do a bit of kernel hacking again after such a long time … and this time I feel like I actually have some clue what I’m doing.
I’m really behind the times when it comes to all the new fangled revision control systems out there like bzr, git, mercurial, svn etc. – cvs and manual patch mangling is all I know.
So, when agk pointed me at quilt, I was a bit dubious at first but gave it a shot. It turned out to be a really simple and useful way of maintaining your own patchset in parallel with an upstream codebase.
Even though it’s a really simple tool, it seems to me to have some of the important advantages of other systems like distributed offline branches and change sets. If I had time to hack on GNOME again, I’d use quilt a lot for offline branches alongside CVS. It’s given me an appetite for looking at other systems too.
FWIW if/when you decide to take a look at “the new fangled RCS systems out there”, if you want something like quilt:
– with Mercurial you can use the mq extension (distributed with Mercurial itself)
– with git, there’s StGIT
In bzr-land, “bzr shelve” is sometimes compared to quilt, but IME it serves a different purpose and is much more limited.
One of the coolest things about quilt is that it scales up insanely well for a large codebase. We’re using it inside the Debian Xorg packages to manage our patches because the old system simply was too slow to really work. We have well over a hundred patches to that huge codebase and quilt has worked flawlessly. You have to be smarter about it (by using quilt edit) than with other patch systems, but it’s an amazing tool to have in the box. We use it inside the packaging system, all of which we store in svn by the way, so quilt can be used as an RCS within a RCS if you want.