Ok, so I just re-read my words below. Perhaps this is a slightly too convoluted process to adopt as a legit development procedure.
I still think it would technically work, but I'm less sure of it than I was when I thought of it. Maybe it's a good band-aid, but it's still just a band-aid over the bigger problem that GSIP#6 is trying to get the Geoserver PMC to address. --saul > > I think it's my bad names that got you bogged down! It's simpler than I > wrote it, I think. The idea is that geoserver's "real" development > would go on against geoserver-trunk, which is based on some kind of > stable geotools. Then a "forward-port" of geoserver-trunk would be > maintained which tracked the changes to geoserver-trunk required to make > it run against geotools-trunk. > > When someone wants to bring any *new* geoserver development into the > forward-port, they can just svn merge the trunk to their branch. Once > they've got everything sorted out (if there are any problems) then the > difference between geoserver-trunk and the forward-port (as retreived by > "svn diff forward-port") are exactly what's needed to make > geoserver-trunk work against geotools-trunk. > ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
