Proposal for a new repository layout

[Juan Manuel Palacios]

	Evening everyone! Earlier today I created a branch called "dp2mp- 
move" where I plan to work on finally moving everything related to  
the MacPorts project over to the new name (and appropriate  
equivalents), finally dropping legacy naming and conventions we're  
still dragging along. For more information on the branch and my  
goals, you can read the (rather extensive) initial commit log at:

http://trac.macports.org/projects/macports/changeset/24454

	One of the main goals I'll pursue with this work is designing new  
distribution means to get both our base sources and ports onto users  
hands, allowing for enough room to grow in every necessary way and  
direction. Pivoting on this, I would like to propose a redesign of  
our existing svn repo layout. Currently we have the following:

branches/ (bunch 'o branches here)
distfiles/
downloads/
tags/ (bunch 'o tags here)
trunk/{base,docs,dports,www}
users/

	Which is mostly the result of combining our OpenDarwin & cvs  
inheritance with svn defaults, without much thinking put into it. I  
believe this layout doesn't suit us well at present for various  
reasons, which I'll try to explain following. First of all, the trunk  
& branches & tags default svn hierarchy works in our case only for  
the base directory, which is the only one we ever branch and/or tag;  
secondly, having dports inside trunk is misleading at best,  
mistakenly hinting that our Portfiles can (or even "should") stay in  
sync with trunk/base when in reality they should be tied to branches/ 
release_x_y (whatever is currently shipping). These inconsistencies  
(and the resulting "Portfile works with trunk Vs. Portfile works with  
release" diatribe) are what's pushing me to relocate both trunk/base  
and trunk/dports.

	First and foremost, I propose we make our use of trunk & branches &  
tags for base only as explicit as it can be, and therefore reorder  
the existing hierarchy as follows:

repository/base/
repository/base/trunk
repository/base/branches
repository/base/tags

	Other than base now being a top level dir (emphasized by listing  
"repository/" in my explanation) and having only MacPorts sources in  
the directories therein, their usage would still be the self- 
explanatory svn standard, so nothing would change on that respect.

	The ports tree would also become a top level dir in our repo,  
"repository/ports", packing yet another surprise we could leverage as  
we see fit and need: multiple ports trees! Some examples:

repository/ports/released/{categories,...}
repository/ports/testing/{categories,...}

repository/ports/panther/{categories,...}
repository/ports/tiger/{categories,...}
repository/ports/leopard/{categories,...}

	Or whatever else comes to your mind we might need at some point,  
depending on the project and users needs (agreed that we have  
platform declarations, so maybe the latter example is not the best  
one). We would of course have to reach some consensus not only on  
what trees we carry (we might need per OS trees, we might not), but  
also on their naming. With this I'm mostly aiming at the following:

repository/ports/released/{categories,...}
repository/ports/testing/{categories,...}

	I propose we start with those two trees and fill them up as  
necessary, the first one being the existing trunk/dports which would  
*have* to stay in sync with base/branches/release_x_y and the second  
being a testbed for Portfiles that need unreleased features and  
syntax to function (ports would be added to it as needed, no need to  
mirror every single category and port in ports/released if the  
corresponding Portfile doesn't pack anything different). I would like  
to make clear that our released Vs. testing split would be with  
respect to our *Portfiles* and not to the projects we port; that is,  
emacs and emacs-devel would still be in the released tree as long as  
their Portfiles are in sync with MacPorts released code. This is  
contrary to the a la Fink "stable" Vs. "unstable" model, which we all  
know condemns stable to always be incredibly out of date and pushes  
everyone to use the unstable tree, while alerting users their  
computers could catch fire. Getting a bit ahead of myself, Portfiles  
in the testing tree could be free to declare a different PortSystem  
value, to signal they need a special MacPorts release to function...  
but said functionality is still not in our code (Eridius? Landon? ;-)

	Users and committers would be free to suggest the creation of  
whatever justifiable new tree they find appropriate. Making all of  
them available through svn and sync (rsync) and whatever else would  
be immediately beneficial to all, I'm sure it's easy to appreciate.

	Such rearrangements to our repo would of course require changes in  
our source code to upgrade existing installations to leverage them  
(for instance, the selfupdate procedure hardcodes the path to the  
sources and therefore would break if we change that under the hood  
c.f. branches/release_1_4 initially missing the base directory  
level), but I believe the results will be well worth the effort. What  
I would like to do here is reach consensus on the best possible repo  
redesign (which I'm hoping does take place!) so that we see ourselves  
in the need to upgrade users only once.

	Lastly, the doc and www dirs currently inside trunk could be moved  
to a "legacy" (detention!) top level dir too (and pulled out of it  
once brought into the light again ;-)

repository/legacy/docs/{www,faq,guide}

	So, thoughts? Opinions? Ideas? Flames...? Hit your reply-all button  
in all of those cases ;-) (that is, don't remain quiet! :-P) Regards,...


-jmpp

PS: Yes, I'm also emphasizing the new ports directory should be  
called just that, "ports", and not "dports" nor "mports" :-P