Official SDL mirror on github

Stewart_Miles · July 8, 2014, 6:30pm

Hi, I’m part of a small team in Google that is working on technology for
game developers. A couple of our recent releases are
https://github.com/google/liquidfun and
https://github.com/google/flatbuffers .

I was wondering whether there is any appetite in the SDL community to
publish an official mirror of the Mercurial repository to github (using a
tool like hg-git)? This could make it easier for open source projects with
dependencies on SDL to include a reference to the project’s source using a
git project reference (e.g git submodules).

Cheers,
Stewart

Julian_Winter · July 8, 2014, 6:35pm

How exactly could this make it easier?Am 08.07.2014 20:30, schrieb Stewart Miles:

Hi, I’m part of a small team in Google that is working on technology
for game developers. A couple of our recent releases are
https://github.com/google/liquidfun and
https://github.com/google/flatbuffers .

I was wondering whether there is any appetite in the SDL community to
publish an official mirror of the Mercurial repository to github
(using a tool like hg-git)? This could make it easier for open source
projects with dependencies on SDL to include a reference to the
project’s source using a git project reference (e.g git submodules).

Cheers,
Stewart

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Gabriel_Jacobo · July 8, 2014, 6:36pm

2014-07-08 15:30 GMT-03:00 Stewart Miles :

Hi, I’m part of a small team in Google that is working on technology for
game developers. A couple of our recent releases are
https://github.com/google/liquidfun and
https://github.com/google/flatbuffers .

I was wondering whether there is any appetite in the SDL community to
publish an official mirror of the Mercurial repository to github (using a
tool like hg-git)? This could make it easier for open source projects with
dependencies on SDL to include a reference to the project’s source using a
git project reference (e.g git submodules).

Cheers,
Stewart

This mirror [1] follows HG quite closely, it’s not official though.

Why would anyone want to use git instead of Mercurial?

(Hey, this flamewar was bound to happen )

[1] https://github.com/spurious/SDL-mirror/commits/master

Gabriel.

Jonas_Kulla · July 8, 2014, 6:45pm

2014-07-08 20:36 GMT+02:00 Gabriel Jacobo :

2014-07-08 15:30 GMT-03:00 Stewart Miles :

Hi, I’m part of a small team in Google that is working on technology for

game developers. A couple of our recent releases are
https://github.com/google/liquidfun and
https://github.com/google/flatbuffers .

I was wondering whether there is any appetite in the SDL community to
publish an official mirror of the Mercurial repository to github (using a
tool like hg-git)? This could make it easier for open source projects with
dependencies on SDL to include a reference to the project’s source using a
git project reference (e.g git submodules).

Cheers,
Stewart

This mirror [1] follows HG quite closely, it’s not official though.

Why would anyone want to use git instead of Mercurial?

To add SDL2 as a git subomdule in projects using git?>

(Hey, this flamewar was bound to happen )

[1] https://github.com/spurious/SDL-mirror/commits/master

Gabriel.

icculus · July 8, 2014, 8:07pm

Hi, I’m part of a small team in Google that is working on technology for
game developers. A couple of our recent releases are
https://github.com/google/liquidfun and
https://github.com/google/flatbuffers .

(I haven’t seen liquidfun before, but I saw FlatBuffers the other day,
and it looks really promising! It’s seems to be a good improvement over
Protocol Buffers.)

I was wondering whether there is any appetite in the SDL community to
publish an official mirror of the Mercurial repository to github (using
a tool like hg-git)? This could make it easier for open source projects
with dependencies on SDL to include a reference to the project’s source
using a git project reference (e.g git submodules).

I certainly can’t stop you, but I would rather you not.

People will assume the GitHub repo is the official location, because
GitHub does this to people for some reason.
People put my various projects on GitHub mirrors just for the sake of
having a git mirror (fine), and then they stop pulling updates (not fine
at all).
People are going to send pull requests to the GitHub repo, which we
probably won’t see, and I’ll probably roll my eyes every time we have to
merge from there.
There will be two bugtrackers: ours, and the GitHub one.
There will be two wikis: ours, and the GitHub one.
There are references all over the place to hg changesets, and links to
https://hg.libsdl.org/ … we had fallout from this before when we
switched from CVS to svn, and again when we switched to Mercurial…we
can deal with that fallout for changing revision systems, and if we ever
move to git we will, but I don’t really care for having two sets of this
at once. It’s not clear that it’s worth the confusion so someone can
choose between typing “git clone” or “hg clone”.
Submodules aren’t interesting to us. We changed our license to let you
statically link SDL, but we’d rather you have to struggle a bit to do
so.

