[Scummvm-devel] Switching from SVN to git, mercurial or bazaar

Max Horn max at quendi.de
Mon Jun 8 22:22:00 CEST 2009


Hi folks,

I am replying to several mails at once. I hope it won't be too  
confusing, I tried to give context.


Am 08.06.2009 um 17:34 schrieb Pierre-Yves GĂ©rardy:

> Actually there is a Mercurial plugin that allows to transparently  
> push/pull code to/from Git repositories, with full history both ways.
>
> http://github.com/blog/439-hg-git-mercurial-plugin
[...]

Hey, that sounds pretty cool. It might allow us to have "the best of  
both worlds" :).



Am 08.06.2009 um 21:15 schrieb Matthew Hoops:
> Another option might be to keep both SVN and also have the git/hg/bzr
> one up and have them automatically sync themselves. FFmpeg does
> something like that to keep its SVN/Git repos in sync. Not sure if
> this is possible at SourceForge, though.


No, I don't think they allow it. I haven't look at FFmpeg, but how  
this is in general done is to provide a read-only SVN interface to the  
repository; I think each of git, hq and bzr allows that.

See <http://blog.fallingsnow.net/2007/08/17/maintaining-an-svn-mirror-directly-from-git/ 
 >,



>
> Am 08.06.2009 um 15:21 schrieb Filippos Karapetis:
[...]
>> In the end of the day, branching doesn't happen very often in  
>> ScummVM (i.e. once every 6 months for releases and once every year  
>> for GSoC), so that's probably not the killer feature that will urge  
>> us move on to git...

Kostas already replied to this, but let me just emphasis this one  
point: We don't use branching that often exactly *because* it is  
annoying and difficult in Subversion, and hence we only do it if we  
must. In particular, the merging capabilities of all three named DVCS  
are vastly better than anything Subversion can do. Being able to use  
local branches (somethign SVN doesn't have) can be very helpful, too.

>> Come to think of it, apart from offline commits, I don't see a real  
>> reason for change, perhaps someone could enlighten us more on the  
>> potential benefits of such a move?

This is still an excellent question, of course. Actually, being able  
to work offline is a *huge* advantage in my eyes. Well, I'll try to  
list some advantages I see:

* Allows offline work -- ideal when you are on an airplane trip, on  
vacation *g*, or just want to sit in the garden without internet while  
coding ;)

* Even when working online, local commits allow "staging" a bigger  
commit. For example, when I work on refactoring, I make many small  
gradual changes. It's convenient to be able to commit ever each, so  
that I can verify my transformations broke nothing. I repeat this  
several times, possibly committing some fixes to some of the earlier  
commits as I go. When I am done, I can for example choose to merge all  
these commits into one/a few big ones (which has pros and cons); or I  
can rearrange them; or at least merge my "bug fix" commits, thus  
hiding all my screwups (i.e., you'll see far fewer "oops" commits for  
me ;).
(by the way, In general, I recommend to everybody to make relatively  
small commits; if you clean up three completely different parts of  
code, and each makes lots of changes, I recommend three separate  
commits instead of one big which mixes everything. You can do that  
with any VCS, but I feel that a DVCS is particularly suited to this  
approach).

* Another advantage of offline work resp. cloning the repository: We  
are not bound to a local server. No more "dang I cannot commit, the  
server is offline". We won't be dependent on a single central instance  
(it's not exactly a substitute to backups, but close to ;).

* Yet another advantage of "offline": Speed. I can examine the full  
rev log, or do an "annotate"/"blame" in virtually no time, because all  
the data is on my local HD.

* It will be *very* helpful for all 3rd party engine or backend  
developers. Right now, they must keep their engine in a separate  
repository, and if the engine is later integrated, it's history is  
lost (unless lots of extra effort is invested into the merge). With a  
DVCS, they can just clone the ScummVM repository. Then, add their  
engines/ subdir, modify other files. And commit all their changes.  
When we make upstream changes, they can merge those in. It's virtually  
the same as working on an official engine. And if multiple people want  
to work on that 3rd party engine, they can share this repository (kind  
of a "mini-fork"). And if the engine becomes official, we can  
seamlessly merge it will full history.

* The whole branching business, but that was already covered  
elsewhere ;-).

* One feature I absolutely love is "git bisect": When something is  
broken (e.g. loading in SCI), I do "git bisect start; git bisect bad",  
then go to a revision I know to be good (e.g. "git co head~50" to go  
back 50 revs); then test that; if it's really good, I do "git bisect  
good". This starts a binary search: Git will now checkout the revision  
between head and head~50; I test it and mark it as either bad or good.  
Rince and repeat till you found the revision that introduced the bug.  
Mercurial also has an extension for this (hbisect), I don't know about  
bzr.
Of course you can do that with subversion, too. But that's over the  
network, and painfully slow, so I rarely do it. With git, I do it a  
lot, and it's super fast. I really love this features :).


There's certainly more, but I think that's already some pretty good  
reasons for a switch.



Bye,
Max





More information about the Scummvm-devel mailing list