Re: [SVN-MIGRATION] Re: Proposed repository structure

From: Date: Tue, 02 Sep 2008 19:46:49 +0000
Subject: Re: [SVN-MIGRATION] Re: Proposed repository structure
References: 1 2 3  Groups: svn.migration 
Request: Send a blank email to svn-migration+get-64@lists.php.net to get a copy of this message
On Sep 2, 2008, at 2:37 AM, Derick Rethans wrote:
So and what's up with extensions in general? Have *all* of them in pecl/ and put them using svn:externals in "release trees"?
That I don't think is a good idea. Those extensions that we bundle should be in every normal checkout for two reasons: 1. we easily spot breaks in compilation. 2. people can use a non-release while developing projects to make sure that changes to PHP don't break their code (and v.v.) As everything lives in the same repository, I don't even know whether :externals works here (as it's not external). I think that leaving it like it is now is fine, and moving in/out pecl can just be an "svn mv" or "svn cp".
Externals can easily be cross-project instead of cross-repository; that's no issue. With an external linking things into ext/, compilation errors will be spotted identically as if they were actually there. As for using a non-release to develop, that's also handled by peg revisions in the externals declaration. With the exception of the "true core" extensions like standard and such, there shouldn't be any extensions that can't stand on their own in pecl anyway. On Sep 2, 2008, at 2:39 AM, Derick Rethans wrote:
I'd like an agreement to move stuff that belongs together together...
So would I, but as I said on IRC, I'd rather get moving with the move than argue the politics of this particular problem. If you can come up with a solution that those involved are alright with, please let me know.
I'm with Johannes here - they're an integral part, so they should go where they belong. It has been causing problems in the past (checking out php-src instead of php5 f.e.), and *not* having them in the correct places again would require scripts to put things in the correct place.
That's a valid point. Again, it's the politics I'd rather not personally deal with. I'll create the new SVN repository with TSRM and Zend merged in, but I'll be counting on you and others to handle questions of licensing and such, as I don't have the first clue about them. On Sep 2, 2008, at 8:20 AM, Marcus Boerger wrote:
1) Copy everything to SVN, it doesn't hurt having a few more things there, if they won't be used, they won't be... if they are, they are at least available. Maybe have a top level /old-stuff
This was my original proposal. I'm willing to go with it, if no one has a good reason not to.
3) Let's do /php-src/trunk/ext... php-src/branches/PHP_5_3/ext... to clarify that matter.
Agreed.
4) We should either have 'experimental' next to trunk/tags/branches or we should put experimental stuff into tags. Either way we need to control who can create tags, branches and/or experimental directories. Personally I'd favor an interface that allows select users to create directories under tags that get prefixed by username. E.g. if I used that to create a tree for the re2c lexer rewrite developemnt I'd end up with php-src/tags/helly_re2c_lexer/...
As sean pointed out, this would go under branches, not tags. Otherwise it's definitely a sound idea. Please add the "prefixed by username" idea to the Wiki pages somewhere. Meanwhile, an experimental/ directory will almost definitely go alongside trunk/ tags/ branches/ in the structure.
5) No parallel CVS supported integrated into the SVN repository. A gateway that can access SVN Data in a CVS way is nice to have. The easiest way is a cronjob that does snapshots into a readonly CVS repository.
I don't feel the need for this, but I invite discussion on whether or not it's useful. Here is the current proposed structure: obsolete/ <old projects> pear/ <pear project>/ trunk/ tags/ branches/ experimental/ <pear project>/ ... pecl/ <pecl project>/ trunk/ tags/ branches/ experimental/ <pecl project>/ ... php-src/ trunk/ zend/ tsrm/ ext/ standard/ ... <externals linked to pecl>/ tags/ PHP_5_3_0/ zend/ tsrm/ ext/
    standard/
    ...
    <externals linked to pecl>/
branches/ PHP_5_3/ zend/ tsrm/ ext/
    standard/
    ...
    <externals linked to pecl>
experimental/ php-doc/ trunk/ en/ fr/ jp/ ... branches/ tags/ experimental/ phd/ trunk/ branches/ tags/ experimental/ Yes, this gives every single PEAR and PECL extension its own branches, tags, and trunk; I feel this necessary. -- Gwynne, Daughter of the Code "This whole world is an asylum for the incurable."

« previous svn.migration (#64) next »