| 1 |
On Sun, Aug 9, 2015 at 8:15 PM, Dale <rdalek1967@×××××.com> wrote: |
| 2 |
> |
| 3 |
> I'm sure I'm not alone on monitoring -dev to see upcoming changes. I |
| 4 |
> noticed they switched to git or something and it seems to have caused a |
| 5 |
> bit of trouble. |
| 6 |
|
| 7 |
There are a few issues they're working through, but nothing really |
| 8 |
serious. There were bound to be a few bumps with the change, and most |
| 9 |
of the -dev posts are around trying to re-establish conventions, |
| 10 |
especially around things like commit comments. The desire is to make |
| 11 |
the history easy to read, parse, etc, but it isn't really stopping |
| 12 |
work from getting done and nobody is going to care if their history |
| 13 |
looks a little different. |
| 14 |
|
| 15 |
> At least I think it may have. I did my usual 'eix-sync |
| 16 |
> && emerge -uvaDN world'. The sync took MUCH longer than usual. I'm |
| 17 |
> talking a WHOLE LOT longer than usual. My first thought, one time thing |
| 18 |
> because of the changes, maybe. Then I got a screen full of this sort of |
| 19 |
> stuff. |
| 20 |
|
| 21 |
Interesting. As I understand it rsync generation should be turned |
| 22 |
off, but maybe some changes did make their way out. I don't believe |
| 23 |
commits are getting to the rsync servers right now, so you might see a |
| 24 |
delay in package updates for a day or so. |
| 25 |
|
| 26 |
Whether you've already seen it or will see it in the future, I would |
| 27 |
expect the first rsync to be much longer. The git migration probably |
| 28 |
touched virtually every file in the tree in some way, which means that |
| 29 |
rsync is going to be modifying just about everything. |
| 30 |
|
| 31 |
I think it actually remains to be seen whether rsync is still the |
| 32 |
fastest way to sync the new tree. If you sync from anonymous git |
| 33 |
(which is supported by repos.conf) that would probably be pretty |
| 34 |
efficient, since by design git keeps track of what did and didn't |
| 35 |
change and it doesn't need to read every inode in /usr/portage to |
| 36 |
figure it out, unlike rsync. I made a validator that finds what |
| 37 |
changed between git revisions and you can do it VERY efficiently by |
| 38 |
comparing the tree one directory level at a time (you can tell whether |
| 39 |
anything in app-backup changed in a commit without having to read any |
| 40 |
of the files, and if something changed you can repeat that one level |
| 41 |
at a time until you read the actual files that changed - it is a O(log |
| 42 |
base <dir-size>) tree search times the number of commits (O(n))). |
| 43 |
Now, for enough time passing (many months most likely) rsync might be |
| 44 |
more efficient since at some point you end up reading almost all the |
| 45 |
files anyway and rsync doesn't care if a file changed three times or |
| 46 |
if it changed once. |
| 47 |
|
| 48 |
TL;DR - don't worry about it too much, but don't be surprised if |
| 49 |
emerge --sync doesn't give you anything new for a day or two. You can |
| 50 |
of course clone any of the URLs under |
| 51 |
https://gitweb.gentoo.org/repo/gentoo.git/ to get the latest changes |
| 52 |
now straight from git. We're up to 210 commits in git already today. |
| 53 |
|
| 54 |
I'm sure the transition could have been less bumpy, but I'm glad we're |
| 55 |
finally seeing it happen. This has been in the works for a very long |
| 56 |
time and sometimes you just have to pull the trigger. If rsync is |
| 57 |
down for a day it isn't the end of the world. |
| 58 |
|
| 59 |
Oh, and a historical repo is posted at: |
| 60 |
https://github.com/gentoo/gentoo-gitmig-20150809-draft |
| 61 |
(that isn't official - I'm sure the official one will be |
| 62 |
gentoo-hosted, but robbat has his hands plenty full already) |
| 63 |
|
| 64 |
-- |
| 65 |
Rich |
Archives