And, personally important to me, but not necessarily anyone else:

We’ve been burned more than once by service providers and software that
we don’t control, and have spent an enormous amount of energy to control
all our infrastructure because of it. Now (with the exception of the
mailing lists for now), in the worst case, we can take our domain
registration and our daily server backup and move somewhere else and
carry on as before. I’m not interested in cooperating with yet-another
Cloud Service provider that will, ultimately, make people ask why we
aren’t using the cloud service provider more instead of the perfectly
good server that’s completely under our control. Real talk: there are
lots of interesting features there, but you should be using GitHub less.

–ryan.

Stewart_Miles · July 8, 2014, 8:23pm

Hi, I’m part of a small team in Google that is working on technology for

game developers. A couple of our recent releases are
https://github.com/google/liquidfun and
https://github.com/google/flatbuffers .

(I haven’t seen liquidfun before, but I saw FlatBuffers the other day, and
it looks really promising! It’s seems to be a good improvement over
Protocol Buffers.)

I was wondering whether there is any appetite in the SDL community to

publish an official mirror of the Mercurial repository to github (using
a tool like hg-git)? This could make it easier for open source projects
with dependencies on SDL to include a reference to the project’s source
using a git project reference (e.g git submodules).

I certainly can’t stop you, but I would rather you not.

People will assume the GitHub repo is the official location, because
GitHub does this to people for some reason.

Would adding a big notice in the Readme.md pointing folks at the real
source tree mitigate this?

People put my various projects on GitHub mirrors just for the sake of
having a git mirror (fine), and then they stop pulling updates (not fine at
all).

If an automated job performed the sync, this wouldn’t be an issue.

People are going to send pull requests to the GitHub repo, which we
probably won’t see, and I’ll probably roll my eyes every time we have to
merge from there.

There will be two bugtrackers: ours, and the GitHub one.

There will be two wikis: ours, and the GitHub one.

This could be mitigated by a big notice in the Readme.md pointing folks at
the real website and source. Using an e-mail autoresponder to all pull
requests and bugs that points them at https://hg.libsdl.org/,
sdl at lists.libsdl.org and the sdl buganizer? Not providing a gh-pages
branch - hence no wiki.

We kinda, have a similar issue where we have internal development trees for
some of our open source projects where we mirror external bugs into our
internal bug system and merge externally contributed patches back into our
internal tree(s). I admit, it’s all work though.

There are references all over the place to hg changesets, and links to
https://hg.libsdl.org/ … we had fallout from this before when we
switched from CVS to svn, and again when we switched to Mercurial…we can
deal with that fallout for changing revision systems, and if we ever move
to git we will, but I don’t really care for having two sets of this at
once. It’s not clear that it’s worth the confusion so someone can choose
between typing “git clone” or “hg clone”.

Submodules aren’t interesting to us. We changed our license to let you
statically link SDL, but we’d rather you have to struggle a bit to do so.

Personally, I’m not a huge fan of checking opaque binaries into source
trees. I think it would be really nice if it was possible to pull a
project and have the entire project build along with its dependencies
entirely from source. Google maintains quite a few projects like this
already (e.g Chromium, Android etc.).

And, personally important to me, but not necessarily anyone else:

We’ve been burned more than once by service providers and software that we
don’t control, and have spent an enormous amount of energy to control all
our infrastructure because of it. Now (with the exception of the mailing
lists for now), in the worst case, we can take our domain registration and
our daily server backup and move somewhere else and carry on as before. I’m
not interested in cooperating with yet-another Cloud Service provider that
will, ultimately, make people ask why we aren’t using the cloud service
provider more instead of the perfectly good server that’s completely under
our control. Real talk: there are lots of interesting features there, but
you should be using GitHub less.

