Hi all,

Here's a quick update on the git-migration experiment. We've pretty much 
settled on doing one large repository for the entire tree for a couple 
of reasons:

- It's realistic to complete in the short term: It doesn't require a 
level of rearchitecture that will delay it forever. The alternative of 
one repo per package requires changes to many of our tools, and 
enhancements to git of varying scopes.

- Many of the biggest problems with it have been solved. For example, 
this week I found a tool that should retain history when merging a 
package in an overlay to the main tree, even if there is no common 
ancestry.

- The remaining problems are not blockers. For example, there is no way 
to check out just part of a tree. Disk space isn't so hard to find now 
that this is a requirement.

- Robin has commented that he doesn't know what kind of server-side 
resources are required. I've talked to a number of git admins 
(kernel.org, fedora, freedesktop.org, gnome), and they have all said the 
hardware requirements for git are negligible. They don't have any 
resource on their servers that's being used up. It's gitweb that is 
somewhat resource-intensive.


The next thing I can think of that needs to happen is putting together a 
concrete plan for how a migration would work and making sure all 
necessary tools support it, on all sides: developer, user, and 
infrastructure. We've got portage support now, but I don't have any idea 
what needs to change on the backend infra servers.

-- 
Thanks,
Donnie

Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com