PSC Motion: Repository Merge

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

PSC Motion: Repository Merge

Robert Bray-2
As per the other thread on this topic today, I would like to officially
motion to merge all of the fdoXXX repositories into one. The structure
of the proposed repository is as follows:

/fdo    - Repository
 /trunk
  /fdodev
   /core
   /tools
   /thirdparty
   /utilities
   /providers
     /sdf
     /shp
     /...
 /branches
  /3.2.x
   /fdodev

Note that tools in this context would be tools written to a particular
release of FDO. If at some point we create one or more tools that work
across multiple versions of the FDO API then we have the option of
creating an /fdotools folder as per Paul Ramsey's recommendation. In
both cases we have the option of including the tools as part of an FDO
release, making them available as a separate release, or making them
available from SVN only.

I would like to proceed on this as quickly as possible, so please vote
within 24 hours.

Thanks,
Bob
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Reply | Threaded
Open this post in threaded view
|

Re: PSC Motion: Repository Merge

Mateusz Loskot
Perfect, even with fdodev ;-)

+1

Robert Bray wrote:

> As per the other thread on this topic today, I would like to officially
> motion to merge all of the fdoXXX repositories into one. The structure
> of the proposed repository is as follows:
>
> /fdo    - Repository
> /trunk
>  /fdodev
>   /core
>   /tools
>   /thirdparty
>   /utilities
>   /providers
>     /sdf
>     /shp
>     /...
> /branches
>  /3.2.x
>   /fdodev
>
> Note that tools in this context would be tools written to a particular
> release of FDO. If at some point we create one or more tools that work
> across multiple versions of the FDO API then we have the option of
> creating an /fdotools folder as per Paul Ramsey's recommendation. In
> both cases we have the option of including the tools as part of an FDO
> release, making them available as a separate release, or making them
> available from SVN only.
>
> I would like to proceed on this as quickly as possible, so please vote
> within 24 hours.
>
> Thanks,
> Bob
> _______________________________________________
> fdo-internals mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/fdo-internals
>


--
Mateusz Loskot
http://mateusz.loskot.net
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Reply | Threaded
Open this post in threaded view
|

Re: PSC Motion: Repository Merge

Frank Warmerdam
In reply to this post by Robert Bray-2
Robert Bray wrote:

> As per the other thread on this topic today, I would like to officially
> motion to merge all of the fdoXXX repositories into one. The structure
> of the proposed repository is as follows:
>
> /fdo    - Repository
> /trunk
>  /fdodev
>   /core
>   /tools
>   /thirdparty
>   /utilities
>   /providers
>     /sdf
>     /shp
>     /...
> /branches
>  /3.2.x
>   /fdodev

+1

