about CVSROOT scripts and certain ideas about the conversion

Hello all,
first of all, I'd like to offer my help in the migration, thus I'm 
posting on this list. Second, I've been looking at the current 
authentication / commiting system we have running, and decided to share 
my views about it, so here goes.

Currently:

* When someone wants to UPDATE / CHECKOUT a tree, (s)he simply logs in 
(anonymously or with an account) and checks it out. There is no actual 
checking of anything involved, and it is always allowed.

* When someone wants to COMMIT a change, the system calls:
1. the commitinfo hook, which calls:
    1.1 the CVSROOT/cvs_acls (perl) script, which checks the 
CVSROOT/avail file to make sure the commit is allowed in this place by 
this user. The default is set to _not allow_ any commits at all; 
basically a whitelist.
    1.2 the CVSROOT/commitinfo.pl script which I'm not sure what it's 
supposed to do. From what I can see, it seems to be used to deny access 
to certain branches (ie. disallow commiting to PHP 4.3, forcing to 
commit to 4.4)

2. the loginfo hook, which:
    2.1 checks what path the commit was made to, passing on a matching 
mailinglist and the log to:
    2.1 the CVSROOT/loginfo.pl (perl) script, which:
       2.1.1 checks for the presence of specific tags (currently only 
[DOC] and [SECURITY])
       2.1.2 sends the log to the specified list, cc'ing phpdoc@ or 
security@ if marked in the previous step; this is done via a direct 
connection (pipe) to the SMTP server.


Right, so now we know what happens currently, under the hood. Since 
we're switching over anyway, we can now think of what to do next. Do we 
wish to keep the system as it is? or do we wish to make changes to it?

Now, a couple of things I've been thinking about:
1. SVN has anonymous read-only access built-in. Do we wish to keep it at 
that? or de we also want to add a separate login (similar to the cvsread 
login) to allow read-only access on.

2. On what basis do we wish to make access rules. By this I mean:
    2.1 We could group them by paths like we do now (ie. access is 
disallowed to all, but allowed to /phpdoc for certain individuals, 
/php-src for others, etc.). The basic component here is based on the 
PATH. This could pose a problem if we change the structure a lot. If we 
make a structure like:
  /TRUNK
  /BRANCHES
  /RELEASES
We'd need duplicate rules for /TRUNK _and_ for /BRANCHES, which would 
need to be copied over for each BRANCH when a new one is added (_major_ 
pain in the ass, assuming people will branch more than we currently do!)
    2.2 We could group them by giving each section a specific property 
(svn uses properties), thus when we make a new branch, we could set the 
property svn:editors to ie core,pecl which would then be expanded to the 
actual userlist. Not being in any of those groups denies access, while 
being allows. Because the properties would remain static, we'd only need 
to store all the user-groups with their assigned users in one place.
    2.3 We could try other ways, but these are the only two that come to 
mind currently. I'm sure others can suggest other ways aswell.

3. Of course since we'll probably be using authz-db system, making all 
my commenting pretty much moot :)

4. Do we want to keep using the perl scripts for the hooks in SVN 
aswell? In my opinion we could just aswell use PHP scripts for it; 
personally I find perl scripts to be hard to work with, but that's 
simply because I'm not a big fan of perl. In my opinion we should stick 
with PHP, like we did with the test-suite, which seems to work just 
fine. Even though it was not specifically designed to handle this.

5. The current tagging-system in loginfo is hardcoded. We could have it 
retrieve such tags from a separate file, making adding tags a lot 
easier. Currently I can't think of any tags that might require adding, 
but possibly in the future people might want to add ie. a [SITE] or 
[WEBMASTER] type of tag.

6. I don't know how the passwords for CVS accounts are stored, I'm 
pretty sure it's using a passwd file, which is automatically checked 
against by CVS. SVN does not have this option as far as I know, but 
instead wants them as plain-text passwords stored in a separate file. 
Will we be able to convert it easily? I don't know, but it's worth 
thinking about before we start.

7. We should add a list to the wiki with each script, it's purpose, and 
how far we are with converting it. I guess 
http://wiki.php.net/vcs/cvs_related_scripts can be expanded to do that 
though.

Well, I'll shut up now, as I've said quite a lot, though after rereading 
it, half of it seems moot to me. Hopefuly this'll spark a bit of discussion.

- Tul