Juan, I agree with pretty much everything you've written here. On Apr 24, 2007, at 18:15, Juan Manuel Palacios wrote:
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.
Excellent.
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,...}
[snip]
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.
Having "released" and "testing" ports trees sound like a good idea.
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? ;-)
What is the deal with the PortSystem value? :) When does that get incremented? What happens if/when it does?
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.
I can't think of any other trees we would need at this point, and I would even discourage the creation of arbitrary trees at anyone's discretion, without some compelling reason. But at least the directory structure you propose would certainly enable an arbitrary number of trees, should we find we need them.
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.
Does selfupdate get the new sources directly from the Subversion repository? Somehow I thought rsync was used for that too, and that there was therefore some level of abstraction between the repo and the selfupdate command such that reorganizations of the repository would not pose a problem. If it currently does come directly out of the repo, it might be beneficial to separate that conceptually, so that reorganizations of the repository do not break any future selfupdate procedure. Do we currently have the ability to configure our MacPorts installations such that selfupdate will download and build the latest version from trunk, rather than from a released branch? That's a capability that I think would be good to have (or keep) for developers.
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}
Moving www, faq and guide to a legacy directory sounds like a good idea to me, since it makes it clear that these parts are no longer in active development nor do they represent the current state of, for example, the web site. I don't think there should be a "docs" directory, however. I recommend: repository/legacy/faq repository/legacy/guide repository/legacy/www
PS: Yes, I'm also emphasizing the new ports directory should be called just that, "ports", and not "dports" nor "mports" :-P
Agreed.