Message-ID: <2014135309.298352.1368914059797.JavaMail.firstname.lastname@example.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_298351_427137769.1368914059796" ------=_Part_298351_427137769.1368914059796 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Cleanup SVN repository
The SVN has been cleaned out and refactored as of revision 30258. The ne= w SVN repo went live on 2008-05-14. All commits should appear sequentially = as of revision 30262.
The geotools *repository is now: http://svn.geotools.org/
The main branch of development, "trunk", is available as http://svn.geotools.org/trunk/.
The svn repo is huge to the point of being uweildy, mixes both uDig and = Geotools, contains big image files which have been deleted but remain in th= e repository, contains files that have been added multiple times rather tha= n being svn copied, and have other miscellaneous errors. This proposal brin= gs love to the repository, cutting its size in half (3 GB -> 1.5 GB) and= getting things on a better footing going forward.
The user visible changes will be:
Following this, everyone will have to do a new checkout. Because we are = doing both a change of location and a change of structure, it looks like fi= ghting through using 'svn switch' will be more of a struggle than it's wort= h. Probably it's easier to save any non-committable changes in an 'svn diff= ' generated patch file and apply that to the new checkout but to each their= own.
The old repository will not be touched so uDig can keep going and so we = have a clean fall back option if anything goes wrong.
Going forward, we expect uDig to undergo a similar cleanup and also move= off to a new server at which point geotools can reclaim the svn.geotools.o= rg domain (although by then we may also move on to OSGeo).
We have developed a multi-step process to clean the repo. We start with = an 'svn dump /path/to/repo > dumpfile' of the repo to get a dumpfile. (T= hese files are mostly text but with binary blobs inside them.) We then:
We propose the following:
The developer guide will have to be updated, notably the source code page.
This proposal does not address the desire to move to a newer version of = the svn server---our host refractions has internal constraints that prevent= it. That can be our incentive to move to OSGeo infrastructure.
We need consensus from the major participants in the Geotools community = and then need to coordinate with refractions, with the uDig community and w= ith Geotools developers and users to schedule the actual work.
The work is tentatively scheduled for the week of the 12th of May 2008, = subject to Refractions' ability.
The svn repo has been split from the common geotools/uDig/geovista repo.= The current SVN is about half the size of the old.