[fdo-internals] More Site Cleanup

[Paul Ramsey]

You can actually use filters on the post-commit hooks to provide 
different actions for different subdirectories of the repository. If 
they code bases were fully merged, however, that would become rather 
intractable.  If they were just directories in the same respository

/fdocore
/postgis
/oracle

then you could provide ACL and different post-commits pretty easily.

P

Robert Bray wrote:
> SVN can only provide access control, revisions, mailing list, etc at the 
> repository level. So to merge them into one repository would mean the 
> commiter list would need to be the same for all of FDO. I don't really 
> have an issue with that approach, but that is not the way it is setup 
> currently.
> 
> Bob
> 
> Jason Birch wrote:
>> Is there a reason why you are staying with multiple SVN instances, 
>> instead of merging the providers into the core and managing access at 
>> the node level?
>>  
>> I'm pretty sure that Trac instances have to have a 1:1 relationship 
>> with SVN repositories.
>>  
>> Jason
>>
>> ------------------------------------------------------------------------
>> *From:* fdo-internals-bounces at lists.osgeo.org 
>> [mailto:fdo-internals-bounces at lists.osgeo.org] *On Behalf Of *Robert Bray
>> *Sent:* Monday, January 15, 2007 12:51
>> *To:* FDO Internals Mail List
>> *Subject:* Re: [fdo-internals] More Site Cleanup
>>
>> Mateusz,
>>
>> Good suggestion. For the tools maybe we can create an fdotools 
>> subversion instance unless someone out there has a better idea.
>>
>> In general I like your navigation approach. Where I am getting caught 
>> up is our multiple SVN instance thing. Right now we have fdo, fdocore, 
>> fdosdf, etc. Many of our pages have a provider list on them and each 
>> time we add a provider we have to touch a bunch of different pages. An 
>> alternative approach is to break the site down by provider. That is 
>> have a main page for FDO, which links to sub-pages for the various 
>> providers and all of their relevant information. Then when we add the 
>> PostGIS provider instead of updating a ton of global pages all we have 
>> to do is add the relevant pages for the PostGIS provider. Today we 
>> have a mix of these two models, which feels really weird to me.
>>
>> BTW - Any idea how Trac integrates with multiple SVN instances? Will 
>> we need separate Trac projects for each provider or can we have a 
>> single Trac project that links to multiple SVN instances?
>>
>> Bob
>>
>> Mateusz Loskot wrote:
>>> Robert Bray wrote:
>>>   
>>>> Haris,
>>>>
>>>> I restored the lost Oracle provider page and added the Oracle provider
>>>> to the table graphic on the home page. For Fdo2Fdo I was thinking of
>>>> adding a "Tools" link under "Essentials". Does that make sense to everyone?
>>>>     
>>>
>>> I like this idea.
>>>
>>> By the way, would it be possible to have some room in the FDO SVN for
>>> such tools, non-provider codes?
>>>
>>> In example, while I'm working on PostGIS provider, I'm developing some
>>> command line tools - in concept, similar to OGR utilities (ogrinfo,
>>> ogr2ogr).
>>> After I have PostGIS provider ready, I'd like to continue development of
>>> my tools and make them user friendly.
>>> So, it would be great to host such tools near the FDO code.
>>>
>>>   
>>>> Also I am pondering the general navigation of the site. I am all ears if
>>>> anyone has recommendations for improving it.
>>>>     
>>>
>>> Yes, I'd have some loose comments. Here is my proposal of structure of
>>> main links (these in the left column):
>>>
>>> - About
>>> -- Features
>>> -- Providers Overview
>>> -- Governance
>>> -- License
>>> -- History
>>> -- FDO users
>>>
>>> - Documentation
>>> -- Requirements
>>> -- Getting Started
>>> -- FAQ
>>> -- Wiki (-> Trac)
>>>
>>> - Community
>>> -- Mailing lists
>>>
>>> - Development
>>> -- Road Map
>>> -- Trac
>>> -- SVN
>>>
>>>
>>> Cheers
>>>   
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> fdo-internals mailing list
>> fdo-internals at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/fdo-internals
>>   
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> fdo-internals mailing list
> fdo-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/fdo-internals