Here's a patch to HEAD that causes the xcvs scripts to first bootstrap Drupal so that they can use the database functions that Drupal provides instead of making direct mysql_query() and etc. calls.

Warning: I have not tested these changes on a Drupal installation (I don't have CVS set up anywhere). dww said he would look at them and test them out.

Also, I'm bootstrapping Drupal in xcvs-config.php, which is not the ideal place to do this. I'm also not sure if the include call to bootstrap.inc actually works (there may be path issues that prevent it from working right). Those should be easy to fix for someone who can test things out.

AC

CommentFileSizeAuthor
#4 cvslog_drupal_bootstrap_1.txt10.55 KBaclight
cvslog_drupal_bootstrap0.txt10.36 KBaclight

Comments

dww’s picture

dww
we/he/they
commented

cool, this is a great start. i'll take a closer look when i get the chance. thanks!

aclight’s picture

aclight commented

BTW, on line 209 of xcvs-loginfo.php, there is this line:

>
    $cid = xcvs_next_id('cvs_messages_cid');
<

I think you would want to use the actual database table name there. I'm not sure how to get the actual table name within Drupal, but you would effectively want to use something like

>
    $cid = xcvs_next_id('table_prefix_cvs_messages_cid');
<

AC

jpetso’s picture

jpetso commented

Re comment #2: Drupal's db_*() functions also can do this for id sequences - it's

    $cid = db_next_id('{cvs_messages}_cid');
aclight’s picture

aclight commented
StatusFileSize
new cvslog_drupal_bootstrap_1.txt10.55 KB

Here's a new version of the patch, rerolled against cvslog HEAD.

I also removed two functions that are no longer used (xcvs_db_connect and xcvs_next_id) and made the change in comment #3 (which I had made in my version a while ago, I just forgot to post a new patch here).

I've been using a very slightly modified version of this patch on my site (running SVN, of course) for a while now, and haven't run into any problems.

As before, this patch is completely untested in it's intended use (that is, against the unforked cvslog module).

dww’s picture

dww
we/he/they
commented
Status: Needs review » Needs work

This would need to be ported to D6 before it could be applied. It'd be helpful for #371969: Move developer info into a block provided by cvs.module (so we could use the core cache API and call cache_clear_all() from inside xcvs-loginfo.php), but frankly, I think I'd rather spend the energy switching d.o to versioncontrol_cvs -- pretty sure the cvs-integration scripts for that are already bootstrapping drupal...

jpetso’s picture

jpetso commented

pretty sure the cvs-integration scripts for that are already bootstrapping drupal...

Yep, and they make good use of that :]