<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
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.<br>
<br>
Bob<br>
<br>
Jason Birch wrote:
<blockquote
 cite="mid8E468917B01800408B91984428BE03DD05853033@starfish.nanaimo.ca"
 type="cite">
  <meta http-equiv="Content-Type" content="text/html; ">
  <meta content="MSHTML 6.00.5730.11" name="GENERATOR">
  <div dir="ltr" align="left"><span class="854135220-15012007"><font
 color="#0000ff" face="Arial" size="2">Is there a reason why you are
staying with multiple SVN instances, instead of merging&nbsp;the&nbsp;providers
into the core and managing access at the node level?</font></span></div>
  <div dir="ltr" align="left"><span class="854135220-15012007"></span>&nbsp;</div>
  <div dir="ltr" align="left"><span class="854135220-15012007"><font
 color="#0000ff" face="Arial" size="2">I'm pretty sure that Trac
instances have to have a 1:1 relationship with SVN repositories.</font></span></div>
  <div dir="ltr" align="left"><span class="854135220-15012007"></span>&nbsp;</div>
  <div dir="ltr" align="left"><span class="854135220-15012007"><font
 color="#0000ff" face="Arial" size="2">Jason</font></span></div>
  <br>
  <div class="OutlookMessageHeader" dir="ltr" align="left" lang="en-us">
  <hr tabindex="-1"><font face="Tahoma" size="2"><b>From:</b>
<a class="moz-txt-link-abbreviated" href="mailto:fdo-internals-bounces@lists.osgeo.org">fdo-internals-bounces@lists.osgeo.org</a>
[<a class="moz-txt-link-freetext" href="mailto:fdo-internals-bounces@lists.osgeo.org">mailto:fdo-internals-bounces@lists.osgeo.org</a>] <b>On Behalf Of </b>Robert
Bray<br>
  <b>Sent:</b> Monday, January 15, 2007 12:51<br>
  <b>To:</b> FDO Internals Mail List<br>
  <b>Subject:</b> Re: [fdo-internals] More Site Cleanup<br>
  </font><br>
  </div>
Mateusz,<br>
  <br>
Good suggestion. For the tools maybe we can create an fdotools
subversion instance unless someone out there has a better idea.<br>
  <br>
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.<br>
  <br>
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?<br>
  <br>
Bob<br>
  <br>
Mateusz Loskot wrote:
  <blockquote cite="mid45ABD020.6050808@loskot.net" type="cite">
    <pre wrap="">Robert Bray wrote:
  </pre>
    <blockquote type="cite">
      <pre wrap="">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?
    </pre>
    </blockquote>
    <pre wrap=""><!---->
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.

  </pre>
    <blockquote type="cite">
      <pre wrap="">Also I am pondering the general navigation of the site. I am all ears if
anyone has recommendations for improving it.
    </pre>
    </blockquote>
    <pre wrap=""><!---->
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 (-&gt; Trac)

- Community
-- Mailing lists

- Development
-- Road Map
-- Trac
-- SVN


Cheers
  </pre>
  </blockquote>
  <br>
  <pre wrap="">
<hr size="4" width="90%">
_______________________________________________
fdo-internals mailing list
<a class="moz-txt-link-abbreviated" href="mailto:fdo-internals@lists.osgeo.org">fdo-internals@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/fdo-internals">http://lists.osgeo.org/mailman/listinfo/fdo-internals</a>
  </pre>
</blockquote>
<br>
</body>
</html>