On May 27, 2010, at 22:32 , David Winslow wrote: > 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)
Great! > * 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. 100% agreed. > * Working things out with ExtJS seems confusing. Why's it okay to use > an SVN mirror of it, but not a git one? Our SVN mirror is approved by the Ext JS team, as long as we only use it for GeoExt development. The reason why we use it now in GeoNode is a more complicated story: We used to link to the officially hosted Ext JS version and had no local copy of it. But things changed when we switched to Ext 3.2: Tim created a temporary svn mirror in the gxp repo, which we used for the transition to Ext 3.2. I included it because we relied on it. When Ext 3.2 was released, I changed the externals source to the one in the geoext repo, instead of switching back to the hosted version or, even better, including a download of the official release in the build process. > Maybe we could host just Ext as > a Maven thing and leave the rest working like it does now. We could do that, but we should ask the Ext JS team for approval. The other option that I had in mind would be to download an official release as part of the build process - in a similar way as we currently do with the gs-data dir. -Andreas. > > -- > 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 >>> >> > -- Andreas Hocevar OpenGeo - http://opengeo.org/ Expert service straight from the developers.
