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

Hello M.,

Saturday, August 2, 2008, 12:53:35 AM, you 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.

Please no more Perl. SVN naturally uses Python and PHP would be fine as
well but Python seems better suited to me.

marcus

> 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