Proposal for a new repository layout

[Ryan Schmidt]

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.