On Scmbug

[Kristis Makris]

Hello everyone,

Thank to David Miller for suggesting I should signup in this mailing
list. Here are some of my 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

Sadly, I share the same view. What have I become! I'm sorry, I didn't want this work to go to waste, and I'm awfully busy at the moment. This glue was in use for over 2 months and I just got around to at least announcing it.

> 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

Whatever bz officially offers as an interface, I'll gladly use -- just name what that is. Including globals.pl and calling functionality from there seemed like the right thing to do. I was planning on emailing this list to request for the extra functions I wrote for Bugzilla to be included in globals.pl. I noticed there's a WWW::Bugzilla Perl  module(with which I've experimented for a while), but that requires logging in through the web gui with the user credentials, and I'm not sure how I should retrieve the user password in an automated way.

> 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 ;)

Then I'll have to consider using threads -- thanks for the heads up.
http://bugzilla.mkgnu.net/show_bug.cgi?id=264

> > 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.

Hey I noticed that! I thought of waiting for a few seconds before a commit to group multiple checkins with the same message. I'll look into this at some point. Thanks. The real solution would be introducing atomic commits in CVS, but ...
http://bugzilla.mkgnu.net/show_bug.cgi?id=265

> 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).

I find this step required to support a generic scm -> bugtracking tool. Problem 2, can be solved through an ssh tunnel, or vpn, which is the real solution to the problem.

> 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

A solution to the commas problem was provided in:
http://www.einval.com/~steve/software/cvs-bugzilla/
CVS was patched to handle them.
I will look into this.
http://bugzilla.mkgnu.net/show_bug.cgi?id=267

> 7) You might want to think about nicking our bz->viewcvs autolinking

Thanks, I will. Are there any functions in globals.pl I can use ?
http://bugzilla.mkgnu.net/show_bug.cgi?id=266

Thanks for the feedback and your time guys. 
Kristis