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

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

On Tue, Jul 24, 2012 at 10:56 AM, Gregg Tavares (社用) <gman@google.com> wrote:
> 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
> Thoughts?

First, thanks for picking this up.

The top option sounds better as a start. I'd personally like to keep
links like http://www.khronos.org/registry/webgl/specs/latest/ and
on the Khronos site, at least initially, so they seem more official.

In the long run I don't think it'll be necessary to maintain even a
read-only Subversion repo on the Khronos site. I was thinking that the
scripts on khronos.org would simply do a git pull periodically, and
serve up the content from the resulting directory. However, I don't
know how well that would integrate with the rest of the Khronos site.
In particular, it might not be possible to serve up
https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/ from
anything except a Subversion repository (i.e., whether Apache could be
configured to not use mod_dav_svn to serve up that directory and
descendants, unlike everything else under /svn/repos/). James, any
thoughts on this in particular?

On the whole, whatever gets the WebGL repo on to github fastest
without breaking tons of links sounds like the best option to me. :)


> 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.
>> Regards,

You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl