Matthew Dillon has posted an update for the 9th on the state of Hammer. The next big question: should the Hammer code for porter be stored in Subversion or Git?
Also: Nothing earth shattering, but this post on users@ has some details on Hammer usage and how it works with large files and with backups in general.
Wow, I didn’t think git was actually going to come up…
As a user, who mostly has to poke around CVSWeb and gitweb interfaces to check for changes, I notice git projects seem to prefer inscrutable three-word comments for commits, where almost every other version control system sinks more verbose comments with much more useful metadata. (Something like “correct xyz support” in git vs. “Do foo to correct xyz support; this was done because v and w, we had tried a b c and d; ../../../bar had to be touched as part of this change…” anywhere else.)
I’m not sure if this is a limitation in git or a style thing, and I’m not sure how much it matters to filesystem porters (especially when it is the familiar, native choice of the likely destination), since people tend to be vocal about their decision-making with filesystems. It’s a noticable annoyance when flipping through, say, Xorg drivers checking on support for one out of ten dozen related chipsets that nobody saw fit to mention anywhere else.
[Of course, git was inspired by Linux kernel workflows, where merging privately-completed code is a big thing, and for “historical reasons” commits to that project are always discussed and hopefully documented on its mailing list…]
Just had to make the observation; if git does get picked I hope there’ll be a way to preserve more of the committers’ thought-processes than just a notation: “added code”.
Does anyone know why Bazaar was ruled out?