Split Trunk

[Anders F Björklund]

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