Project tracking and releases using Subversion

Hi Everyone

For the past few months, I've been working on a fork of the cvslog and project* modules to be able to use them with subversion instead of cvs. After consulting with dww, maintainer of these modules, I learned that someone (jpetso) had applied, and by now has received, a Google SoC position for creating an RCS abstraction layer. Eventually, such a layer would presumably make it a little easier to use a version control system other than CVS.

Since I needed to use subversion sooner rather than later, we decided that I would do an initial fork and try to get everything working with subversion. The changes I had to make to get subversion working would be help jpetso to know what needed to be changed and what could stay the same. My goal was to change as little as possible, and so I didn't change any function names or t() strings. I am using the locale module to take care of "translation" of CVS-->SVN and various other string changes. I also didn't need to change any of database tables, though the content that's stored in them is slightly different. I don't think subversion has an output for the # of lines added or subtracted, so those items aren't included. The value now stored in the # lines added field is the previous revision number. I think that's the only database change that was major. For everything else, the quantity stored in the field is the same or very similar to what is used in cvs.module.

I've attached all of the scripts and files I needed to change to get this working (I think). Change the extension to .zip after you download the file. Here's a summary of what needed to be changed:

1. Surprisingly, the cvs.module itself didn't need to be modified that much. The cvs_fetch_repository() function has been changed to call the svn binary properly. Note: I couldn't get cvs_use_file == 1 to work, but I'm not sure if this is due to my web host having security settings that block it from working. The other major change in cvs.module was to the cvs_process_log (now cvs_process_svn_log()) function. The subversion log XML parsing of this was taken from the subversion.module file created by halkeye. I also added a few ancillary functions as needed, such as cvs_get_svn_tag().
2. My web host doesn't support subversion over webdav, so I have to use svnserve. Because of that, I have to store subversion user passwords in plain text in my passwd configuration file. Since cvs.module passes passwords from the CVS application form through crypt(), I wouldn't have a way to give the user access to my repository. So, I now pass the passwords through str_rot13() to at least obfuscate the password. The clear text password can be seen in the CVS accounts page by clicking the Export tab.
3. The xcvs scripts were the hardest part of the conversion. Subversion and CVS are just fundamentally different in several ways, and so shoehorning the way that subversion works into the established database structure set up for cvs was a little tricky. Subversion uses revisions, and doesn't track modifications to individual files by keeping version numbers for the files. Furthermore, subversion handles branches and trunks in a somewhat more informal way than cvs does, and so there aren't any commands (AFAIK) for extracting the branch or tag of a certain transaction. The subversion book recommends keeping a /trunk, /branches, and /tags directory under the main directory for each project. Branches and tags go in their own directory under that hierarchy (eg. /branches/DRUPAL-5--1 or /tags/DRUPAL-5--1-6-beta). My scripts require such hierarchy to get branches and tags right.
4. I'm not sure if this is true of cvs, but svn allows you to use pretty much any type of script as a hook script. Since I'm most familiar with PHP, that's what I used for my subversion pre-commit and post-commit scripts. Those scripts should go in the hooks directory within your subversion repository. Make sure to make them executable.
5. Another nice benefit of subversion is that all commits are atomic. So, that allowed me to move some of the processing of a commit into the pre-commit script, but keep most of the logic and permissions in the xcvs scripts. If at any time the xcvs script(s) called by the pre-commit script gives an exit != 0, then the commit won't happen. I think subversion has a hook that is called even earlier than pre-commit, and which could be used to determine if the user has permission to commit, but without knowing what files were changed (and therefore which project node the commit affects), the script wouldn't know whether to accept or deny. So, the slight downside is that a commit with a lot of changes might get denied, but only after all of the changes were uploaded to the repository. But, since svn is more efficient with commits anyway, I don't see this as a big issue.
6. You'll notice that I included bootstrapping of the Drupal database in the xcvs scripts. This is nice since my database tables all have prefixes.
7. I modified the package-releas-nodes.php file to package from a subversion repository instead of cvs. I wanted files saved as .zip files on my site, so I've made that modification. I'm also not keeping Drupal code, so I removed some of the code to take care of that. I also have to run the script as a real web process (via a browser or wget) instead of from the command line, because my host's configuration of php5 from the command line doesn't work right.
8. Because of the above restriction, I changed the shebang lines to match the path of php5 on my host. You may need to change those back to /usr/bin/php or something similar.

Note: Though I have run some tests with this code, I wouldn't say it's close to being stable yet. Furthermore, though I've tried to code in a security conscious manner, I don't have a lot of knowledge about security issues WRT PHP, etc., so I can't promise the scripts are as secure as they should be.

I'm not planning on making this into a module of my own, because:

• I don't have the time to fully maintain it
• It's so close to the official cvslog module that it doesn't really make sense to have two separate modules that do almost the same thing
• As I mentioned before, jpetso is going to work on the RCS abstraction layer this summer, and so hopefully his work will make maintaining two separate RCS modules unnecessary

With that being said, I'm happy to answer questions people have about why I did something one way versus another, and generally how things work. Outside of the xcvs and hook scripts, I'm really only familiar with the code that I modified, so don't ask me about how cvs.module or the project* modules are working outside of where they interact with svn.

On the same note, I'm glad to hear comments/criticisms of the changes, especially related to security problems. I will be using this code on a production site in the somewhat near future (at least until the RCS abstraction layer is completed), and so if there are problems I'd like to know about them.

I hope these changes are useful to some of you out there.

Adam