Version Control System
It was nice to see
James writeup a
comparison of cvs, subversion, and bazaar. He concentrated on
showing the similarities, but I’d like to point out a couple strong
advantages bazaar would bring as a set of usage scenarios.
Usage case 1: If I’m working on a project hosted in cvs, I often just
won’t bother to hack on stuff if I’m forced to be offline. The reason
is that the lack of access to the repository is just so limiting that
sometimes I don’t feel like it’s worth it (I like to be able to look
for more details about a specific commit in the past, being able to
compare behavior to an old version, easily getting diffs without
having to remember to make a full copy of a pristine version of the
directory every time a cvs update is performed and/or hoping I
remembered to do it when I need it, etc.) This can partially be
solved in cvs by doing using rsync to make a copy of the repository
itself and to attempt to update it when I get back online (which I
have done), but it involves a bunch of hackery and is problematic at
best–it’d be too easy to totally mess up the repository. baz makes
it easy to replicate a repository and then merge between them. It’s a
very useful feature, even for a single-person project.
Usage case 2: When trying to fix a bug, usually in a product that I’m
not too familiar with, I often have several cycles of ‘cvs diff -pu |
less’ (to remember all the changes, extra debugging information I’ve
added, initial failed attempts to fix stuff that caused lots of
changes, etc.) followed by a number of changes to the code. With cvs
and products like gtk+, this is really slow and aggravating as cvs
diff takes forever. A local repository copy/fork/branch/whatever,
which baz enables, fixes this problem quite nicely. (Yeah, yeah, I
could check out another pristine working copy and just use normal diff
recursively on the two on-disk directories; yes, I do that with cvs at
times, but I usually think that “I’ll only need to do this one more
time…” and a full cvs checkout takes longer than a cvs diff)
Usage case 3: Lots of users with cvs are, of necessity, third-class
citizens–they only get access to the anoncvs servers which are always
out-of-date (even if only by a day) because there’s no way to give
them read-only access to the real cvs servers. baz can easily fix
that (my developing with gnome guide tutorial is in a repository where
only I have write access to, but the whole world has read access).
P.S. I don’t mention tla here even though it shares these advantages,
because its usability is so horrendously awful (IMO) that it could
easily be seen as negating all its advantages (at least the last
version I used). baz does suffer some still, but is far
better in the most recent versions. I’m really looking forward to
baz-ng to see if it can continue to improve the usability.
Bugzilla
I realized that although we had a few patch reports, I didn’t really
use them. I found that after I went to them to find unreviewed bugs,
I’d have to click on a link that would forward me to patch-status.cgi,
which would auto-redirect to buglist.cgi after some time, from which
I’d have to pick a bug (instead of a patch) and then scroll down to
find the patch and finally click on the appropriate links for it. It
was just too much of a pain. So, I wrote a new patch-report
(which other patch reports now make use of in their links). You can
also limit your search to
a specific product or limit it to patches created in a certain day
range such as
the last week.
Also, I was seeing multiple people suggest or talk about having a
special maintainer section that listed a bunch of common queries
(e.g. all bugs with patches that have been marked as
accepted-commit_after_freeze, or all bugs that haven’t been commented
on, or all bugs with a certain set of words in it, etc.). So I made
something like that at the reports
for maintainers section.