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.

This is my test attempt at converting the SDL Subversion repository to
Mercurial.

http://hg.icculus.org/icculus/SDL/

Feel free to clone, but this repo may be destroyed and rebuilt again
while I play around. Eventually, this will move to libsdl.org to replace
the Subversion repository.

This is just SDL; I have filtered out the other projects and spent a
great deal of time hand-editing the Subversion dump to clean up the
revision history, and will be packaging them in separate repos. This
repo has the 1.3 branch as the default, and SDL-1.2 as a named branch.
All revision history in the Subversion repo (back to 1.2.0) is in the
Mercurial repo.

Upon cloning this repo, I was a little horrified to see how much disk
this eats:

$ du -hs SDL-hg
100M SDL-hg

One hundred megabytes!

This is worth knowing though: that seems like a big collection of bytes,
but that's a working copy plus every change we made to SDL, ever.

For comparison, here's a fresh checkout of the trunk and
branches/SDL-1.2 from Subversion:

$ du -chs SDL SDL-1.2
50M SDL
37M SDL-1.2
86M total

So it's not too bad, then, especially when you consider that the svn
checkout didn't have any of the GSoC (etc) branches (or any of the
revision history at all).


Here's all you really need to know about Mercurial.

- The best quick-start tutorial I've read is Joel Spolsky's new
hginit.com. You should read it. It's interesting and funny. I've read a
lot of quick-start tutorials, and no other does it as well.

- The important thing to know, as a subversion user, is to stop fearing
branching. Mercurial works best when you have a bunch of little ad-hoc
branches weaving around each other.

- When committing new changes, keep the first sentence of the log
comment short and on a line by itself. It'll be used for the summary.

- More or less, most commands work like Subversion's, and there is a
TortoiseHg to match TortoiseSvn, if that's you're thing. But once you
start using things that Subversion can't do (bisect, record, shelve,
rollback, queues, etc), you're going to find yourself annoyed when you
have to work with a Subversion repository and can't use these extra
features.


Comments and questions welcome.

--ryan.

_______________________________________________
SDL mailing list

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

Oh awesome!


_______________________________________________
SDL mailing list

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

That's a great Mercurial tutorial!

On Fri, Feb 26, 2010 at 7:49 PM, Ryan C. Gordon wrote:



--
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC
_______________________________________________
SDL mailing list

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

Not awesome. If it ain't broke, don't fix it, and the SVN server isn't
broke. It's not that we "fear branching," it's that we don't really need
the added features that Mercurial brings to the table, and it's not
worth all the extra hassle of reimplementing a working system to get
functionality that SDL's development has never needed, and *then*
having to adapt to new paradigms to take full advantage of it! That's
just plain ridiculous IMO.



_______________________________________________
SDL mailing list

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

On 2/26/10, Mason Wheeler wrote:

Svn is simply outdated though. So, in a sense it IS broke.
If you are working on something in svn, then you can't drop what you
are doing and try a spur of the moment fix / feature, you must stop
your work, create a patch, revert your changes, the do what you wanted
to do in the first place, then once that is done, either commit or
revert your current stuff, and then, finally reapply the patch you
made in step A.

A huge waste of time, and a productivity killer.

With hg, you just shelve the changes, and come back to them at a later point.
It really makes the job of developing much easier, and less tedious.

The only big question here is how does hg handle EOL on windows
systems (aka CRLF <-> LF conversions).
_______________________________________________
SDL mailing list

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

...huh? I'm sorry, but I have no idea what you're talking about there.
A file is a file, and you can modify them just fine no matter what
version control system you're using, without long and convoluted
backup/patch/restore/whatever cycles.

If I'm working on something in SVN, and I need to create a quick
patch, I create the patch, check in only the files involved in the
patch, leave the patch in my codebase because I most likely
created the patch to solve a problem I was having in the first
place, and then go back to what I was doing originally.

The only possible scenario I can think of where this would
even potentially be problematic is if you're working on
something and then, halfway through, have to patch an
unrelated issue in the same file, which I've never actually
had happen to me. Is that what you're referring to?

