Scmbug

[Dave Swegen]

As the main code-bodger of the bz->cvs integration stuff on Steve's page
I'd like to make a few comments:

1) (And this is the one that really annoyed me) If you want people to
use a tool that you've written, at least put a descriptive page up. Just
pointing to a tarball and saying "Abandon all the work you've done, this
is much better" just isn't going to work. I very nearly didn't bother
looking any further at that point...

2) To be honest, I've pretty much gone off the idea of having the scm
system fiddling directly with the bz DB. The main problem is that as bz
starts working with more DB backends, and schemas change, the script is
going to have to keep up. More maintainance overhead, and you also miss
out on nice things like sanity checking the SQL. FWIW, the next version
of the cvs->bz integration will probably talk via the bz web ui (which
is going to need some work).

3) Using a daemon is potentially a nice solution. But how useable is
fork() on win32 systems? This is a consideration, as there are plenty of
bz users on win boxes (I know, sounds mad, doesn't it ;)

4) (Related to the one above): Having an intermediary step that sits
between cvs and bz has two problems: One is that it is one extra step
which the user can muck up installing (though your solution is far nicer
than ours), and it may make things awkward from a networking POV (think
firewalls).

5) A common request we have is that when a single commit that covers
files in multiple directories is made, only one message will be placed in
bz. I couldn't see anything in your code that dealt with this, but if it
isn't there you might want to keep that in mind. I still havn't come up
with a nice clean solution to this.

6) Potential bug: I believe that the parsing of files,dirs and
versions in Glue.pm/prepare_activity_commit_from_CVS doesn't cope with
files or dirs with whitespace in them (it won't cope with commas either, but
then there is very little that can be done about that). We had this very
problem with windows users who added documentation... Give me a shout
and I'll dig up the new regexp I came up with that copes with this.

7) You might want to think about nicking our bz->viewcvs autolinking
stuff, and modifying it to cope with the format of your commit messages.
For a lot of the users of our stuff this a major nice feature.

The only thing that I believe your system improves on over ours is the
delivery method, which looks much, much easier to set up and configure.
As I said in point 2 I think talking directly to the DB is wrong, but
the real problem is how to solve the issues that raises, which is a different
discussion :)

Cheers
    Dave