> I am actually hoping this reduces code branches ... both for geotools > and geoserver.
So what do you see as the geoserver branch/functionality structure? Leaving aside legacy branches that get only bugfix treatment (1.3.x, soonish 1.4.x), how can geoserver lay out its braches to meet its functionality requirements? Perhaps think what Andrea would say about stability before suggesting that gs-trunk would work well on gt-trunk (without re-thinking how gt-trunk is currently a big old R&D experiment) >> >> * Have a running branch of geoserver which tracks gt-trunk. *not* >> geoserver-trunk, but a different branch, perhaps called >> "geoserver-gt-trunk-sync". > I am not sure that suggestion (which occurred to me as well) is quite > strong enough - we are operating with this right now except the branch > of geoserver is called OWS4. Sort-of. Except that OWS4 is just a one-man experiment. geoserver-track-gttrunk (better name, I think) would need to be more actively developed...perhaps with a cruisecontrol so that folks knew when it was busted. >> coupled with >> >> * Constantly svn merge geoserver-trunk into geoserver-gt-trunk-sync, >> and then make necessary changes to compile against gt-trunk. This way >> you have an always-up-to-date patch (svn diff > >> gs-trunk-to-gt-trunk.patch) taking gs-trunk to gt-trunk. > Darn that hurt my brain; will try and talk myself through that after a > break. 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. >> The hard part is that geotools often leads geoserver. It's true that >> geotools risks going in the "wrong" direction, but geotools is often >> the leader here. More folks tracking ISO/OGC standards in gt than >> geoserver, for sure! > Interesting; this conflicts with my recent experience - GeoTools is > changing right now in order to facilitate GeoServer development (the > fact that this development is scattered across GeoServer branches is a > different problem). Yeah, it's true. There's lots of people doing lots of crazy stuff right now. It would be cool if there was a less scary/treacherous/scattered way of letting geoserver/geotools work together. But hey, at least there's no more geoserver-specific geotools code in the geoserver svn repository, right? Didn't that happen for a bit? --saul ------------------------------------------------------------------------- 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
