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.
