git migration

[Omari Stephens]

Hey, all

For Android, we wrote a tool on top of git (called "repo") that allows usto
consider a number of associated git repositories as a single repo repository.
Basically, our source tree is split into a bunch of "projects," where each
project is a separate git repository.  And simplistically, one can think of repo
as a for loop.

Unfortunately, I personally haven't started working with git/repo yet, soI
can't offer any personal insight.  As such, I'm not yet well-versed on all of
the reasons why we went this route, and what all of the drawbacks are.  Acouple
things that mattered for us, mentioned in a blog post on repo at [1], are:

* We want to delineate access control based on location in the tree.
* We want to be able to make some components replaceable at a later date.
* We needed trivial overlays for OEMs and other projects who either aren't ready
or aren't able to embrace open source.
* We don't want our most technical people to spend their time as patch monkeys.

Furthermore, a multi-million-line git repository could easily be very slow given
the amount of time required to traverse the hierarchy and build the tree hash.

There are two significant drawbacks for us:
- We have no way to perform an atomic commit across different projects.  This
means, among other things, that it's possible to end up with a commit that's
partially checked in (for instance, if there's a merge failure in one project
but not another).  Unfortunately, to put it generally, "distributed coherency is
very hard and/or very slow"
- There is no way to mentally determine the ordering of two commits.  That is,
whereas in a centralized VCS if I see a bug at r1234 that was supposedly fixed
at r1221, I immediately know something's wrong since 1234 > 1221.  With git,
though, knowing that you're considering commits ...abcdef00 and ...00000001
tells you nothing about the ordering of those two commits — you must explicitly
check with git to know which came first.

To help deal with this second issue, we created a naming scheme that
encapsulates both date and branch information.  As such, if someone says that a
bugfix should be in "foo," and I know that I have "bar," then I can again
definitively determine if that bugfix should or should not be in my build
without having to check with git.  This solution works pretty well, but it also
takes time and effort.  However, it's probably fairly scriptable.



To conclude, I'm not saying that using repo (and potentially gerrit, our
change-management system) is or is not the way for xfce to go — Idon't really
know what's valuable or not for xfce.  It's just something to consider.  And as
a final note, keep in mind that these are all new tools, and as such, come with
their fair share of rough edges.  That said, most of the Android dev teamhas
switched over, so it's gotten a fair bit of a workout already, and will only get
better (in theory :o)

[1]
http://google-opensource.blogspot.com/2008/11/gerrit-and-repo-android-source.html
[2] http://source.android.com/download/using-repo

HTH,
--xsdg