Split Trunk

[Juan Manuel Palacios]

On Oct 5, 2007, at 4:03 AM, Anders F Björklund wrote:

> 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)


	It's a matter of approaches. I just don't like the Fink Stable Vs.  
Unstable approach and, although not recently, the inability to use  
unreleased features in our Portfiles is something that has concerned  
many of us repeatedly, as it severely hinders our testing abilities.  
Therefore, a "trunk", "testing" or whatever tree for Portfiles that  
work with base' trunk at any moment (without the constraint of not  
breaking use installations) seemed like a good approach to me. I  
should emphasize again that said approach does *not* aim at testing  
ported software versions, e.g. the latest rpm5 alpha build, but  
MacPorts unreleased features instead. But,...

>
> Normally you'd even have a security branch that leads to  
> backporting things for old releases.


	My proposed model leaves open room to grow any number of port trees  
we might ever need, including "security" and even Stable Vs. Unstable  
of for whatever reason we deem it appropriate one day ;-)
>

---snip---


>
> 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.


	Agree, totally platform blocks for the win! I only used the platform  
trees as examples of what we could do should we ever need to, based  
on my proposed reorganization. Exporting any of these trees to users  
would also be as simple as adapting the base/portmgr/mprsyncup script  
to server them. But,...

>
> 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).


	Yeah, a regular user should only see the need for using a single  
tree, the one we would serve up by default ("release"), unless very  
specific needs drove him/her some secondary tree for whatever reason  
(e.g., a MacPorts developers wanting to test with real life Portfiles  
a new feature that hasn't been released ;-) But I'll now stop  
insisting on that, I just liked the idea of being able to create any  
number of trees should we ever need to.

	As for binaries, we will need to have platform specific trees, but I  
don't see those belonging in SVN (ftp, webdav, plain HTTP, whatever,  
but not SVN) so this particular part of the discussion may be out of  
scope [1].

	Regards,...


-jmpp

[1] Some people have suggested before we pull the ports tree out of  
svn entirely, but I disagree with that. Having history tracking for  
Portfiles and being able to see how they have evolved is a very big  
plus in my opinion, but that argument does not apply to packages, I  
believe, as they are simply the end result of the Portfiles... for  
which we have history tracking ;-) And as for tracing the builds....  
you guessed it: http://trac.macports.org/projects/macports/wiki/ 
PortLoggingProposal (specially the part on post-processing of the  
logs into tabulated web pages).