Another thought related to this: how hard would it be to build Maven artifacts for OpenLayers, GeoExt and gxp? Then we would not need any svn:externals at all (at least for the javascript stuff).
Ah yes, and sorry if this sounds stupid. I neither have much experience with Maven nor with git at this point. Regards, Andreas. On May 26, 2010, at 17:15 , David Winslow wrote: > Just a note: we don't actually modify code in GeoServer and GeoNetwork, we > simply pull in pre-built artifacts (from OpenGeo's Maven repository for > GeoServer, and from an ad-hoc HTTP server for GeoNetwork) and add a couple of > extensions to each. We could (should?) avoid cloning these into git. > > -- > David Winslow > OpenGeo - http://opengeo.org/ > > On 05/25/2010 06:49 PM, Ariel Nunez wrote: >> Thanks for pushing this up in the queue David. >> >> >> 2 - We mirror all our SVN externals so we can use git submodules to do the >> same thing. >> Pros - slightly better integration than braid on the client end >> (checkout consists of "install git, >> git clone, git submodule update --init";) >> Cons - maintaining git clones of svn projects, two-tier process to push >> changes back >> >> I like this option a lot, we are using outside dependencies and the >> submodule step makes this crystal clear. >> >> From my conversation with David on IRC, the projects are the following: >> { >> geoext (we follow trunk) >> openlayers (we follow trunk) >> geoserver ( we modify ) >> geonetwork (we modify) >> ext (we follow trunk) >> gsconfig.py (we follow trunk) >> } >> >> The idea would be to setup git forks for those repos under the geonode git >> account, like this: >> github.com/geonode/geoext >> github.com/geonode/openlayers >> github.com/geonode/geoserver >> github.com/geonode/geonetwork >> github.com/geonode/ext >> github.com/geonode/gsconfig.py >> >> And put git submodules in this main repo: >> github.com/geonode/geonode >> >> If anybody does not like the fact that we depend on Github, we always have >> the option to setup: >> git.geonode.org >> >> 3 - We commit all SVN externals directly to the git repository, kind of like >> svn vendor branches. >> Pros - even better integration than git submodule, when you checkout the >> project you get >> everything. >> Cons - it takes a bit of digging in the repository to extract diffs to >> submit upstream patches, and >> even bringing in updates is kind of a pain. >> >> It is true this option may be the simplest for new users but I don't like >> the fact that patches are against "Geonode's version of X project" instead >> of the actual project. "Explicit is better than implicit", so #2 is still my >> favorite. >> >> But I'm open to alternatives/arguments. However, let's try and be >> git-friendly by, say, Friday next week? I'm not aware of a hard deadline >> but at the rate this discussion's been going we'll never get converted. >> >> +1 The sooner the better. >> >> Ariel > -- Andreas Hocevar OpenGeo - http://opengeo.org/ Expert service straight from the developers.