Checking binaries we depend upon - like SDL - into our trees sounds like a
nasty option. Snapshotting SDL into each project that depends upon it
sounds awful. It’s possible we could maintain yet another mirror of SDL on
github which we reference from our projects but that just makes me sad :(On Tue, Jul 8, 2014 at 1:07 PM, Ryan C. Gordon wrote:

–ryan.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Daniel_Gibson · July 8, 2014, 8:26pm

Hi,

People will assume the GitHub repo is the official location, because
GitHub does this to people for some reason.

People put my various projects on GitHub mirrors just for the sake of
having a git mirror (fine), and then they stop pulling updates (not fine
at all).

People are going to send pull requests to the GitHub repo, which we
probably won’t see, and I’ll probably roll my eyes every time we have to
merge from there.

There will be two bugtrackers: ours, and the GitHub one.

There will be two wikis: ours, and the GitHub one.

There are references all over the place to hg changesets, and links to
https://hg.libsdl.org/ … we had fallout from this before when we
switched from CVS to svn, and again when we switched to Mercurial…we
can deal with that fallout for changing revision systems, and if we ever
move to git we will, but I don’t really care for having two sets of this
at once. It’s not clear that it’s worth the confusion so someone can
choose between typing “git clone” or “hg clone”.

All true, thus you should switch to Github completely
(But you don’t have to use the Github Wiki, it’s optional)

And, personally important to me, but not necessarily anyone else:

We’ve been burned more than once by service providers and software that
we don’t control, and have spent an enormous amount of energy to control
all our infrastructure because of it. Now (with the exception of the
mailing lists for now), in the worst case, we can take our domain
registration and our daily server backup and move somewhere else and
carry on as before. I’m not interested in cooperating with yet-another
Cloud Service provider that will, ultimately, make people ask why we
aren’t using the cloud service provider more instead of the perfectly
good server that’s completely under our control. Real talk: there are
lots of interesting features there, but you should be using GitHub less.

Some random thoughts:

Projects from 10 years ago that were hosted on sourceforge can still
be found there (unless the project lead explicitly took them down)
Many projects from 10 years ago that were hosted on custom servers
can’t be easily found anymore, because the server is down
Github pull requests make contributing easier, because people don’t
need an account for each project’s bugtracker to contribute a patch
- the patches are easier to find for outside people to look at
Other projects (e.g. D programming language, Yamagi Quake2,
RBDoom3BFG) have experienced much higher outside contribution
activity since using Github - most probably because of the last point
Github provides documented APIs to export the data (Wiki, Issue
Tracker, …) and there are tools/scripts to import that into other
systems (bugtrackers etc), so backing up the data and migrating to
another service is not too painful, if needed
Probably a main point for Hg over Git back then was better support
on Windows? Nowadays even Visual Studio supports Git out of the box
and my impression is that Git now is more popular in general.

Cheers,
DanielAm 08.07.2014 22:07, schrieb Ryan C. Gordon:

OKUMURA_Yuki · July 8, 2014, 9:01pm

Hi, I run the mirror mentioned in this thread(spurious/SDL-mirror).

2014-07-09 5:23 GMT+09:00 Stewart Miles :

snip -

People will assume the GitHub repo is the official location, because
GitHub does this to people for some reason.

Would adding a big notice in the Readme.md pointing folks at the real source
tree mitigate this?

I put “-mirror” in the repository name to indicate this. I believe it works.

snip -

People are going to send pull requests to the GitHub repo, which we
probably won’t see, and I’ll probably roll my eyes every time we have to
merge from there.

There will be two bugtrackers: ours, and the GitHub one.

There will be two wikis: ours, and the GitHub one.

This could be mitigated by a big notice in the Readme.md pointing folks at
the real website and source. Using an e-mail autoresponder to all pull
requests and bugs that points them at https://hg.libsdl.org/,
sdl at lists.libsdl.org and the sdl buganizer? Not providing a gh-pages branch

hence no wiki.

snip -

I haven’t got any (real) bugreports/pull requests on our mirror. We’ll
do my best to route them into official places in case we got any.

(This fact - lack of any pull request - would be the problem;
ideally, all contributions should be upstreamed. If my mirror
prevented upstreaming, I must reconsider about mirroring.)

I believe having a official(or even a wild) GitHub mirror bring
positive effect to the project. I’m pretty much more than happy if I
could provide any help in this area

Sylvain_Beucler · July 8, 2014, 9:35pm

Hi,On Tue, Jul 08, 2014 at 04:07:53PM -0400, Ryan C. Gordon wrote:

Hi, I’m part of a small team in Google that is working on technology for
game developers. A couple of our recent releases are
https://github.com/google/liquidfun and
https://github.com/google/flatbuffers .

(I haven’t seen liquidfun before, but I saw FlatBuffers the other
day, and it looks really promising! It’s seems to be a good
improvement over Protocol Buffers.)

I was wondering whether there is any appetite in the SDL community to
publish an official mirror of the Mercurial repository to github (using
a tool like hg-git)? This could make it easier for open source projects
with dependencies on SDL to include a reference to the project’s source
using a git project reference (e.g git submodules).

I certainly can’t stop you, but I would rather you not.

People will assume the GitHub repo is the official location,
because GitHub does this to people for some reason.

People put my various projects on GitHub mirrors just for the sake
of having a git mirror (fine), and then they stop pulling updates
(not fine at all).

People are going to send pull requests to the GitHub repo, which
we probably won’t see, and I’ll probably roll my eyes every time we
have to merge from there.

There will be two bugtrackers: ours, and the GitHub one.

There will be two wikis: ours, and the GitHub one.

There are references all over the place to hg changesets, and
links to https://hg.libsdl.org/ … we had fallout from this before
when we switched from CVS to svn, and again when we switched to
Mercurial…we can deal with that fallout for changing revision
systems, and if we ever move to git we will, but I don’t really care
for having two sets of this at once. It’s not clear that it’s worth
the confusion so someone can choose between typing “git clone” or
"hg clone".

Submodules aren’t interesting to us. We changed our license to let
you statically link SDL, but we’d rather you have to struggle a bit
to do so.

And, personally important to me, but not necessarily anyone else:

We’ve been burned more than once by service providers and software
that we don’t control, and have spent an enormous amount of energy
to control all our infrastructure because of it. Now (with the
exception of the mailing lists for now), in the worst case, we can
take our domain registration and our daily server backup and move
somewhere else and carry on as before. I’m not interested in
cooperating with yet-another Cloud Service provider that will,
ultimately, make people ask why we aren’t using the cloud service
provider more instead of the perfectly good server that’s completely
under our control. Real talk: there are lots of interesting features
there, but you should be using GitHub less.

I’m going to bookmark this e-mail, very well put.

Hopefully this GitHub mania will end as the previous ones
(SourceForge, LaunchPad, Google Code, whatever)

–
Sylvain

Alex_Barry · July 8, 2014, 9:51pm

I think some people are missing Ryan’s point.

First, it’s not necessary to be mirrored on github - if you use git, that
does not mean you can not use mercurial.

Second, since SDL is self hosted, it means there is 100% control on the
developers side.

Third, availability is not an issue for the average user (SDL will almost
never be built from hg in a production piece if software), and not a
necessity for developers (snapshots are usually more stable, except in
cases when you need bleeding edge features).

If there is some Google project using SDL, they can created scripts for git
to automatically pull revisions of SDL if necessary.

The bottom line is that it can be convenient, but it’s just adding
unnecessary confusion and another source that needs to be maintained at the
same quality that we expect from the official mercurial, which can’t be
guaranteed from libsdl.org’s perspective.
Hi, I run the mirror mentioned in this thread(spurious/SDL-mirror).

2014-07-09 5:23 GMT+09:00 Stewart Miles :

snip -

People will assume the GitHub repo is the official location, because
GitHub does this to people for some reason.

Would adding a big notice in the Readme.md pointing folks at the real
source
tree mitigate this?

I put “-mirror” in the repository name to indicate this. I believe it works.

snip -

People are going to send pull requests to the GitHub repo, which we
probably won’t see, and I’ll probably roll my eyes every time we have to
merge from there.

There will be two bugtrackers: ours, and the GitHub one.

There will be two wikis: ours, and the GitHub one.

This could be mitigated by a big notice in the Readme.md pointing folks at
the real website and source. Using an e-mail autoresponder to all pull
requests and bugs that points them at https://hg.libsdl.org/,
sdl at lists.libsdl.org and the sdl buganizer? Not providing a gh-pages
branch

hence no wiki.

snip -

I haven’t got any (real) bugreports/pull requests on our mirror. We’ll
do my best to route them into official places in case we got any.

(This fact - lack of any pull request - would be the problem;
ideally, all contributions should be upstreamed. If my mirror
prevented upstreaming, I must reconsider about mirroring.)

I believe having a official(or even a wild) GitHub mirror bring
positive effect to the project. I’m pretty much more than happy if I
could provide any help in this area :)_______________________________________________
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Sik_the_hedgehog · July 8, 2014, 10:04pm

