I started to write an email about this but I decided it was too long. Cliff's notes version instead:
* I have the geonode client build working based on Maven artifacts already (development mode isn't there yet though) * git-svn makes it really easy to keep a git repository synced to an upstream SVN repository. There are some restrictions if you want to be able to push back. * The distinction between modifiable and non-modifiable externals strikes me as not that important. We don't commit to GeoExt and OpenLayers without exporting patches and going through extensive community review anyway, so not being able to commit directly from a GeoNode checkout doesn't seem like it would be a huge change in workflow. * Working things out with ExtJS seems confusing. Why's it okay to use an SVN mirror of it, but not a git one? Maybe we could host just Ext as a Maven thing and leave the rest working like it does now. -- David Winslow OpenGeo - http://opengeo.org/ On 05/27/2010 07:50 AM, Andreas Hocevar wrote: > Hi, > > I wonder how ccnmtl do their OpenLayers trunk mirror on GitHub: > http://github.com/ccnmtl/openlayers - this is always up to date with trunk. > > If we could mirror the other projects in a similar way, I guess that would be > the way to go (easier than Maven, and better integrated). David, is this what > you meant with option 2? > > See some more comments inline. > > On May 26, 2010, at 00:49 , 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) >> > We modify - at least we create patches that we rely on. > > >> openlayers (we follow trunk) >> > We modify, the same way as with geoext. > > >> geoserver ( we modify ) >> geonetwork (we modify) >> ext (we follow trunk) >> > We use releases, mirrored on the geoext svn. It would be better to include > the official release (to be downloaded and unpacked by the build tool) and > not use git for ext. One caveat though: we are only allowed to do this if the > GeoNode license is compatible (GPL 3 or similar). > > >> gsconfig.py (we follow trunk) >> > You forgot one: > gxp (we modify) > > Regards, > Andreas. > > >> } >> >> 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 >> >
