Update on this: Please proceed with the git migration without waiting for my commits!
It is unlikely that I will be able to finish the refactoring this week. I am running out of time, working myself through the mail and list backlog and unforeseen tasks after my vacation. It is also unlikely that I will be able to finish it next week and the week after, because I will be in Zürich for 3 days next week, have to prepare my AGIT conference presentation and workshop, and attend the AGIT conference with booth duty from July 6-9. So a realistic date for finishing the refactoring will be around July 15. Sorry for that - I have not managed yet to have myself cloned :-). -Andreas. On Jun 22, 2010, at 13:00 , Andreas Hocevar wrote: > Hi, > > sounds great to me! It's not that I am totally unfamiliar with git, but > waiting until the refactoring is committed makes things definitely easier. > > Thanks for the patience everyone. > > -Andreas. > > On Jun 7, 2010, at 23:09 , Sebastian Benthall wrote: > >> 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) 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 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. >>> 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 >> > > -- > Andreas Hocevar > OpenGeo - http://opengeo.org/ > Expert service straight from the developers. > -- Andreas Hocevar OpenGeo - http://opengeo.org/ Expert service straight from the developers.