(though I still don't follow the need for the fdodev level)

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, [hidden email]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Reply | Threaded
Open this post in threaded view
|

Re: PSC Motion: Repository Merge

Robert Bray-2
I am also fine with that directory just being called fdo. I just want to
make sure there is a folder there to create global branches from (e.g. a
branch that applies to all of fdo). If we can do that without the
folder, then I am happy to do away with it.

Bob

Frank Warmerdam wrote:
>
> +1
>
> (though I still don't follow the need for the fdodev level)
>
> Best regards,

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Reply | Threaded
Open this post in threaded view
|

RE: PSC Motion: Repository Merge

Greg Boone
In reply to this post by Robert Bray-2
If we accept this proposal then the requirement to use the following
environment variables would be eliminated since all source code would
reside in a single repository.

FDO
FDOUTILITIES
FDOTHIRDPARTY

Greg

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Robert Bray
Sent: Tuesday, January 16, 2007 5:53 PM
To: FDO Internals Mail List
Subject: [fdo-internals] PSC Motion: Repository Merge

As per the other thread on this topic today, I would like to officially
motion to merge all of the fdoXXX repositories into one. The structure
of the proposed repository is as follows:

/fdo    - Repository
 /trunk
  /fdodev
   /core
   /tools
   /thirdparty
   /utilities
   /providers
     /sdf
     /shp
     /...
 /branches
  /3.2.x
   /fdodev

Note that tools in this context would be tools written to a particular
release of FDO. If at some point we create one or more tools that work
across multiple versions of the FDO API then we have the option of
creating an /fdotools folder as per Paul Ramsey's recommendation. In
both cases we have the option of including the tools as part of an FDO
release, making them available as a separate release, or making them
available from SVN only.

I would like to proceed on this as quickly as possible, so please vote
within 24 hours.

Thanks,
Bob
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Reply | Threaded
Open this post in threaded view
|

RE: PSC Motion: Repository Merge

Jason Birch
In reply to this post by Robert Bray-2
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: PSC Motion: Repository Merge

Robert Bray-2
If SVN can branch without the folder, then I am happy to live without it.

Bob

Jason Birch wrote:

> How about something like this:
>
> /fdo
>  /fdo
>   /branches
>    /3.2.x
>     /core
>     /tools
>     /...
>   /trunk
>    /core
>    /tools
>    /thirdparty
>    /utilities
>    /providers
>      /sdf
>      /shp
>      /...
>
> Initially, the additional "fdo" level would be redundant.  However, this
> would mean that tools could be moved out into its own structure later,
> like:
>
> /fdo    - Repository
>  /fdo
>   /branches
>    /3.2.x
>   /trunk
>  /fdotools
>   /branches
>    /1.3.22
>   /trunk
>
> Other projects seem to be able to branch directly from trunk?
>
> http://svn.refractions.net/postgis/
>
> http://svn.refractions.net/geotools/
>
> Jason
>  
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Robert Bray
> Sent: Tuesday, January 16, 2007 15:17
> To: FDO Internals Mail List
> Subject: Re: [fdo-internals] PSC Motion: Repository Merge
>
> I am also fine with that directory just being called fdo. I just want to
> make sure there is a folder there to create global branches from (e.g. a
> branch that applies to all of fdo). If we can do that without the
> folder, then I am happy to do away with it.
>
> Bob
> _______________________________________________
> fdo-internals mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/fdo-internals
>
>  

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Reply | Threaded
Open this post in threaded view
|

Re: PSC Motion: Repository Merge

Mateusz Loskot
In reply to this post by Jason Birch
Jason Birch wrote:
> Other projects seem to be able to branch directly from trunk?
>
> http://svn.refractions.net/postgis/
>
> http://svn.refractions.net/geotools/

Yes, it's perfectly possible to do it:

svn copy trunk branches/namedtrank

Cheers
--
Mateusz Loskot
http://mateusz.loskot.net
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Reply | Threaded
Open this post in threaded view
|

RE: PSC Motion: Repository Merge

Robert Fortin
In reply to this post by Robert Bray-2
Can we get something that reflect more closely the pattern that
developer would currently have bin using?

If I created a local shadow for a 3.2.X version, I would most likely
have created it this way:

3.2.X
        /Fdo
        /Providers
        /Thirdparty
        /Utilities

We could simply revert Bob's proposal and do

/Fdodev or Fdo_root(repository root)
        /trunk
                /Fdo
                /Providers
                /Thirdparty
                /Utilities
        /branches
                /3.2.X
                        /Fdo
                        /Providers
                        /Thirdparty
                        /Utilities
 
This would also limit changes to build scripts, project and make file,
etc.

RF
 

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Robert Bray
Sent: Tuesday, January 16, 2007 6:59 PM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] PSC Motion: Repository Merge

If SVN can branch without the folder, then I am happy to live without
it.

Bob

Jason Birch wrote:

> How about something like this:
>
> /fdo
>  /fdo
>   /branches
>    /3.2.x
>     /core
>     /tools
>     /...
>   /trunk
>    /core
>    /tools
>    /thirdparty
>    /utilities
>    /providers
>      /sdf
>      /shp
>      /...
>
> Initially, the additional "fdo" level would be redundant.  However,
> this would mean that tools could be moved out into its own structure
> later,
> like:
>
> /fdo    - Repository
>  /fdo
>   /branches
>    /3.2.x
>   /trunk
>  /fdotools
>   /branches
>    /1.3.22
>   /trunk
>
> Other projects seem to be able to branch directly from trunk?
>
> http://svn.refractions.net/postgis/
>
> http://svn.refractions.net/geotools/
>
> Jason
>  
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Robert
> Bray
> Sent: Tuesday, January 16, 2007 15:17
> To: FDO Internals Mail List
> Subject: Re: [fdo-internals] PSC Motion: Repository Merge
>
> I am also fine with that directory just being called fdo. I just want
> to make sure there is a folder there to create global branches from
> (e.g. a branch that applies to all of fdo). If we can do that without
> the folder, then I am happy to do away with it.
>
> Bob
> _______________________________________________
> fdo-internals mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/fdo-internals
>
>  

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Reply | Threaded
Open this post in threaded view
|

Re: PSC Motion: Repository Merge

Mateusz Loskot
Robert Fortin wrote:
> Can we get something that reflect more closely the pattern that
> developer would currently have bin using?
>
> If I created a local shadow for a 3.2.X version, I would most likely
> have created it this way:
>
> 3.2.X
> /Fdo

Why not just Core?

> /Providers
> /Thirdparty
> /Utilities
>
> We could simply revert Bob's proposal and do
>
> /Fdodev or Fdo_root(repository root)
-------------^^^^^^^

By the way of some restructurization, I would suggest to try to make
FDO structure more Unix-friendly to not mix camels with camel-case,
lower-case and both mixed with underscores.

Please, if I may ask for this, let's try keep things consistent.

Cheers
--
Mateusz Loskot
http://mateusz.loskot.net
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Reply | Threaded
Open this post in threaded view
|

Re: PSC Motion: Repository Merge - Revised

Robert Bray-2
Ok, let's reset this motion and try again using everyones input.
Proposed single repository structure is:

/fdo
 /trunk
  /core
  /providers
  /thirdparty
  /utilities
  /tools
 /branches
  /3.2.x
   /core
   /providers
   /thirdparty
   /utilities
   /tools
  ...

And of course we can still create a top level /fdotools if and when we
have something to put in it.

Does this work for everyone? Please vote.

Bob
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Reply | Threaded
Open this post in threaded view
|

Re: PSC Motion: Repository Merge - Revised

Mateusz Loskot
+1

Robert Bray wrote:

> Ok, let's reset this motion and try again using everyones input.
> Proposed single repository structure is:
>
> /fdo
> /trunk
>  /core
>  /providers
>  /thirdparty
>  /utilities
>  /tools
> /branches
>  /3.2.x
>   /core
>   /providers
>   /thirdparty
>   /utilities
>   /tools
>  ...
>
> And of course we can still create a top level /fdotools if and when we
> have something to put in it.
>
> Does this work for everyone? Please vote.
>
> Bob
> _______________________________________________
> fdo-internals mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/fdo-internals
>


--
Mateusz Loskot
http://mateusz.loskot.net
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Reply | Threaded
Open this post in threaded view
|

Re: PSC Motion: Repository Merge - Revised

Frank Warmerdam
In reply to this post by Robert Bray-2
Robert Bray wrote:

> Ok, let's reset this motion and try again using everyones input.
> Proposed single repository structure is:
>
> /fdo
> /trunk
>  /core
>  /providers
>  /thirdparty
>  /utilities
>  /tools
> /branches
>  /3.2.x
>   /core
>   /providers
>   /thirdparty
>   /utilities
>   /tools

+1


--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, [hidden email]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Reply | Threaded
Open this post in threaded view
|

RE: PSC Motion: Repository Merge

Romica Dascalescu
In reply to this post by Greg Boone

I think we should keep FDOTHIRDPARTY.
Usually Thirdparty is not modifying in the same time with each FDO
version.
In this moment I build only one Thirdparty for trunk and branches/3.2.x
and the first reason is space.

Romi

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Greg Boone
Sent: Tuesday, January 16, 2007 6:32 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] PSC Motion: Repository Merge

