The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.

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

How exactly could this make it easier?


Am 08.07.2014 20:30, schrieb Stewart Miles:

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


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.

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


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

(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 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

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

On Tue, Jul 8, 2014 at 1:07 PM, Ryan C. Gordon wrote:


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


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


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


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.).
 


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
 

Hi,

Am 08.07.2014 22:07, schrieb Ryan C. Gordon:

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


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,
Daniel

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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

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

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

- snip -
- 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

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Hi,

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

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
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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 -

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

- snip -
- 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

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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

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.

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

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

On 7/8/2014 4:49 PM, Robotic-Brain wrote:

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.

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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.

1. http://www.sourcetreeapp.com/
2. http://offbytwo.com/git-hg/

Cheers,
Jeffrey Carpenter


On 2014/07/ 08, at 18:49, Robotic-Brain wrote:


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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:
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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 Kolaitis

On 9 Ιουλ 2014, at 6:56 π.μ., "T. Joseph Carter" wrote:

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

On 08/07/14 21:07, Ryan C. Gordon wrote:

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.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

On 08/07/14 23:07, Ryan C. Gordon wrote:

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.

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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 all

Am 09.07.2014 15:36, schrieb Nikos Chantziaras:
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

A lot of people here seem to be talking about features specific to sites like Github and Bitbucket[1], rather than features unique to Git over Mercurial.


I don’t have an opinion on an official mirror of SDL, but if it were done it would make much more sense to do it on Bitbucket rather than Github since the former supports Mercurial natively and still has most of the features being talked about (forking, pull requests, etc.)


For people having trouble with Mercurial itself, tools like SourceTree[2] (already mentioned earlier in the thread) make it easier to use both Git and Mercurial.


1: https://bitbucket.org/features
2: http://sourcetreeapp.com

On Jul 9, 2014, at 10:36 AM, Nikos Chantziaras wrote:

2014-07-09 15:54 GMT+02:00 Robotic-Brain:


Quoted for emphasis.


Integration-Manager Workflow on the git manual.

Am 09.07.2014 16:04, schrieb Alex Szpakowski:

Am 09.07.2014 09:58, schrieb:

I think this is a very compelling reason for git. I don't know anything
about hg though, so I don't know if there is an equivalent
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Looks like mercurial may be getting shallow clones in the near future...


On Wed, Jul 9, 2014 at 10:59 AM, Robotic-Brain wrote:

Seems no one is against a github clone, or whatever feels demanded, as much as it just keeps an hourly?/daily sync cron job, and informs so.

hghub anyone?




On Wed, Jul 9, 2014 at 5:08 PM, Alex Barry wrote:

Nah, Hg has nothing like that

On 9 Ιουλ 2014, at 5:59 μ.μ., Robotic-Brain wrote:

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I say stick to one or the other. Either one is adequate, but not both at the
same time. Since the maintainers and primary developers of SDL prefer hg, the
addition of github to the mix would result in a stale cache, mismatched tools, a
one-way patch stream, and added confusion.


On 07/09/2014 11:47 AM, Juan Manuel Borges Caño wrote:
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I would vote more or less for Git.
 It is a lot faster than Mercurial.
Other than that it doesn't matter where the repository is.



On Wed, Jul 9, 2014 at 5:28 PM, John wrote:

Y'all can keep discussing the merits and flaws of git and Mercurial
(this is actually a very interesting conversation and I'm learning
things from it!), but to be clear: switching to git, or having an
official git mirror, is not happening at this point in time.

As I said before, anyone is welcome to clone to GitHub or
whatever--that's the point of DVCS--but we won't be doing anything
official on our end.

--ryan.


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

You can do something similar with hg by specifying a changeset as
your clone's root. Mercrial's way does allow you to push changes
back, but other clones based on your repository must specify the same
root…

Joseph


On Wed, Jul 09, 2014 at 10:58:10AM +0300, wrote:

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Ryan:

I think that's a clear answer to Steward's question "whether there is any appetite to publish an official mirror of the Mercurial repository to github".


Cheers.

Lurker here, but I don't see what would need to be so "official" about a repo. As long as the people in charge of the repo sync in a timely fashion and forward any reported issues on github to the official bugtracker... that's pretty much it. No SDL "official" commiter has to ever touch that repo and OP already said the repo readme could clarify any issues. Again, I'm missing the "official" part...

Cheers,




On Wed, Jul 9, 2014 at 5:20 PM, Julian Winter wrote:



--

I'm glad that my first post to this list generated such interesting traffic

Thanks for the feedback on the mirror, I completely understand and respect your position.


My motivation for an *official* git mirror is to allow:

1. Users to have confidence the mirror is always up to date.

2. Users to have confidence the mirror is not a fork.
3. Projects to reference the *source* of SDL using git submodules at a particular commit.



I'm particularly interested in #3 since we (Fun Propulsion Labs at Google) are building pieces of technology and applications that reference existing open source libraries and would prefer not to snapshot stuff into our trees.  At the moment we've taken the snapshot approach to LiquidFun https://github.com/google/liquidfun (snapshotting googletest and freeglut) but this doesn't scale when projects have multiple dependencies.



Using one off scripts to download dependencies from different source control systems isn't particularly desirable since this ends up one-off scripts that need to be maintained for multiple platforms and copied into each project that requires them etc. etc.  The Chrome and Android teams use repo https://code.google.com/p/git-repo/ to handle multiple git projects, where they have a load of git projects which are all pulled down to a developers workstation using yet another git project to maintain a manifest of projects to pull.  This is cool for huge projects like Chrome and Android but could be overkill to smaller technology components hence the git submodules approach ( see what Cocos2d-x is starting to do here as an example https://github.com/cocos2d/cocos2d-x ).


Anyway, that's just where I'm coming from.  As I said, I understand the hesitance in mirroring so it's possible that *if* we open source something based upon SDL we'll setup a git mirror that allows #1, #2 and #3 above.


Cheers,
Stewart



On Wed, Jul 9, 2014 at 1:39 PM, Iván Vodopiviz wrote: