Re: To late to rename /repository/web modules?

On Jul 18, 2009, at 7:53 PM, Hannes Magnusson wrote:
> Hi Gwynne^Wall
>
> Is it to late to rename the modules under /repository/web ?
>
> The "php-" prefix feels redundant and in fact has become quite  
> annoying :)
>
> We currently have:
> doc/
> doc-editor/
> embed/
> pecl/
> pecl4win/
> php/
> php-bugs/
> php-gcov/
> php-hosts/
> php-master/
> php-news/
> php-people/
> php-testfest/
> php-wiki/
> php-windows/
> pres2/
> presentations/
> qa/
>
> I'd like to drop all the "php-" prefixes, and rename the "php" module
> to either "www" or "web".
>
> I severely doubt that many people have this checkedout out already(or
> ever will), so "client side" breakage is very small, so the question
> becomes: is it possibly without fuckingup svn?

A few "svn mv" commands would easily handle the renaming. Of course,  
this would re-break rsync, which Derick finally managed to get working  
(big round of applause to Derick, people, he put in a good bit of  
effort and patience on that front). I happen to agree that your naming  
scheme would be better (although just "www" for what's currently  
phpweb would be very ambiguous, since there're non-strictly-website  
modules in there), but I don't know if it's worth the hassle at the  
moment. I call for thoughts from the list on this.

> -Hannes
>
> p.s. what exactly do we call module these days?
> do we call all /repository/xxx modules?
> so /repository/php is a module, and /repository/php/php-src is what?
> Or is /repository/php/php-src the module, and /repository/php is just
> the "group"?
> /repository/phd is a module, /repository/php/php-src is a module,
> /repository/php/phpruntests/ is a module, and /repository/php/ is
> just.. "a group"..?


/repository/ -> "the repository"
SVNROOT plus anything with tags/, branches/, trunk/ in it ->  
"module" (common usage) OR "project" (SVN's official terminology)
Anything above a module -> "organizational structure", or simply  
"folder" :P

The top-level directories are pretty much aribtrary organizational  
conveniences. There's absolutely no intrinsic meaning to them.  
Ideally, they have conceptual meanings, i.e. "php/ contains everything  
directly related to core PHP development", "web/ contains all the PHP  
websites", "phpdoc/ contains everything related to core php  
documentation", etc. In practice, these are a bit blurry. web/  
contains peclweb (but not pearweb), docweb (but not gtk-web), and so  
forth. phpdoc/ contains doc-base and the language modules, but not  
docweb. You get the idea. The current setup is the best I could manage  
under the constraints of mostly no one telling me what made sense and  
people yelling at me to change things around at the 11th hour, 59th  
minute, and 50th second. It's fairly obvious that considerably more  
progress could be made in this vein. It's also deeply complicated by:

1) The fact that you can't move anything smaller than a module around  
(short of extremely complex scripting), so that (for example), the  
PECL extensions that were moved into php-src can't be effectively  
moved back out again while preserving the tagging and branching. This  
is partially a limitation of SVN, but more practically a limitation of  
conceptualization: If something that was part of an existing "project"  
before becomes its own "project" later, it's expected that you'll do  
some mv/cp work to set up the trunk of the new "project", let your  
VCS's copy-tracking point you to earlier history, and apply fresh tags  
and branches to the new "project" as needed rather than trying to ape  
the original "project"'s. The fact that SVN's branches-and-tags-are- 
directories thing complicates this a lot more than is otherwise  
necessary is peripheral.

In general, the tags-and-branches-are-directories thing fits very  
poorly into PHP's existing workflow. This is primarily and foremost  
because our workflow has for at least 13 years evolved around CVS's  
way of doing things; SVN represents a paradigm shift. Not as big a  
shift as Git would have been, but a shift nontheless.

Nonetheless, I'm the last person to argue that SVN needs to have done  
it more like CVS did.

2) The fact that people don't like dealing with changes which disrupt  
their workflow. Moving things around in a repo means forcing people to  
svn switch --relocate, or in some cases create entirely new checkouts.  
It also means making them update their scripts which make (reasonable  
and necessary) assumptions as to repository layout. The more, and the  
more often, you change things, the more upset people are going to be.  
At this point we *might* have enough lattitude to make one more major  
set of changes before people get too sick of scrambling to keep up to  
bother. In order to maintain even that much, the changes need to be  
carefully thought out and clearly beneficial.

3) The fact that several of these top-level abstractions could really  
stand to be independant repositories altogether. This was bandied  
about all the way back at the start of the migration, but ultimately  
rejected as adding an entire new layer of complexity to just about  
everything. Yet at the same time, it's clear that some things have  
grown too large to comfortably fit within the abstraction of our  
single repository. PHP-GTK is one of them. libgd is another (and  
Pierre is already looking into moving that out of our repo  
completely). It's questionable whether systems/ should *ever* have  
been part of a public repo, and it would have made a lot more sense  
for SVNROOT/ and systems/ to be part of an independant setup (though  
it would have complicated the layout of SVNROOT/ itself a bit).  
phpdoc/ is also large enough to be counted as its own entity at this  
point.

There are a lot of issues to consider and a lot of organizational  
problems that I don't feel we're all that likely to ever work out,  
based on past experience. People don't seem to really care if it works  
cleanly, so long as it "just works" (*cough Jani cough*). Ultimately,  
we'll come up against the blank wall of complexity problems. An SVN  
repository with 284345 revisions is just insanely huge. GCC converted  
their *twenty-year-old* CVS repo to SVN back in 2005 or so, and since  
then they've only made it to SVN revision 149787. It's questionable  
whether SVN scales to such a huge repo; certainly we've already seen  
some speed issues that even stateless HTTP can't explain away.

-- Gwynne