[postgis-devel] Re: CVS to SVN move

[Paul Ramsey]

Markus,

Thanks for bugging me about this again.  To recap from before, my big  
problem was taking the current postgis and geos modules in the one  
CVS repository and splitting them into two svn respositories, but it  
turns out that the way I was doing it (cvs2svn on the whole CVS  
archive, then svndumpfilter to try and break them apart) was way more  
complex than I had to be.  Simply pointing cvs2svn into the module I  
wanted achieved exactly the effect I was looking for.

So, I am officially ready to move geos and/or postgis into svn.

Which should go first, and when?

Paul

On 25-Jul-06, at 12:25 AM, Markus Schaber wrote:

> 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
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel