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.
