Re: [SVN-MIGRATION] Argh!

> She was saying that this is not how svn is usually organized, but
> looking around I see other large projects doing that.

As a svn user, the current layout is intuitive to me..  However, the
svn book discusses the KDE repository layout as a valid and common
one.  It is just not the layout they recommend.  Link here:
http://svnbook.red-bean.com/en/1.5/svn.reposadmin.planning.html#svn.reposadmin.projects.chooselayout

> for $i in `svn ls http://svn.php.net/repository/pecl`; svn co $i/trunk

I am not sure why you would not want the branches.  If a branch is
active, any change to trunk needs to be merged into the branch.  If a
branch is inactive it should be removed via 'svn delete <branch>'.  It
will still exist in svn if someone wants to go back and look at old
branches, but it will not be present when people checkout HEAD.  Tags
are special forms of a branch, so the same thing applies.

> WHAT 3rd-party apps? Without proof this point is also moot.

I cannot think of a problem with 3rd party applications.  TortoiseSVN
and all of the reputable web viewers can work with any repository
layout.  Even git svn clone works on weird repositories, it just makes
it harder to work with.  There may be something out there I am not
aware of, but SVN does not enforce a layout and usually 3rd party
applications follow suit and don't enforce one either.

Is there still serious consideration about restructuring the layout?