[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] Moving WebGL Khronos related stuff to GitHub

So I'm looking into this since it seems like Cedric is too busy.

My current thinking

1) On the Khronos server, use git-svn to clone the current svn repo to git
2) push that git repo to github
3) make a script that 
  step 1) uses git to pull from github master to the git-svn repo on the khronos server
  step 2) uses git svn dcommit from there to commit the changes it just pulled into svn
4) Make the svn server read only except for a local account
5) Setup a cron job that calls the script from step 3

This keeps all the links working. Keeps Khronos.org as the place to run the tests (no gh-pages on github)

At least as a first step. What do you think?

The next meta step would be to install a post commit step on github that triggers the script from step 3. That could happen by accessing a webpage that calls the script. There's no security issues except DoSing

OR, maybe I'm over thinking it and should follow this pattern

1) Move everything to github
2) check in redirects on svn
3) write script that syncs to github to update khronos.org/webgl specs / get.webgl.org
4) make that script from Step3 either a cron job or triggered from post-commit script on github

That's certainly easier. It means though that all the links out there to cvs still will link to HTML redirects (not HTTP redirects) which means search engines and stuff will not likely update (an HTTP redirect can say "permanent", an HTML one can't  It also means checking something into master at github master does not make it live. It has to be moved to a gh-pages branch to be live which is an extra step. I suppose a post-commit script can handle that too

Is there a preference? I think I prefer the top steps to the bottom ones. It's also potentially faster. github's gh-pages feature is not instant (I've seen it take > 10 mins to update) where as a post-commit step that updated svn would likely be nearly instant. On the other hand it's more brittle. Theoretically if the scripts always go from git -> svn there should never been an issue but as we call know there often are. In fact I just thought of one. svn will need a config that auto adds mime types so the files get served correctly. That's fine for known types but if anyone adds a new type of file on github it won't get served from the svn server without someone updating that script and then manually updating svn:mime-type the files of that type already checked in


On Tue, May 29, 2012 at 10:27 PM, Cedric Vivier <cvivier@mozilla.com> wrote:
On Wed, May 30, 2012 at 1:03 AM, Kenneth Russell <kbr@google.com> wrote:
> Any further thoughts on the desired repository structure?
> Cedric, would you be willing to own the tasks of:
>  - Working with James and Gregg to come up with a final repository structure
>  - Working with James to update the Khronos side shell scripts
> populating the directories under http://www.khronos.org/registry/webgl/

I think I'll figure out a middle ground somewhere between a "pure git
way" and the constraints discussed.
I'll have this ready by the end of the week and then sync up with
James and Gregg for the next steps.