[os-infrastructure] piccolo discussion, was: Model discussion boiled down

[Jay Hankinson]

Joe is absolutely correct here. To simplify the map file we just have to 
branch to a simpler structure. The reason it's such a mess is that when 
we first went open source, we made the decision to move from having 3 
distinct source tree versions (unix, vms and Windows) to 1 common 
layout. The only way to achieve this was to move stuff into the 
"on-disk" structure we currently have using directory and fmaps.

J
Joe Abbate wrote:
> Hi Chris,
>
> Chris Clark wrote:
>> Can any one comment on how big a job this is (is it even possible)? 
>> The 2 big areas that jump out are:
>>
>>   1. removal of fmaps (we have around 120)
>>   2. moving directories around (e.g.
>>      ingres!ingres2006r2!generic!front!st!specials would be
>>      /SRC/generic/front/st/specials) we get a new higher level dirs and
>>      we then loose the special_unix dirs
>>
>> Are there others? J, you're my build Meister, any thoughts?
>
> There are plenty of others.  ingres!main!generic!front!st!specials is 
> mapped to front/st/specials_unix_vms, so to flatten it, we would have 
> to branch all the files in it to 
> ingres!community!ingresdb!front!st!specials_unix_vms.  The CL is where 
> most of the flattening would occur, for example,
>
> ingres!main!unix!cl!clf!cs  branch to 
> ingres!community!ingresdb!cl!clf!cs_unix
> ingres!main!alpha!cl!clf!cs  branch to 
> ingres!community!ingresdb!cl!clf!cs_vms
> ingres!main!wnt!cl!clf!cs  branch to 
> ingres!community!ingresdb!cl!clf!cs_win
> ingres!main!unix!cl!clf!cs  branch to 
> ingres!community!ingresdb!cl!clf!csmt_unix
>
> The above is obviously a representation of the "controlled" or 
> "buffer" approach, and makes allowance for ingres!community!empire!* 
> to come along.
>
> It may be redundant for most on this list, but I encourage anyone who 
> hasn't seen the full output of "p sdirs" to look at it.  Some people 
> seem to talk about "main" as if it were some special entity that 
> Piccolo knows about and treats differently, but it's just another 
> branch, on equal footing with all others, just like an svn trunk is no 
> different from svn branches/tags.  It's how we use the branch that 
> makes a difference.
>
> Joe
> _______________________________________________
> opensource-infrastructure mailing list
> opensource-infrastructure at lists.ingres.com
> http://lists.ingres.com/mailman/listinfo/opensource-infrastructure