[postgis-devel] Re: CVS to SVN move

[Markus Schaber]

Hi, Paul,

Paul Ramsey wrote:

>> Some weeks ago, there was a discussion on the PostGIS devel list about
>> moving from CVS to SVN.
>>
>> What's the current state of decision on this issue?
> 
> I didn't end up making a decision, because I found it so time consuming
> to try and separate the repositories, and never succeeded.

Ok, I understand.

Maybe the cvs2svn script could be helpful.

I'd suggest that you first convert the whole CVS repository 1:1 into SVN
using a tool like that, and after that, use the SVN move command to
reorganize the trees, branches and tags inside the SVN repository as you
like it.

>> And what do you think about the possible separation of the jdbc code
>> into its own project?
> 
> I am not super enthusiastic, though I understand your desire to do
> independent releases, I also like having it as part of the official
> distribution.  Perhaps a JDBC sub-page where extra releases could go, or
> a nightly JDBC build, would be a suitable substitute for a completely
> separate stream?

My main point behind this is that the two code bases are completely
independent. Clients and Servers can be deployed and upgraded
independently. E. G. one can use the newest JDBC code against a 0.8
Server. It's a bit like the pgjdbc driver vs PostgreSQL itsself.

It might even make sense to separate the Backend code and the shapefile
loaders / dumpers by the same argument.

But currently, the project still is small enough, so it doesn't really
matter, as long as you're prepared to make releases that have either
part unchanged. EOD.

> PL/Java w/ PostGIS may be interesting, though it may also suffer from
> the same problems that PL/Java in Oracle has, namely brutal throughput
> problems.  Test before you jump in too deep.

Yes, throughput problems might be a problem. But with intelligent
design, and the GCJ backend, I expect the throughput to be acceptable.
Don't forget that, currently, the C backend code also employs
conversions from the on-disk format to the in-memory format and the GEOS
format.

I have not thougt about Oracle compatibility yet, nor looked at the
Oracle way of doing it at all, btw. Partly because I don't want to get
into licensing issues.

My initial idea was to make the power of JTS / geotools / whatever
available in the backend by defining a mapping for the JTS classes. This
would make it possible e. G. to create a stored procedure that
completely renders a map with several layers in the backend, given the
bbox as parameter, and returning a .jpeg as byte array.

Btw, it might also make sense to port the Python Geotypes to PLPython.

HTH,
Markus
-- 
Markus Schaber | Logical Tracking&Tracing International AG
Dipl. Inf.     | Software Development GIS

Fight against software patents in EU! www.ffii.org www.nosoftwarepatents.org