| 1 |
Hi all, |
| 2 |
|
| 3 |
Here's a quick update on the git-migration experiment. We've pretty much |
| 4 |
settled on doing one large repository for the entire tree for a couple |
| 5 |
of reasons: |
| 6 |
|
| 7 |
- It's realistic to complete in the short term: It doesn't require a |
| 8 |
level of rearchitecture that will delay it forever. The alternative of |
| 9 |
one repo per package requires changes to many of our tools, and |
| 10 |
enhancements to git of varying scopes. |
| 11 |
|
| 12 |
- Many of the biggest problems with it have been solved. For example, |
| 13 |
this week I found a tool that should retain history when merging a |
| 14 |
package in an overlay to the main tree, even if there is no common |
| 15 |
ancestry. |
| 16 |
|
| 17 |
- The remaining problems are not blockers. For example, there is no way |
| 18 |
to check out just part of a tree. Disk space isn't so hard to find now |
| 19 |
that this is a requirement. |
| 20 |
|
| 21 |
- Robin has commented that he doesn't know what kind of server-side |
| 22 |
resources are required. I've talked to a number of git admins |
| 23 |
(kernel.org, fedora, freedesktop.org, gnome), and they have all said the |
| 24 |
hardware requirements for git are negligible. They don't have any |
| 25 |
resource on their servers that's being used up. It's gitweb that is |
| 26 |
somewhat resource-intensive. |
| 27 |
|
| 28 |
|
| 29 |
The next thing I can think of that needs to happen is putting together a |
| 30 |
concrete plan for how a migration would work and making sure all |
| 31 |
necessary tools support it, on all sides: developer, user, and |
| 32 |
infrastructure. We've got portage support now, but I don't have any idea |
| 33 |
what needs to change on the backend infra servers. |
| 34 |
|
| 35 |
-- |
| 36 |
Thanks, |
| 37 |
Donnie |
| 38 |
|
| 39 |
Donnie Berkholz |
| 40 |
Developer, Gentoo Linux |
| 41 |
Blog: http://dberkholz.wordpress.com |
Archives