[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