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