Scmbug

[Kristis Makris]

Hello,

It looks like this message didn't get through the first time, so I'm
resending.

> 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

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