| 1 |
Starting a new thread for discussion: |
| 2 |
|
| 3 |
On Thu, Oct 2, 2014 at 7:06 PM, Michał Górny <mgorny@g.o> wrote: |
| 4 |
> Dnia 2014-10-01, o godz. 13:30:55 |
| 5 |
> Rich Freeman <rich0@g.o> napisał(a): |
| 6 |
> |
| 7 |
>> On Tue, Sep 30, 2014 at 10:08 PM, Rich Freeman <rich0@g.o> wrote: |
| 8 |
>> > If you'd like to contribute another agenda item, please reply to this email. |
| 9 |
>> |
| 10 |
>> I'll offer up a further topic for the git migration. |
| 11 |
> |
| 12 |
> I think that there are a few issues that the Council may actually want |
| 13 |
> to discuss. |
| 14 |
|
| 15 |
I was thinking of an additional item also worth consideration. |
| 16 |
|
| 17 |
So far the general plan has tended to be that we would do a full |
| 18 |
historical git migration, and the last commit would just be the active |
| 19 |
tree, which would then be further cleaned up (remove cvs headers, |
| 20 |
changelogs, switch to thin manifests, etc). |
| 21 |
|
| 22 |
I was thinking that it might make more sense to just make things |
| 23 |
really simple and ONLY migrate the active tree into the starting git |
| 24 |
repository. That is, basically take the rsync tree, remove metadata, |
| 25 |
and do a git init. (Then follow that up with removing changelogs, |
| 26 |
cleaning up cvs headers, and so on.) |
| 27 |
|
| 28 |
A historical migration could be done in parallel and released a few |
| 29 |
hours later. However, it would not be a contiguous repository. That |
| 30 |
is, the converted active tree commit would not have any parents. If |
| 31 |
you wanted to have a contiguous tree you would need to splice in the |
| 32 |
historical migration with git replace. |
| 33 |
|
| 34 |
Rationale: |
| 35 |
1. The historical git migration right now is not perfect. It |
| 36 |
probably will never be perfect, and there is debatable value in even |
| 37 |
trying to make it perfect. |
| 38 |
|
| 39 |
2. Somebody may very well want to improve on the historical git |
| 40 |
migration. If the converted repository doesn't favor any particular |
| 41 |
historical migration, then anybody can swap in the historical |
| 42 |
migration of their choosing. We aren't locked into a point-in-time |
| 43 |
migration that isn't the best that it could be. Anybody who wants a |
| 44 |
better migrated history can make their own. |
| 45 |
|
| 46 |
3. I fear that some are going to argue that we shouldn't do the |
| 47 |
migration until the historical migration is better than it is now. |
| 48 |
Just how much better it needs to be could be a matter of considerable |
| 49 |
debate. Not making a permanent connection between the historical and |
| 50 |
active migration sidesteps this debate. |
| 51 |
|
| 52 |
4. Decoupling the historical and active migration makes the active |
| 53 |
migration brain-dead simple. Downtime will be minimized, and we don't |
| 54 |
have the possibility of running into some issue hours into a migration |
| 55 |
where we need to try to figure out how to handle it. The active tree |
| 56 |
will migrate and cut over as quickly as things can be swapped out. |
| 57 |
The historical migrated tree will be posted whenever it is ready - |
| 58 |
likely within hours but if it takes longer there really is no big |
| 59 |
loss. We can fix it as many times as we like. |
| 60 |
|
| 61 |
5. In general I think that we're well past the point of diminishing |
| 62 |
returns. I personally don't see any return on improving the |
| 63 |
historical git tree beyond the general fun of tinkering with the code. |
| 64 |
In the meantime many are eager to see the active tree migrate. Let's |
| 65 |
stop holding up moving forward by obsessing about looking backwards. |
| 66 |
|
| 67 |
-- |
| 68 |
Rich |
Archives