Integration with other modules

I've jotted some notes on the scenario I believe we need to keep in mind. That is, allowing for each OG to have its own SVN module automatically created and deeply integrated. Check it out at http://www.wovenlabs.com/workspace/components/svn.

Integration with Case Tracker should also be discussed.

One possible approach, at this stage, is to create a new module, called perhaps trac (heh) and copy any and all other modules into this new module and move forward without having to be concerned with any backwards compatibility at all. That way the cvs routines in the project module could be directly converted to svn equivs and any other aspects of dealing with, say, a wiki module could be free of BC concerns and cruft. I think it would be easier to get significant svn updates into the project module from a trac (whatever) module after it was proven to be working than to just keep updating and co-managing the project module as well. This approach could take care of the 2nd two points. I'm not sure what the OG module is yet, or where it fits in to the overall Drupal scheme.

-100 to "starting over" with a new, incompatible module for "trac". any site that wants to do issue tracking, software integration, etc, with drupal will want to save their old data and move it into whatever new solution they're going to install, which will either be a non-problem, or a trivial DB update, if they continue to use their existing solution. plus, in spite of all of the failings, there's still a lot of wisdom encapsulated in the code bases of the existing modules. furthermore, this module's scope is relatively limited, and i see no reason whatsoever to fork the code of any other modules just to get svn integration. finally, there's NO reason to make an svn-specific version of project, casetracker, etc, etc. all we want/need is to make the existing modules not care what version control system is being used, such that sites (or ideally, individual projects) can just plug in whatever RCS they're using.

i've already indicated my desire and ability to make the project module RCS-independent (http://drupal.org/node/70125). that's going to be relatively easy, and probably the hardest of the bunch. i don't know what concerns (if any) you'd hit in casetracker. as far as i can tell, it has no notion of source code at all, so this really doesn't matter at all. i'm guessing that so long as we make it so each project could point to its own RCS repository/directory, and made project sufficiently OG-aware (OG == organic groups, ala http://groups.drupal.org) via http://drupal.org/project/og_project, i don't know what else you'd need to do for happy svn-integration.

so, from my perspective, the only thing that really needs any work at all is a patch for #70125. not sure what else you hope to accomplish with this issue. :)

i'm still on vacation right now, and not in any position to work on code, but i might be available for a visual review of a patch, or general input on the direction the code was going.

-derek

@dww: -100 to "starting over" with a new, incompatible module for "trac". I didn't really suggest starting over from scratch, just starting from a combined experimental module made up of the current modules that would comprise a trac-like clone, and move forward from that point without having to be concerned with backwards compatibility or any CVS legacy issues. When the required functionality is in place then look at intergrating the good parts back into the standalone modules. Abstracting a revision system backend has merit but it also introduces extra layers of complexity and coding overhead that will take more time to implement and debug. I want a PHP trac clone yesterday so I'll spend my time getting to that goal via whatever is the path of least resistance.

i just think you're mistaken in how easy it will be to hack together a SVN-only clone that provides the same functionality that the project.module and cvs.module provide together right now. furthermore, i think you're underestimating how much work it will take to get this "clone" back into any kind of shape to be useful to the drupal community at large...

abstracting the RCS away from the project module will be a little bit of work, but definitely worth doing, and not all that complicated. anything else *might* be slightly faster in the short run (i'm not even sure of that) but *definitely* more work in the long run...

however, i'm unavailable to actually write any code for the next few weeks. so, if you want to do something now, do whatever you're going to do... :) i'd just vote for spending the time on work that won't have to be thrown-away or re-done in a month.

thanks,
-derek

thats actually what i've been doing...

trying to find ways that look good even without havng to modifythe project module (yet)

Looks like subversion will have to have some work done to make it work with og properly, but otherwise it looks pretty good... I don't want subversion to contain any of the issue / project stuff, although eventually, in the end, i'd like to see it tied to together to have a nice clean setup like trac does, but its still just parts of a whole.

+1
i would love to see subversion integrated more w/ project module & drupal in general. what about backing drupal's file attachments and or node revision systems w/ Subversion?

what about backing drupal's file attachments and or node revision systems w/ Subversion?

i proposed this months ago: http://drupal.org/node/50682
haven't yet had a chance to work on it, but i think it'll be amazing whenever someone finishes it.

don't know if you followed this halkeye: http://drupal.org/node/125222#comment-208909 and http://groups.drupal.org/node/3259 , if everything goes well by September subversion integration will be smooth :)

The result of last year's Summer of Code was the Version Control API, and meanwhile there's a Subversion backend for it as well - quite minimal though, it doesn't do more than log parsing at the moment. That is, it doesn't have:

• A repository browser.
• Hook scripts so that access could be dynamically restricted.
• Integration with any password storage, be it svnserve, WebDAV or SSH. The latter two should be done in a VCS agnostic way anyways.
• Also, the log parser is very slow at the moment.
• There's no release node integration that would generate release tarballs for projects.

That said, Version Control API has realistic chances of replacing cvslog on drupal.org and elsewhere, and when that happens, the Subversion backend gets all things for free that apply to the CVS version of the Project* infrastructure. I would appreciate every contribution that helps with achieving this goal, there's a good share of work to be done still: see this page for a TODO list. Or in case you prefer something easier, you could implement the versioncontrol_svn_get_directory_contents() and versioncontrol_svn_get_file_contents() functions (alias 'svn ls' and 'svn cat') and port the Subversion module's repository browser to use Version Control API functions.