If we accept this proposal then the requirement to use the following
environment variables would be eliminated since all source code would
reside in a single repository.

FDO
FDOUTILITIES
FDOTHIRDPARTY

Greg

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Robert Bray
Sent: Tuesday, January 16, 2007 5:53 PM
To: FDO Internals Mail List
Subject: [fdo-internals] PSC Motion: Repository Merge

As per the other thread on this topic today, I would like to officially
motion to merge all of the fdoXXX repositories into one. The structure
of the proposed repository is as follows:

/fdo    - Repository
 /trunk
  /fdodev
   /core
   /tools
   /thirdparty
   /utilities
   /providers
     /sdf
     /shp
     /...
 /branches
  /3.2.x
   /fdodev

Note that tools in this context would be tools written to a particular
release of FDO. If at some point we create one or more tools that work
across multiple versions of the FDO API then we have the option of
creating an /fdotools folder as per Paul Ramsey's recommendation. In
both cases we have the option of including the tools as part of an FDO
release, making them available as a separate release, or making them
available from SVN only.

I would like to proceed on this as quickly as possible, so please vote
within 24 hours.

Thanks,
Bob
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Reply | Threaded
Open this post in threaded view
|

RE: PSC Motion: Repository Merge - Revised

Greg Boone
In reply to this post by Robert Bray-2
Following up on Mateusz's point regarding mixed case. All the
directories in the proposal use lower case.  I propose that we keep the
currently implemented camel case naming system. This would allow us to
minimize changes to the build scripts. Also, I am in agreement with
Robert. After looking at the build scripts, we would save time and
effort by not renaming the Fdo folder to Core.