So let me see if I’m understanding right… The idea is to make a
mirror of the repo on GitHub, with all the potential issues it can
entail, only to make life slightly easier to GitHub users?

I think the discussion may make more sense if seen from that viewpoint.

Gabriel_Jacobo · July 8, 2014, 10:22pm

2014-07-08 17:07 GMT-03:00 Ryan C. Gordon :

There are references all over the place to hg changesets, and links to
https://hg.libsdl.org/ … we had fallout from this before when we
switched from CVS to svn, and again when we switched to Mercurial…we can
deal with that fallout for changing revision systems, and if we ever move
to git we will, but I don’t really care for having two sets of this at
once. It’s not clear that it’s worth the confusion so someone can choose
between typing “git clone” or “hg clone”.

If there’s substantial interest in having a Git clone (but not enough
interest to install/learn Mercurial ), we could probably provide a
mirror hosted at libsdl.org, cutting Github out of the equation. I think it
could be worth making SDL more available to those already comfortable with
git at the risk of some link confusion (if that exists at all)–
Gabriel.

Robotic-Brain · July 8, 2014, 11:49pm

I’m hesitant to learn hg in fear of confusing it with git (the syntax
seems to be nearly identical)
so I would like to see a git repository - not necessarily github - so
you could host it on libsdl.org

