Okay. Luke, Ariel, and I have been working off the github repository for a couple of weeks now, and I can pull in SVN commits with relatively little pain. I don't *think* you will have any serious conflicts, since the modifications to the client media are pretty small (I think some CSS work is all, maybe some adjustments to the search page JS). However, if you are more comfortable with SVN you may as well use that for your refactoring, once it's in SVN I can migrate it and then kill off the SVN repo.
Other than that, I think we are fully migrated. -- David Winslow OpenGeo - http://opengeo.org/ On 06/22/2010 11:43 AM, Andreas Hocevar wrote: > 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. >> >> >
