as the maintainer of the project module, i got private email from a user named "halkeye" about this topic. instead of continuing the discussion on email, i wanted to post my reply here, since i think other members of this group might be interested in this.
On Jun 17, 2006, at 12:53 AM, halkeye wrote:
Been looking into making a svn module for drupal,
i hope you found contributions/modules/svn in the drupal repository. looks like it was written by moshe, though unfortunately, it doesn't look like there's a drupal project associated with it. :(
and noticed that the project module has many links to the cvs module.
actually, the overwhelming majority of the project/cvs interaction is handled by the cvs module:
http://drupal.org/project/cvslog
(/modules/cvslog in the drupal contributions repository)
the project-specific mentions of "cvs" are pretty minor. for example, a few poorly worded links on the project nodes, which could easily be made generic enough to make sense with cvs, svn, or any other rcs. i haven't done a thorough audit of the code, but i suspect the parts of the project module itself that assume/depend on cvs are a) small and b) easily fixed. i'd be more than happy to review and commit patches that made project not assume a specific rcs, nor to assume the presence of an rcs and code at all.
Trying to figure out a solution if more people after me make more rcs solutions, so one doesnt' have to keep patching the project module.
maybe make use of the module_hook command to find out which modules support specific functionality?
no, in general the solution would be to make project itself not assume the presence of an rcs at all, and then put all the rcs-specific functionality into other modules, which extend the project UI through hook_menu() and hook_form_alter(). if there are rare cases where this wouldn't be sufficient, we can figure that out once we run into them, but i'm guessing this approach would be able to cover everything.
i hope this helps. i'd love to make drupal a much more flexible and powerful solution for source/project management than trac. ;) isolating the dependence on any given RCS will help that a lot. plus, there's the frequent talk of moving drupal to SVN. i'd consider any work to make the project module not assume CVS to be worth doing, both for general flexibility for other sites, and eventually, for drupal.org itself. i personally don't see the need to switch drupal to use SVN anytime soon, but this sort of work is definitely a precondition to making that possible.
thanks,
-derek
Comments
its finally working
Okay, bottom to top.
I totally agree, drupal.org has no real need to switch from CVS to SVN. The main reason i'm writing this is not for drupal (although that'd be really cool), but more because both personal and work uses svn to manage code, and I know others use svn too. (as well as darcs, and a few other ones...bitkeeper?)
Two of the biggest things that tie into cvs that i've found so far are:
function project_developers($nid = 0) {if ($project = node_load($nid)) {
- $output = module_invoke('cvs', 'get_project_contributors', $nid);
+ $output = implode('',module_invoke_all('get_project_contributors', $nid));
Which is used for listing all the members who commit to a project.
And in project_project_view
+ if (module_exist('subversion')) {+ $links[] = l(t('View SVN messages'), 'node/'. $node->nid . '/track/code');
+ $links[] = l(t('Developers'), 'project/developers/'. $node->nid);
+ }
Which just shows developers links and links to svn/cvs messages.
(ack, low laptop battery power, will reply to the rest later)
http://drupal.org/project/sub
http://drupal.org/project/subversion
got an intial version up now.. needs some patches to the project module, but I was hoping we could get some feedback from some others on exactly how to go about doing this..
works without the patches though, just better if you have them.
historical note
i contributed the 1st svn module and then walkah completely rewrote it to use pecl svn extension. it has languished for a long time.
project created
i created a project for svn.module ... i am not opposed to merging or renaming svn.module if thats wise.
because of the fact that i
because of the fact that i can get diffs of files without checking them out, I could easily store diffs in the db and such, creating a more integrated feel like trac has.
diffs in the DB
i hope you just mean the diffs for each commit, not every possible diff that people might want to view. ;) that seems like the job for the viewsvn (or whatever we're going to name it) module that talks to svn and just displays the results into your web page.
hrm, that is a good
hrm, that is a good point..
I just don't like having to setup multiple pieces of software where one could do easily.
But trac just does changesets, which is the diff from the previous version.