Bootstrap Drupal so xcvs scripts can use Drupal database functions
aclight - April 16, 2007 - 23:48
| Project: | CVS integration |
| Version: | 6.x-1.x-dev |
| Component: | X-CVS scripts |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs work |
Description
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
| Attachment | Size |
|---|---|
| cvslog_drupal_bootstrap0.txt | 10.36 KB |
#1
cool, this is a great start. i'll take a closer look when i get the chance. thanks!
#2
BTW, on line 209 of xcvs-loginfo.php, there is this line:
<?php>
$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
<?php>
$cid = xcvs_next_id('table_prefix_cvs_messages_cid');
<
?>
AC
#3
Re comment #2: Drupal's db_*() functions also can do this for id sequences - it's
<?php$cid = db_next_id('{cvs_messages}_cid');
?>
#4
Here's a new version of the patch, rerolled against cvslog HEAD.
I also removed two functions that are no longer used (
xcvs_db_connectandxcvs_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).
#5
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...
#6
Yep, and they make good use of that :]