Here is an example of grabbing a set of changes from trunk over to the 2.1.x stable branch.
You need a checkout of the stable branch:
- mkdir stable
- svn co http://svn.geotools.org/geotools/branches/2.1.x/ stable
Then lets go into the geotiff module:
Lets figure out the first revision number - we can start with when 2.1.x split off trunk.
C:\java\geotools\gt\plugin\geotiff>svn log --stop-on-copy
Stable branch is targeted towards 2.1.RC0
stable branch will be released as 2.1.0
So 2.1.x was created at r13923 - that is BEFORE
Now lets check what happened on trunk in that timeframe:
C:\java\geotools\gt\plugin\geotiff>svn log -r 13923:HEAD http://svn.geotools.org/geotools/trunk/gt/plugin/geotiff
Removed deprecated CRS classes from trunk. Those classes will stay on the 2.1 branch. The purpose for this removal is o
So it looks like there is a good change we want on the stable branch.
Lets go get it:
> svn merge -r 13923:13954 http://svn.geotools.org/geotools/trunk/gt/plugin/geotiff
So two files were changed, lets try our "maven test", that still works. Okay that worked, it is worth doing the full "maven clean, build, createRelease" cycle.
Often when developing on trunk we don't do the createRelease test - but hey we are supposed to be stable here.
If all goes well we can commit:
> svn commit -m "Patched r 13923:13954 from trunk, Removed the last dependencies to the old CRS system - thanks martin"
And hope that CC does not find issue with the changes (is shouldn't).
If it did we could back out the change and commit:
svn merge -r 13954:13923 http://svn.geotools.org/geotools/trunk/gt/plugin/geotiff