> > 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. >
+1 on this transition plan. > 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