aren’t there tools to sync git and hg?

Andreas_Schiffler · July 9, 2014, 2:42am

Yes: http://hg-git.github.io

I tried to set up a procedure to automatically mirror SDL using this
tool about 2 years ago. The reason was to create a CoApp setup for SDL
(CoApp is used for automated NuGet package creation for Windows) and
relied on a github repo to “shallow-fork” the master repository. I gave
up after messing around for a few days as I couldn’t get it to work.On 7/8/2014 4:49 PM, Robotic-Brain wrote:

aren’t there tools to sync git and hg?

Jeffrey_Carpenter · July 9, 2014, 3:33am

Hi,

SourceTree [1] is what I use. It works well enough for me (without knowing much about hg at all) in keeping up with local hg repos of SDL & friends when I find myself needing to use a dev branch or make local changes to the source files.

There’s also git-hg [2], but the results do not always appear to me to be lossless, when looking at branches and such.

Cheers,
Jeffrey Carpenter
<@Jeffrey_Carpenter>On 2014/07/ 08, at 18:49, Robotic-Brain wrote:

I’m hesitant to learn hg in fear of confusing it with git (the syntax seems to be nearly identical)
so I would like to see a git repository - not necessarily github - so you could host it on libsdl.org

aren’t there tools to sync git and hg?

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

T_Joseph_Carter · July 9, 2014, 3:56am

I have no opinion on git and github vs. hg, but I will say that I
agree with Ryan about maintaining control over the infrastructure to
the greatest extent possible. I’ll cite the reasons he didn’t want
to go into in detail, plus many more of my own experience. To be
dependent on any silo, even a presently “open” one, invites disaster.

That said, if there were a compelling reason other than fashion sense
to switch to git, I’d say it was worthwhile. At this point, simply
because of its fashionable status, everyone either does or should
learn it anyway. But the fact is that Mercurial is not lacking by
comparison.

In fact the only complaint I have whatsoever with SDL’s current setup
is that the repository is a pain to clone or otherwise manipulate
because the tree is massive. This problem isn’t limited to
Mercurial.

Back in January, Aggelos Kolaitis proposed merging some ancient
intermediate changesets?that’s IMO an interesting idea. Of course
nobody replied, because it would require a fresh clone for everyone,
which isn’t a great idea.

If git’s partial cloning weren’t limited as it is, it would be a
worthwhile solution. But it is, and so it’s not.

JosephOn Tue, Jul 08, 2014 at 04:07:53PM -0400, Ryan C. Gordon wrote:

Hi, I’m part of a small team in Google that is working on technology for
game developers. A couple of our recent releases are
https://github.com/google/liquidfun and
https://github.com/google/flatbuffers .

