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
<http://www.kernel.org/pub/software/scm/git/docs/git-submodule.html>
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 <http://github.com/geonode/geoext>
github.com/geonode/openlayers <http://github.com/geonode/openlayers>
github.com/geonode/geoserver <http://github.com/geonode/geoserver>
github.com/geonode/geonetwork <http://github.com/geonode/geonetwork>
github.com/geonode/ext <http://github.com/geonode/ext>
github.com/geonode/gsconfig.py <http://github.com/geonode/gsconfig.py>
And put git submodules in this main repo:
github.com/geonode/geonode <http://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 <http://git.geonode.org>
3 - We commit all SVN externals directly to the git repository,
kind of like svn vendor branches
<http://svnbook.red-bean.com/en/1.5/svn.advanced.vendorbr.html>.
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
