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