User Account Management: provide account import/export

Commit restrictions should be reasonably straightforward to implement. If you want to help with the implementation, there's two templates that you can use in order to get an idea of how this should be written:

• The xcvs-* commit hooks in the CVS backend (cvs.drupal.org link) implement this in a relatively complete way for CVS already. The challenge would be to parse SVN's hook arguments instead of CVS's, and transform into the same commit/item array format that the CVS backend hooks use as well (with minor changes like passing the real revision number as 'revision' property of the commit array, instead of an empty string for CVS).
• Adam Light has implemented SVN commit hooks for the "old" cvs.module, available as project_svn_acl_0.zip in the attachments of this post. cvs.module commit hooks look quite similar to Version Control API ones due to the fact that the latter are derived from the former, so while I shuffled a bit of code around in the CVS backend's hooks, the overall structure and approach are pretty much the same. If you can port Adam's SVN code to the CVS module's structure then it'll make for a working set of SVN backend commit hooks.

Note that Version Control API's commit hooks only control access itself, but they don't directly do the checks for directory/project access and the likes. That is handled by the Commit Restrictions module (for plain directory based access control) and/or the Project Node Integration module (versioncontrol_project, for project node based access control). versioncontrol_project's support for branches with different directory names is not yet written, but if it happens then it should go into that module.

As for user account management, I summed up my thoughts in this article and came up with a plan in this issue. In short, I'd like to decouple user authentication from the backends because a couple of authentication methods exist for all of Subversion, Git, Mercurial and Bazaar. So an SSH-keys authentication backend would just say "I can take care of authentication for SVN, Git and Mercurial" and Version Control API would present it as an option for repositories of those backends. That issue is on hold though because I'm still busy with the 2.x release of Version Control API, hopefully we'll see improvements in the authentication infrastructure during adebar's Summer of Code project.

For now though, it would be perfectly possible to implement a simple passwd-Exporter like the one in the CVS backend, that would at least work for svnserve setups. Should be relatively easy (and I think Adam Light has also something similar in the afore-mentioned SVN port of Project*), but again I'm currently out of time and can't take this on at the moment.

@smokris: Instead of the link jpetso gave above, use the attached files. These are more recent. I wrote these when I was first learning Drupal and PHP, so they are fairly rough, but they do work. Essentially what I did was to fork the cvslog module on d.o and just did minimal modifications to get things to work with Subversion instead of CVS. I didn't change any function names or strings, but rest assured that in the attached file when I say CVS it really means SVN. These scripts also work with the database structure used by the cvslog module, with two minor changes. I think I added one field to the {cvs_files} table and I'm also using the {cvs_files}.lines_added field for another purpose, since I couldn't find a way with SVN to get the lines_added and lines_removed information in the first place.

I should add that I'm using these commit scripts with svnserve on my server. I tried using them with svn served via apache, but for some svn operations, such as copy, I was getting strange but not helpful error messages at certain times. I couldn't figure out if these were due to a problem with my scripts or if there was a bug in svn or the apache bindings.

I also have a simple script that runs via a cron job that queries the {cvs_accounts} table and writes the passwords stored there into my /usr/local/subversion/repository/conf/auth file. Since svnserve only supports plain text passwords, I had to modify some code in cvs.module so that the password stored in the {cvs_accounts}.pass field is not encrypted.

Commit restrictions have been implemented by chrono325 as part of #491544: Add hook scripts to subversion. Let's therefore narrow down the scope of this issue to just user account management.