So, we were a bit short-staffed last week due to the Understanding Risk
conference, but I went ahead and set up the projects according to scheme
#2 from my original proposals, with the exception that ExtJS is
downloaded from Cachefly (ie, the same way you would download it from
their web site). These are up on GitHub now: http://github.com/GeoNode/
The setup process should be pretty familiar for those coming from the
old system:
1. git clone [email protected]:GeoNode/geonode.git
2. git submodule update --init
3. python bootstrap.py
4. source bin/activate
5. paver build
I'll document this in a more permanent place shortly. Anyway, now that
we're on git we can move to a more sandboxy model (basically, all
contributors fork the project and work in their own forks, issuing pull
requests when they have something suitable for 'master') or we can all
push to the same github repository. I don't think we've had any issues
thus far so I'd tend toward just giving everyone write access (which
doesn't preclude forking or branching for particularly pervasive
changes). If you'd like commit access to the repository on Github
please email me with your github account name.
The other thing is the transition process. I think everyone on the team
is somewhat familiar with git (except Andreas?) so I had hoped we'd be
able to do this with a fairly brief transition period. Unfortunately,
Andreas is in the middle of a largish refactoring on SVN trunk, so I
guess it makes some sense to keep the SVN repo running until he gets
that committed (and he's on vacation this week.) Therefore, I propose
we keep the SVN repository up until June 25 (Friday two weeks from now)
but start using the git repository for new work. I'll be merging any
changes made to the SVN repo to github, but not the other way, during
the interim.
Or we can just keep working in SVN until Andreas gets back; it's pretty
easy to update the converted repository.
--
David Winslow
OpenGeo - http://opengeo.org/
On 05/25/2010 05:30 PM, David Winslow wrote:
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/