_______________________________________________
SDL mailing list

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

And here they are...

http://hg.icculus.org/icculus/SDL_image/
http://hg.icculus.org/icculus/SDL_mixer/
http://hg.icculus.org/icculus/SDL_ttf/
http://hg.icculus.org/icculus/SDL_rtf/
http://hg.icculus.org/icculus/SDL_net/
http://hg.icculus.org/icculus/sdlweb/
http://hg.icculus.org/icculus/Maelstrom/

...I'm probably going to rebuild the base SDL repo with the revisions
sorted by branch...it's a little ugly for what eventually becomes
ancient history, but it makes the repo about 60 megabytes instead of 100
(and yes, that's smaller than the 1.3+1.2 Subversion checkout).

--ryan.


_______________________________________________
SDL mailing list

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

As someone that pulls from the repo, you won't see a big different
(you'll type "hg fetch" instead of "svn update"). But as someone that
commits work to the repo: trust me, it's a good step.

--ryan.


_______________________________________________
SDL mailing list

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

You enable an extension (shipped with Mercurial) in your config file.
The repo always wants to store in Unix endline format, and the extension
will convert to and from Windows format when used on a Windows machine.

(and it does basic heuristics to make sure you're really using a text
file it should be converting.)

http://mercurial.selenic.com/wiki/Win32TextExtension

If you're using Cygwin or some such environment, you may want to just
stick with the Unix endlines, of course.

--ryan.

_______________________________________________
SDL mailing list

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

I have to agree with Mason here.

Being an IT consultant in the real world, and having spent half of my working years
as SCM/Build manager, I fail to see the advantage here as well.

I hardly contribute any code to SDL, so my voice is worth zero on this issue, but this looks
like all those real life cases I have witness, where a company changed their complete build
infrastructure just because one of their managers decided to change to the flavour of the month.

So what are the real benefits Mercurial will bring to SDL developers, besides some new cool
features, that you *might* use?

How will be the expected productivity gains?

--
Paulo

On Sat, Feb 27, 2010 at 5:39 AM, Mason Wheeler wrote:

I've seen projects convert from SVN to Git and see huge increases in
the amount of contributions, largely because of the distributed nature
of the revision control system. With Subversion, the "commit access"
thing is probably more of a pain than most people realize.
Contributors have to do all sorts of painful things to make patches
work with newer revisions, and it gets messy really fast. This really
discourages contribution. Whereas, with something like Mercurial or
Git, you can very easily rebase your work on top of the latest code.
And being able to just "pull" changes into a repository is a huge help
for maintainers as well.

If you want to see a "for instance" of Git helping a project's
productivity, just take a look at Dungeon Crawl Stone Soup. We
switched from SVN to Git in about September or October, and we've been
very pleasantly surprised with the development pace and number of
contributions.

I would not so quickly dismiss a move to Mercurial.

- Steven

On Fri, Feb 26, 2010 at 10:48 PM, Paulo Pinto wrote:
_______________________________________________
SDL mailing list

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

I don't want to dismiss it, I was just pointing out what are the real reasons to change the SCM
in use.

SDL already changed from CVS to SVN, and Subversion has lots of nice features over CVS that
are really worth the upgrade, like the ability to rename directories.

Now I was just being sceptic about the gains. Do the majority of the SDL contributors face daily
issues that would be solved by moving to Mercurial or it is a solution in search for a problem?

If in 2 years time there is the new XYZ source control will it move again?

As I said, I hardly contribute any real code to SDL so my voice doesn't really count here, but I fail
to see the beneficts. Maybe I am too old and have seen this type of scenario too many times already.

--
Paulo

On Sat, Feb 27, 2010 at 8:00 AM, Steven Noonan wrote:

I am skeptical about this as well, what are the benefit of a mercurial repo?
Yeah, disk space savings are nice and dandy but not really "productive and killer feature"
One of the issues with opensource is that it moves, floats, converts files too often;
imho you should invest the time for building the hg repo to fix bugs and follow the feature request of the roadmap

i have one request though: if you do the switch please move *every* sdl project to hg, i don't want to have partial version checking in hg and partial in svn
bye
Vittorio


On Sat, Feb 27, 2010 at 8:39 AM, Paulo Pinto wrote:

If it makes anything easier for Ryan, Sam, and the others, then it's worth it.

Jonny D


On Sat, Feb 27, 2010 at 10:15 AM, Vittorio G. wrote:

Hello,


At risk of feeding the flames...

On 2010年02月27日 08:39, Paulo Pinto wrote:

CVS and SVN share the same development model. From a development point
of view there isn't much change nor gain in that switch. You only have
fancier software that is virtually the same in function.


It's a different development model that allows much faster changes,
testing, experimentation and development. You can do changes offline,
branch all the time, etc... It's much more flexible.


Well SVN -> HG is mainly done for going from a centralized development
model to a decentralized development model. CVS and SVN are both
centralized as I mentioned before and very inflexible. Moving to a
decentralized model will help development in many aspects.

Personally ever since I've started using GIT all the time I just can't
stand SVN much. It's just painful to use. The branching is awful, you
can't do offline commits and end up creating horribly large patches if
committing against master (to try not to have broken repo ever). Not to
mention that if you are doing small commits and someone else does a
commit more or less where you are working you risk collisions which will
mess up both of the developers.


Edgar
_______________________________________________
SDL mailing list

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

Hello,


Without wanting to call a flame war, I'm curious as to why you've chosen
Mercurial over other decentralized version control systems like say GIT
or Bazaar.

Anyway, it's a great move that will definitely benefit SDL a lot. Hurrah!


Edgar

On 2010年02月27日 04:49, Ryan C. Gordon wrote:
_______________________________________________
SDL mailing list

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

On Sat, Feb 27, 2010 at 10:15 AM, Vittorio G. wrote:

I was skeptical of the transition, too, and I'm a pretty strong
proponent of starting any new project on Git or Mercurial or Bazaar.

But then I remembered how controversial SDL's new licensing ambitions
(via Galaxy Gameworks) are. I think it might be a good thing for the
community if it's easier to work on SDL as a community without needing
to send one's improvements "upstream" if that would be incompatible
and/or not rewarding enough for them to ordinarily do that. Moving to
Mercurial will make that much easier.

--
http://codebad.com/
_______________________________________________
SDL mailing list

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

Yes, if it offers benefits equivalent to what Subversion brought over
CVS, and what Mercurial brings over Subversion.

(Fwiw, we converted to Subversion on April 26th, 2010. Almost 4 years
ago. Also fwiw: I know that because I could type "CVS" into the search
field in the Mercurial web interface. )

--ryan.

_______________________________________________
SDL mailing list

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

Here are my immediate thoughts:

I'm on airplanes for about 16 hours this upcoming week, and then will be
sitting in hotel rooms that may not have internet connections after
that. It was awesome when we switched to Subversion from CVS, because I
could diff and revert without a network connection. But I couldn't
commit. So I would spend time when I got home splitting all the work
into meaningful pieces. The alternative was one massive commit with
"worked on a bunch of stuff" as the log message. If two fixes
overlapped, it was even more effort to split up the patches. With
Mercurial, I just commit like I always would, and when I get to the
Internet, "hg push" will send it on to libsdl.org.

Bug hunting, airplane or not: you can't bisect with Subversion
(basically, you take all the revisions that could be buggy, try the one
in the middle. Works? Try the newer half of those revisions. Doesn't?
Try the older half. Keep halving until you find the specific patch that
caused the bug). This only works because all the revisions are on your
hard drive already. Likewise for things like blame and switching between
branches.

I work on several machines. Lots of times I'll do Mac work on my Linux
workstation, since it has a big monitor, and then move the changes over
to the Macbook with the smaller screen. Now instead of generating
patches and copying them to the other computer, I just commit them on
the Linux box and pull from that clone of the repository. The equivalent
in Subversion is to commit code that might not even compile to
libsdl.org (and everyone else, too). Here, I'm just efficiently pushing
it around my LAN, and once I get it all working, I do one push to
libsdl.org.

Even with universal internet access: we don't give out Subversion
logins. Now someone can just publish their own branch anywhere on the
internet, so we can see their work and pick and choose from it instead
of making them roll patches. Bitbucket (a Mercurial-flavored GitHub
thing) makes it easy for anyone to throw up their own fork of the
repository and publish their changes without having to own a public server.

If someone in a third world country on a dial up connection takes the
time to clone the repository once, everyone in the area can clone from
him instead of a server in California. Even if they just pass around a
USB stick or CD-R. Once they get the data, they're all individual,
complete, and functional source repositories.

If libsdl.org's hard drive catches fire, EVERYONE has a complete backup
of the repository.

If Sam decides he doesn't want to work on SDL any more, anyone can take
up the torch and have a complete history of the project to work from,
instead of the fork starting from whatever happened to be the last thing
he checked out.

Also: the tools are so much better. Even stupid things like being able
to enable the pager extension, so "hg diff" automatically pushes through
"less" to display changes. Or that the webview is built in (and you can
use it on your own system, not just as a cgi-bin set up on
svn.libsdl.org) Or that you can have extensions at all.

There aren't tons of .svn directories everywhere (just one .hg at the
top of the tree). You don't have to go to the top of the tree to do
normal things (diff and commit and such only function on the current
directory and subtrees in subversion).

The end user won't see much significant difference. I assume most people
get SDL from a tarball, or .deb, or .rpm. Those that get it from
revision control still just pull changes with a single command. But for
them, the "commit" command will now work, too.

--ryan.


_______________________________________________
SDL mailing list

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

(Really, this is the question I expected, not "why move from Subversion?")

I considered Mercurial and Git. I didn't even look at bzr, because it
seems like no one uses it but Ubuntu (which is no small user, of
course). For hosting on icculus.org, I got lots of requests for git and
hg, but none for bzr.

Also, I've been using fossil to commit some changes to the SQLite
project this past week, but it's not ready for heavy, general-purpose
use (although I do wish Mercurial would steal the handful of new and
very good ideas fossil brings to the table).


These are my primary reasons for choosing Hg over Git:

- Mercurial works better on Windows at the moment. Git used to need
Cygwin, and the msysgit project doesn't seem that active. Also, I've
seen a few too many comments from the Git developers that suggest they
aren't at all concerned about being hostile to users on Mac OS X and
Windows. As git's original purpose is to help the Linux kernel
developers, I guess that's not surprising, and if SDL wasn't so
concerned with portability, it wouldn't be a big deal. Fwiw, git seems
to be largely interested in Unix, but Mercurial _does_ need Python to
run, so we're probably going to have problems with obscure systems that
worked with Subversion. But the ones we really care about: Windows,
Linux, and Mac OS X? Mercurial is sweet.

- I personally find Mercurial to be a little easier to use. I think it's
a little more welcoming to people migrating from Subversion, too. I
think that git's index is a little scary to new users (indeed, Mercurial
Queues are probably moreso, but they're optional).

- All my projects were moved from Subversion to Mercurial many months
ago, so I have personal experience with it. This is both easier for me
(of course), and better that I can help other people with questions
during the transition, where I wouldn't be so helpful with git.

- Awhile ago, I made a comment that I liked Mercurial better, but git
would probably win the public's mindshare, with x.org and some other
major players migrating to it. Then several major projects (Python,
Mozilla, etc) chose Mercurial over git, bitbucket showed up, and Fog
Creek's new Kiln product really seem to be generating excitement for
Mercurial. There is something to be said for using the popular tech,
since it's more likely to get improvements. One of the many problems
with CVS is that no one was really working on it.


That being said, ultimately this is a personal choice that I'm
inflicting on everyone else. Git and Mercurial basically support all the
same features, and mostly have identical workflows. Any given
organization could probably be very happy with either, and both are a
quantum leap over Subversion. I could have very easily gone the other
way and written up a similar email about why I _didn't_ choose Mercurial.

--ryan.

_______________________________________________
SDL mailing list

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

Uh, 2006, not 2010.

--ryan.

_______________________________________________
SDL mailing list

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

Hello,


On 2010年02月27日 21:47, Ryan C. Gordon wrote:

That surprised me a lot too .


Yeah, Mercurial probably wins there. I've got some of my users running
git on windows and mac os x, but I do believe it is harder especially if
you want to avoid msys and friends on windows.


Probably true there also.


Going to throw my 2 cents although it's probably a bit superfluous. I
used to use SVN, then did the switch ~4 years back to HG. About 2 years
ago did the jump to GIT. From what I've seen, Mercurial is a bit more
newbie-friendly then GIT. However GIT is _much_ faster and from what
I've experienced seems to handle merges much better. I'm probably too
used to it now, but I've never really had an issue with branches and
tags with GIT, however I remember having a hard time with named branches
in HG. However that was a while ago and it's probably better.

As you mentioned, they are both functionally identical (decentralized
version control) and a _MAJOR_ jump over CVS/SVN imho. IMHO the
difference between HG/GIT mainly boils down to what you're used to and
maybe in some niche areas one will be better then the other.


Edgar
_______________________________________________
SDL mailing list

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

why not eh? seems a new versioning system appears every year or so, keeps you on your toes etc, really who gives a crap, oh! everyone who replied negativley to ryans post

ok i'll stop reading sdl list and posting irrelevant crap now.

I think this is great. If for no other reason, it will give me a
concrete excuse to mess around with a distributed versioning system,
which is something I've been wanting to do for a while.
_______________________________________________
SDL mailing list

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

Wow, this is freaking fast!

hg clone http://hg.libsdl.org/SDL
... yup, it's SDL 1.3!
hg clone SDL SDL-1.2
cd SDL-1.2
hg update SDL-1.2
... yup, it's SDL 1.2!

time on my machine:
real 0m22.740s
user 0m8.376s
sys 0m1.942s

Woo!
_______________________________________________
SDL mailing list

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

On 28 February 2010 08:40, Sam Lantinga wrote:

woooooooooooooooooooooooooo

we are so easilly pleased if only ordering a pizza was this fast

On 2/28/10, Sam Lantinga wrote:

I couldn't find any recent benchmarks for hg and git, so here's one. I
cloned the SDL hg repo, and converted it to git using
http://hg-git.github.com/ . Unfortunately this only cloned the default
branch, so I cloned a new hg repo with just the default branch for a
fair comparison. Each repo has 3229 commits, and all tests are
cache-hot.

0. version
$ hg version
Mercurial Distributed SCM (version 1.4.1)
$ git version
git version 1.6.4.4

1. Statusing -
hg$ time hg status

real 0m0.343s
user 0m0.304s
sys 0m0.039s

git$ time git status
# On branch master
nothing to commit (working directory clean)

real 0m0.039s
user 0m0.015s
sys 0m0.016s

2. Full log (not that useful in practice, but it shows both repos have
the same number of commits) -
hg$ time hg log | grep ^changeset: | wc -l
3229

real 0m2.300s
user 0m2.270s
sys 0m0.040s

git$ time git log | grep ^commit | wc -l
3229

real 0m0.366s
user 0m0.324s
sys 0m0.042s

3. Local clone (I run hg in quiet mode so it doesn't print all the
files it's checking out to make sure text scroll doesn't slow it down)
-
hg$ time hg clone -q newSDL newSDL2

real 0m4.134s
user 0m3.616s
sys 0m0.511s

git$ time git clone gitSDL gitSDL2
Initialized empty Git repository in /home/mjs/sdltmp/gitcheckout/gitSDL2/.git/

real 0m0.717s
user 0m0.407s
sys 0m0.173s

Results:
hg real / git real = 8.79, 6.28, 5.76 slower

Note it's entirely possible I've messed something up to make these
results invalid, so if anyone else tries a test and comes up with
different results let me know!

Anyway I can't speak to the non-quantifiable aspects of the two - I
just thought a side-by-side comparison would be interesting

-Mike
_______________________________________________
SDL mailing list

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