On 05/12/2010 03:52 PM, Sebastian Benthall wrote:
* Switch official repository to Github for hosting the code. We
have access to http://github.com/geonode and David and I agree that
the evidence has panned out that github is good for project publicity.
(See for example http://tinyurl.com/yhens8c ) . To effect this
transition, this will require some changes to how we do JavaScript
dependency management.
I've been pondering this and doing a bit of research. I see about 4
different approaches to this issue.
1 - We create a script (or maybe we use something like braid
<http://wiki.github.com/evilchelu/braid/>) to mimic what we are doing,
just not
directly in the VCS.
Pros - we're still working directly off of the SVN of our
dependencies, minimal change to workflow
Cons - poor integration (checkout consists of "install git, install
svn, install braid, git clone,
braid update")
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
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.
4 - We stop checking out dependencies into the source tree and use a
static download to fetch them
instead. This could be a simple URL fetch like we currently do
with GeoNetwork/Intermap, or it
could include some version metadata like Maven or easy_install use.
Pros - portable if we ever switch vcs tools again?
Cons - more rigid structure/setup process, upgrading the version
means publishing a new artifact
in the dependency repository.
I am currently thinking that choice #3 in the above list is the nicest.
It allows us to version *exactly* the revision of all dependencies,
unlike the current system where checking out an older revision may fail
(because it's still pulling in whatever's latest from svn:externals).
In addition, I think we can mitigate the hassle of extracting diffs by
just keeping a branch where those dependencies are always the unmodified
version from upstream. (We could even make that the main/trunk/master
branch that we do deployments from.)
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.
--
David Winslow
OpenGeo - http://opengeo.org/