/fdo
 /trunk
  /Fdo
  /Providers
  /Thirdparty
  /Utilities
  /Tools
 /branches
  /3.2.x
   /Fdo
   /Providers
   /Thirdparty
   /Utilities
   /Tools
  ...

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Robert Bray
Sent: Tuesday, January 16, 2007 8:51 PM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] PSC Motion: Repository Merge - Revised

Ok, let's reset this motion and try again using everyones input.
Proposed single repository structure is:

/fdo
 /trunk
  /core
  /providers
  /thirdparty
  /utilities
  /tools
 /branches
  /3.2.x
   /core
   /providers
   /thirdparty
   /utilities
   /tools
  ...

And of course we can still create a top level /fdotools if and when we
have something to put in it.

Does this work for everyone? Please vote.

Bob
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Reply | Threaded
Open this post in threaded view
|

Re: PSC Motion: Repository Merge - Revised

Mateusz Loskot
Greg Boone wrote:
> Following up on Mateusz's point regarding mixed case. All the
> directories in the proposal use lower case. I propose that we keep the
> currently implemented camel case naming system. This would allow us to
> minimize changes to the build scripts.

+1

Simply, my suggestion was about trying to introduce some
consistency, to choose one schema.
Now, FDO uses following schemas in names of files and directories:

- lowercase, ie. com, nls
- lower_case_with_underscores, ie. everything in RDBI
- UPPERCASEONLY, ie. ODBC
- CamelCaseWithUPPERCASEMIXED, ie. Rdbms/Override/MySQL, PostGIS.sln
- CamelCase_With_Underscores, ie.
- CamelCaseWith_underscores_and_UPPERCASE, ie. FormatterToXML_UTF16.cpp

So, my call was not to use only lowercase, but to choose
whichever but one.

> Also, I am in agreement with
> Robert. After looking at the build scripts, we would save time and
> effort by not renaming the Fdo folder to Core.

+1

Cheers
--
Mateusz Loskot
http://mateusz.loskot.net
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Reply | Threaded
Open this post in threaded view
|

RE: PSC Motion: Repository Merge - Revised

Greg Boone
In reply to this post by Robert Bray-2
I vote +1 on the modified proposal.

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Mateusz
Loskot
Sent: Wednesday, January 17, 2007 10:41 AM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] PSC Motion: Repository Merge - Revised

Greg Boone wrote:
> Following up on Mateusz's point regarding mixed case. All the
> directories in the proposal use lower case. I propose that we keep the
> currently implemented camel case naming system. This would allow us to
> minimize changes to the build scripts.

+1

