My understanding is we can commit as much as we need into the existing repository. Once the new repo at locationtech has been set up and initial code were checked in (after path/packages migration?) its pretty easy to identify the commits since tag 1.4.0. We can add udig-platform as a remote repository to the new clone taken from locationtech afterwards. All commits pushed after 1.4.0 can cherry-picked into a new branch merged back into mainline at locationtech.
I would suggest to commit and push. In this case of the current pull we should accept it. Thanks Emily for the fix including a test case!! Cheers, Frank 2013/4/4 Jody Garnett <jody.garn...@gmail.com> > We are kind of in limbo during the migration to eclipse hosting (i.e. we > have not sorted out as a team what we want to do - and I do not have a fix > on how long it will take for the initial codebase to be available). > > My understanding is that since you are set up on the eclipse end of things > that we can smoothly pull your fix over when the time comes. > > Ideas? > > -- > Jody Garnett > > On Thursday, 4 April 2013 at 5:32 AM, Emily Gouge wrote: > > Thanks for the help Jody. I think I tracked down and solved the > problem. I opened a JIRA bug and created a pull request with my updates. > https://github.com/uDig/udig-platform/pull/166 > > Emily > > On 02/04/2013 8:26 PM, Jody Garnett wrote: > > Afternoon Emily: > > While I have not had a chance to test, I have run into similar problems > previously. > > There are two candidates: > > 1) The code that writes the catalog out to disk, and reads is back in again > performs some URL encoding/decoding. > 2) Similar code is called when MapImpl is saved (as it wants to save out > connection parameters for each of its layers) > > I have sent emails tracing through these methods before, with notes ... > > For now: > > 1. CatalogImpl.saveToFile calls ServiceParameterPersister.store > 2. Which rewrites URLs to be relative: > > URL relativeURL = URLUtils.toRelativePath(this.reference, url); > value = URLUtils.urlToString(relativeURL, true); > > 3. And then encodes: > > value= URLEncoder.encode( value, ENCODING ); > > Similar code in restoreProperties performs the reverse. > > Debug these two methods to see where things have gone astray? > > > > On Wed, Apr 3, 2013 at 7:28 AM, Emily Gouge <ego...@refractions.net> > wrote: > > I have a shapefile with a space in the file name ("my test.shp"). When I > load this into uDig the first time it loads and displays fine. However when > I close and re-open uDig the file is not displayed. This warning message > is printed: > "Trouble matching file for:file:/C:/data/SMART/**SampleData/countries2/my% > **20test.shp#my%20test" > > This problem only occurs when the space is in the file name. If the space > exists in one of the directory names I don't have any problems. Also, it is > not specific to shapefiles; it also happens for raster files. > > Can somebody confirm this behavior and perhaps point me to where I need to > look to get it resolved? > > Thanks, > Emily > ______________________________**_________________ > User-friendly Desktop Internet GIS (uDig) > http://udig.refractions.net > http://lists.refractions.net/**mailman/listinfo/udig-devel< > http://lists.refractions.net/mailman/listinfo/udig-devel> > > > > > _______________________________________________ > User-friendly Desktop Internet GIS (uDig) > http://udig.refractions.net > http://lists.refractions.net/mailman/listinfo/udig-devel > > _______________________________________________ > User-friendly Desktop Internet GIS (uDig) > http://udig.refractions.net > http://lists.refractions.net/mailman/listinfo/udig-devel > > > > _______________________________________________ > User-friendly Desktop Internet GIS (uDig) > http://udig.refractions.net > http://lists.refractions.net/mailman/listinfo/udig-devel > >
_______________________________________________ User-friendly Desktop Internet GIS (uDig) http://udig.refractions.net http://lists.refractions.net/mailman/listinfo/udig-devel
