Juan Manuel Palacios wrote:
If you guys may remember, I suggested a somewhat large rearrangement of our svn tree a while ago, but all in all I was met with quite a bit of opposition so I simply dropped it (the initiative at the time, not the desire to do it ;-).
Wasn't ready for it then, isn't ready for it now. Maybe bring it up again for MacPorts 2.0... :-) I also found the post http://lists.macosforge.org/pipermail/macports-dev/2007-April/ 001159.html
I did, however, propose a "test" tree of some sort where we would instead test MacPorts itself, freely using whatever new features/constructs that may be in our trunk base code but not in a MacPorts release at any moment; currently, any new MacPorts feature has to wait for a new release before being adopted in Portfiles, which hinders our ability to test. "mysql5" and "mysql5-devel" ports would both live in the "release" tree if they work with whatever MacPorts release is current, but (a copy of) any of those would have to move to the "test" tree if the corresponding Portfile starts using syntax/code only available in base's trunk. Users would be free to use the "test" tree against base's trunk or the recommended "release" tree against the current MacPorts release.
This is somewhat similar, except that "test" and "development" moves in opposite directions... i.e. your ports gets pushed from release to "test" when needed for testing features, whereas the "development" tree gets pushed to "release" once released (possibly even getting some testing inbetween, i.e. development -> testing > release) Normally you'd even have a security branch that leads to backporting things for old releases.
But that layout is not limited to only those two trees, as any other purpose-specific tree could be created to fulfill whatever need we may have should they arise. For instance, platform specific trees could be created:
/ports tiger/ aqua/ audio/ (etc) leopard/ aqua/ audio/ (etc)
Do we really need this....? Certainly not now... but who knows if we ever do...? ;-) In any case, having the room to grow is a big plus, I believe, and we don't have it now.
I think that binaries (archives and packages) should be split by OS/major, but I don't think sources (Portfile and files/) should be unless it really really has to. That is, I prefer the "platform {}" variants. http://lists.macosforge.org/pipermail/macports-dev/2007-July/002033.html It doesn't really have to split locally (at least not until the cross-platform development features appear), but it does have to split on the server side when serving out binary packages or binary archives (i.e. pre-compiled). --anders