Simply, my suggestion was about trying to introduce some
consistency, to choose one schema.
Now, FDO uses following schemas in names of files and directories:

- lowercase, ie. com, nls
- lower_case_with_underscores, ie. everything in RDBI
- UPPERCASEONLY, ie. ODBC
- CamelCaseWithUPPERCASEMIXED, ie. Rdbms/Override/MySQL, PostGIS.sln
- CamelCase_With_Underscores, ie.
- CamelCaseWith_underscores_and_UPPERCASE, ie. FormatterToXML_UTF16.cpp

So, my call was not to use only lowercase, but to choose
whichever but one.

> Also, I am in agreement with
> Robert. After looking at the build scripts, we would save time and
> effort by not renaming the Fdo folder to Core.

+1

Cheers
--
Mateusz Loskot
http://mateusz.loskot.net
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Reply | Threaded
Open this post in threaded view
|

RE: PSC Motion: Repository Merge - Revised

Orest Halustchak
In reply to this post by Robert Bray-2
+1 to keep currently implemented camel case names.

+1 for not renaming Fdo folder to Core.

Orest.

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Greg Boone
Sent: Wednesday, January 17, 2007 9:58 AM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] PSC Motion: Repository Merge - Revised

Following up on Mateusz's point regarding mixed case. All the
directories in the proposal use lower case.  I propose that we keep the
currently implemented camel case naming system. This would allow us to
minimize changes to the build scripts. Also, I am in agreement with
Robert. After looking at the build scripts, we would save time and
effort by not renaming the Fdo folder to Core.

/fdo
 /trunk
  /Fdo
  /Providers
  /Thirdparty
  /Utilities
  /Tools
 /branches
  /3.2.x
   /Fdo
   /Providers
   /Thirdparty
   /Utilities
   /Tools
  ...

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Robert Bray
Sent: Tuesday, January 16, 2007 8:51 PM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] PSC Motion: Repository Merge - Revised

Ok, let's reset this motion and try again using everyones input.
Proposed single repository structure is:

/fdo
 /trunk
  /core
  /providers
  /thirdparty
  /utilities
  /tools
 /branches
  /3.2.x
   /core
   /providers
   /thirdparty
   /utilities
   /tools
  ...

And of course we can still create a top level /fdotools if and when we
have something to put in it.

Does this work for everyone? Please vote.

Bob
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Reply | Threaded
Open this post in threaded view
|

Re: PSC Motion: Repository Merge - Revised

Robert Bray-2
Ok, so everyone but Frank has chimed in and accepted this:

/fdo
 /trunk
  /Fdo
  /Providers
  /Thirdparty
  /Utilities
  /Tools
 /branches
  /3.2.x
   /Fdo
   /Providers
   /Thirdparty
   /Utilities
   /Tools
  ...

Frank are you ok with keeping the Camel Case? I know I personally don't like it, but I don't want to spend a bunch of extra time fixing and testing build scripts. If so then I will see if I can get this scheduled. The repositories will probably be unavailable for a day with addition time required to fix the build scripts.

Greg, any idea how long it will take to fix up the build scripts?

Thanks,
Bob

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Reply | Threaded
Open this post in threaded view
|

Re: PSC Motion: Repository Merge - Revised

Frank Warmerdam
Robert Bray wrote:

> Ok, so everyone but Frank has chimed in and accepted this:
>
> /fdo
> /trunk
>  /Fdo
>  /Providers
>  /Thirdparty
>  /Utilities
>  /Tools
> /branches
>  /3.2.x
>   /Fdo
>   /Providers
>   /Thirdparty
>   /Utilities
>   /Tools
>  ...
>
> Frank are you ok with keeping the Camel Case? I know I personally don't
> like it, but I don't want to spend a bunch of extra time fixing and
> testing build scripts. If so then I will see if I can get this
> scheduled. The repositories will probably be unavailable for a day with
> addition time required to fix the build scripts.

+1 ... I'm sorry, I'm been having trouble keeping up with the revisions on
this motion.  I'm not thrilled with camel case, but I don't mind.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, [hidden email]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
12