(I haven’t seen liquidfun before, but I saw FlatBuffers the other
day, and it looks really promising! It’s seems to be a good
improvement over Protocol Buffers.)

I was wondering whether there is any appetite in the SDL community to
publish an official mirror of the Mercurial repository to github (using
a tool like hg-git)? This could make it easier for open source projects
with dependencies on SDL to include a reference to the project’s source
using a git project reference (e.g git submodules).

I certainly can’t stop you, but I would rather you not.

People will assume the GitHub repo is the official location,
because GitHub does this to people for some reason.

People put my various projects on GitHub mirrors just for the sake
of having a git mirror (fine), and then they stop pulling updates
(not fine at all).

People are going to send pull requests to the GitHub repo, which we
probably won’t see, and I’ll probably roll my eyes every time we have
to merge from there.

There will be two bugtrackers: ours, and the GitHub one.

There will be two wikis: ours, and the GitHub one.

There are references all over the place to hg changesets, and links
to https://hg.libsdl.org/ … we had fallout from this before when we
switched from CVS to svn, and again when we switched to
Mercurial…we can deal with that fallout for changing revision
systems, and if we ever move to git we will, but I don’t really care
for having two sets of this at once. It’s not clear that it’s worth
the confusion so someone can choose between typing “git clone” or “hg
clone”.

Submodules aren’t interesting to us. We changed our license to let
you statically link SDL, but we’d rather you have to struggle a bit
to do so.

And, personally important to me, but not necessarily anyone else:

We’ve been burned more than once by service providers and software
that we don’t control, and have spent an enormous amount of energy to
control all our infrastructure because of it. Now (with the exception
of the mailing lists for now), in the worst case, we can take our
domain registration and our daily server backup and move somewhere
else and carry on as before. I’m not interested in cooperating with
yet-another Cloud Service provider that will, ultimately, make people
ask why we aren’t using the cloud service provider more instead of
the perfectly good server that’s completely under our control. Real
talk: there are lots of interesting features there, but you should be
using GitHub less.

–ryan.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Aggelos_Kolaitis · July 9, 2014, 7:58am

So others have the same feeling that the repo is getting too massive as well? That’s good to hear. And I sincerely consider this to be a very good idea.

Btw, this wouldn’t have been an issue with git, since git allows one to do ‘git clone repo --depth 1’. This is a huge timesaver for people that are not interested into cloning all 2000 commits of a package and just want the newest version.

– Aggelos KolaitisOn 9 ??? 2014, at 6:56 ?.?., “T. Joseph Carter” wrote:

I have no opinion on git and github vs. hg, but I will say that I agree with Ryan about maintaining control over the infrastructure to the greatest extent possible. I’ll cite the reasons he didn’t want to go into in detail, plus many more of my own experience. To be dependent on any silo, even a presently “open” one, invites disaster.

That said, if there were a compelling reason other than fashion sense to switch to git, I’d say it was worthwhile. At this point, simply because of its fashionable status, everyone either does or should learn it anyway. But the fact is that Mercurial is not lacking by comparison.

In fact the only complaint I have whatsoever with SDL’s current setup is that the repository is a pain to clone or otherwise manipulate because the tree is massive. This problem isn’t limited to Mercurial.

Back in January, Aggelos Kolaitis proposed merging some ancient intermediate changesets?that’s IMO an interesting idea. Of course nobody replied, because it would require a fresh clone for everyone, which isn’t a great idea.

If git’s partial cloning weren’t limited as it is, it would be a worthwhile solution. But it is, and so it’s not.

Joseph

On Tue, Jul 08, 2014 at 04:07:53PM -0400, Ryan C. Gordon wrote:

Hi, I’m part of a small team in Google that is working on technology for
game developers. A couple of our recent releases are
https://github.com/google/liquidfun and
https://github.com/google/flatbuffers .

(I haven’t seen liquidfun before, but I saw FlatBuffers the other day, and it looks really promising! It’s seems to be a good improvement over Protocol Buffers.)

I was wondering whether there is any appetite in the SDL community to
publish an official mirror of the Mercurial repository to github (using
a tool like hg-git)? This could make it easier for open source projects
with dependencies on SDL to include a reference to the project’s source
using a git project reference (e.g git submodules).

I certainly can’t stop you, but I would rather you not.

People will assume the GitHub repo is the official location, because GitHub does this to people for some reason.

