[Tux4kids-tuxtype-dev] Git use this summer
David Bruce
davidstuartbruce at gmail.com
Tue Apr 27 15:45:54 UTC 2010
Hi,
Now that the GSoC assignments have been finalized, we have a few weeks
for everyone to get "bonded" before the official coding period starts.
As most of you know, we switched from Subversion to Git over the
winter. While my experience with Git has so far been almost uniformly
positive, I should make it clear that I am by no means a Git expert.
Git is exceedingly flexible, so there are almost limitless ways that
we could set up our project "workflow". For now, I figure that our
small project can use it more or less the same way we used to use svn,
with everyone pushing and pulling from the repositories on Alioth. If
anyone out there is a bona fide Git guru, or has worked in other
projects that use Git in a sophisticated way, please feel free to
contribute any insights.
One issue has been the extent to which we use branches. Last year, we
had a lot of pain at "merge time" trying to get the svn branches
re-incorporated into the trunk. So, one possibility has been to just
work directly in "master" (Git's counterpart to "trunk"), and try not
to push in any changes that break things. Basically, we should try to
keep "master" in a continuously releasable state. The only problem I
see is that the student then has to push his new code into master
before his mentor can see it or review it.
So, I would favor creating gsoc branches for each project as before.
That way the student and mentor can both see the new code before it
gets merged. The way we can avoid the merge pain is by frequent
merging of changes back into master (and also frequent merging from
master into the branches). Git offers a couple of ways to do this,
"git merge" and "git rebase" - AFAICT they result in the same state of
the code, but with different commit histories. The relative
advantages of the two are about where my level of Git understanding
gets fuzzy.
Practically speaking, however, we don't have so much to worry about
this summer. Jesus' project is completely independent.
tux4kids-admin (Vikas/Michal) and libt4k-common (Brendan/me) are also
independent, but both will also require changes in tuxmath and tuxtype
themselves. Wenyuan's SVG work raises an interesting point -
currently tuxmath itself contains the SVG-handling code, but that is
part of what will be included in libt4k-common. So, one question is
whether Wenyuan should start from tuxmath's current code, or enhance
the SVG code in libt4k.
So, we really just have three projects/branches that could collide
with each other (or maybe four if you count any tuxmath/tuxtype work
that goes on this summer independent of GSoC).
Best,
David
More information about the Tux4kids-tuxtype-dev
mailing list