This is great. Once we switch to git we should turn off code browsing in Trac to avoid confusion--unless there is a way to point Trac at github?
That may be transitional though, since we've talk a bit about transitioning to github for project management tools. I am ambivalent on this, since the transition will involved a lot of overhead and some relearning (and will involved some changes to processes internal to OpenGeo...) but it would centralize our project web presence. What are your thoughts on this? On Mon, Jun 7, 2010 at 10:44 AM, David Winslow <[email protected]> wrote: > 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/ > > > -- Sebastian Benthall OpenGeo - http://opengeo.org
