Re: [SVN-MIGRATION] about CVSROOT scripts and certain ideas about the conversion

One nice thing about svn is that you can check out as any user  
(including an anonymous user) but commit as yourself.

PHP accounts are stored in a mysql database and a process converts  
this to a file that cvs can use.  With svn the authentication could be  
carried out by apache directly against the database using an  
mod_auth_mysql or equivalent... but since the database machine != svn  
machine we should have a local copy of the credentials to work from to  
avoid grinding to a halt if master goes offline or suffers from a  
power outage (which is pretty common :-/)

--Wez.

On Aug 1, 2008, at 6:53 PM, M. Sokolewicz wrote:

> 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
>
> -- 
> SVN Migration Project Mailing List (http://svn.php.net)
> To unsubscribe, visit: http://www.php.net/unsub.php
>