Removing hard coded cvs module support.. adding hooks instead.

Not realy sure how to handle:
project.inc: project_project_access('create'

        // Since this CVS access checking is non-standard, we need to
        // special-case uid 1 to always allow everything.
        if ($user->uid != 1 && module_exist('cvs') && variable_get('cvs_restrict_project_creation',1)) {
          return db_result(db_query("SELECT uid FROM {cvs_accounts} WHERE uid = %d AND status = %d", $user->uid, CVS_APPROVED)) ? TRUE : FALSE;
        }

(created an issue so i had somewhere to add patches)

CommentFileSizeAuthor
#1 drupal.project.subversion.patch.txt951 byteshalkeye

Comments

halkeye’s picture

halkeye commented
StatusFileSize
new drupal.project.subversion.patch.txt951 bytes

Adding some hooks for links and contributors

dww’s picture

dww
we/he/they
commented

FYI: i'm interested in helping with this stuff, but i'm unavailable from now until mid july. feel free to gather as many ideas and patches as you can (preferably, with the corresponding changes to cvs.module so that everything would still work fine on d.o), and i'll review, test, comment, and commit them once i'm back.

thanks,
-derek

bjvetter’s picture

bjvetter commented

I've been away for a bit and was updating myself on the flurry of activity on the new project module. I noticed many comments about cvs integration and such for releases, tags, etc. While I know that drupal.org uses CVS, we're looking at using Subversion instead.

So I'd like to toss my 2cents in and suggest that you provide some way to hook in a variety of release mechanisms. Besides CVS, SVN is an obvious extension that perhaps we can put in ourselves. There may even need to be a way to enter the info manually instead of relying on integration to get the list of tags.

I haven't looked at the current CVS code, so you may already be going down this path.

dww’s picture

dww
we/he/they
commented

yes, i know. it's definitely my medium term goal. however, my desire to get a new release system in place as soon as humanely possible means that i'm adding yet more functionality to the cvs.module instead of trying to refactor all the common bits into a "project_vcs.module" or whatever i'll end up calling it.

so, yes, in the short term, this is unfortunately a "step backwards". but, the new release system will be such a vast improvement, that once it's in place, it'll be so much easier for myself (and everyone else) to make improvements in whatever modules we're working on. ;)

so, fear not. i don't want drupal's project management to depend exclusively on CVS anymore than you do. ;)

-derek

aclight’s picture

aclight commented
Status: Active » Closed (fixed)

At the request of dww, I'm marking this issue as closed.

The project* module still has a fair amount of hard coded CVS references in it, but I'm working to clean some of these up. See patches/issues at http://drupal.org/node/151490, http://drupal.org/node/150485, and http://drupal.org/node/150374 for more information.

Furthermore, jpetso has a SoC project with this specific goal in mind. See the Issue tracking and software releases group on groups.drupal.org for more information.

Finally, for those interested in using Subversion with the project* modules, I have forked the 5.0 version of cvslog and the related xcvs scripts and have gotten them working with subversion. For more information, see Project tracking and releases using Subversion

AC