People put my various projects on GitHub mirrors just for the sake of having a git mirror (fine), and then they stop pulling updates (not fine at all).

People are going to send pull requests to the GitHub repo, which we probably won’t see, and I’ll probably roll my eyes every time we have to merge from there.

There will be two bugtrackers: ours, and the GitHub one.

There will be two wikis: ours, and the GitHub one.

There are references all over the place to hg changesets, and links to https://hg.libsdl.org/ … we had fallout from this before when we switched from CVS to svn, and again when we switched to Mercurial…we can deal with that fallout for changing revision systems, and if we ever move to git we will, but I don’t really care for having two sets of this at once. It’s not clear that it’s worth the confusion so someone can choose between typing “git clone” or “hg clone”.

Submodules aren’t interesting to us. We changed our license to let you statically link SDL, but we’d rather you have to struggle a bit to do so.

And, personally important to me, but not necessarily anyone else:

We’ve been burned more than once by service providers and software that we don’t control, and have spent an enormous amount of energy to control all our infrastructure because of it. Now (with the exception of the mailing lists for now), in the worst case, we can take our domain registration and our daily server backup and move somewhere else and carry on as before. I’m not interested in cooperating with yet-another Cloud Service provider that will, ultimately, make people ask why we aren’t using the cloud service provider more instead of the perfectly good server that’s completely under our control. Real talk: there are lots of interesting features there, but you should be using GitHub less.

–ryan.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Tim_Angus · July 9, 2014, 10:31am

I can see where you’re coming from, but for what it’s worth I feel that
GitHub is much, much better than the things that have come before it.
They seem to be adhering to the do one(ish) thing well, and this is
good. Unlike e.g. sourceforge who did EVERYTHING but did nothing
particularly well.

Related; I think it’s time we acknowledged that hg has lost the DCVS
competition. It has a better UI and is arguably easier to extend, but
for most purposes git is just better. I learned hg first and was
resistant to moving to git for various reasons, but I can’t imagine
going back now.On 08/07/14 21:07, Ryan C. Gordon wrote:

Real talk: there are
lots of interesting features there, but you should be using GitHub less.

Nikos_Chantziaras · July 9, 2014, 1:36pm

I’ll just throw my two cents here.

I’ve contributed a few patches to SDL_mixer, and things seemed more
difficult then they ought to be. When I’m using Git, working with code
seems a lot easier. Unless I was doing something wrong, maintaining my
own fork and working with branches and then rebasing everything before
submitting the patches was a real hassle with mercurial. At one point I
was forced to actually export patches on file with hg and then import
them, or try to because hg seemed unable to deal with some conflicts. In
Git, this is made easier and I can rebase in a new branch and then
rebase again, or fast-forward or cherry-pick.

The result is that in the end I actually stop caring. At some point, Sam
asked me to rebase a rather large-ish patch set so he can merge it
(introducing simultaneous music stream playback), but I never got around
to it simply because I didn’t want to deal with mercurial again.

GitHub makes things even easier, by being able to fork and submit pull
requests, which can be inspected and commented on (even on a line by
line basis) in a very nice way.

In GitHub, you can also disable the issue tracker and wiki and use
external ones. Even if GitHub gets run over by a bus, this just means
you move the official repo somewhere else, no big deal.On 08/07/14 23:07, Ryan C. Gordon wrote:

[…]

There are references all over the place to hg changesets, and links to
https://hg.libsdl.org/ … we had fallout from this before when we
switched from CVS to svn, and again when we switched to Mercurial…we
can deal with that fallout for changing revision systems, and if we ever
move to git we will, but I don’t really care for having two sets of this
at once. It’s not clear that it’s worth the confusion so someone can
choose between typing “git clone” or “hg clone”.

Robotic-Brain · July 9, 2014, 1:54pm

If you totally do not want to host on github, just use the
"Integration-Manager Workflow" from the git book, where the “blessed
repo” is github and the “integration manager repo” is the master on
libsdl.org

git is a DVCS after allAm 09.07.2014 15:36, schrieb Nikos Chantziaras:

On 08/07/14 23:07, Ryan C. Gordon wrote:
In GitHub, you can also disable the issue tracker and wiki and use
external ones. Even if GitHub gets run over by a bus, this just means
you move the official repo somewhere else, no big deal.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org