Rich Freeman wrote: > 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.
I was expecting a bump but not climbing a hill. lol Breaking things to the point I can't emerge anything, that's a pretty big bump. ;-) Makes me want to get out my tractor and box blade. >> 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 > > It appears it was live even if it wasn't supposed to be. I got the updated version. Maybe someone forgot to flip a switch until things got settled?? Oh well. I've been reading -dev for ages. I been using Gentoo since about 2003. I try to at least keep a eye on the changes that are coming. I was aware that the git change was coming and have read where many are well, tickled pink about it. I'm fine with it because it seems to be a process that is heading toward something better. I just wasn't expecting this little hick-up. At least it wasn't that other thing that really gets on my nerve, that I don't want to mention. ;-) It broke my rig. That ain't good. I'm going to miss p.g.o. Sometimes, I go there and look to see if anything I'm interested in has been updated. KDE, Firefox, GIMP, k3b etc etc. If they haven't, I generally wait a day or so, especially if I know a update is coming and as soon as it is available, I want to sync and update. That saves a tiny fraction of load on servers and a little of my time as well. I see that someone else filed a bug about this. That was my reason for asking. I wanted to be sure it was a bug and not just a bad sync, corrupted bad not just a bumpy road bad, before I filed one. If I file a bug, I'm pretty much positive it is a bug. Anyway, here it is and it seems to be fixed. https://bugs.gentoo.org/show_bug.cgi?id=557184 I might add, sync is taking a LONG time again. Of course, my DSL is a bit slower than some folks. At least the bumpy road got smoothed out tho. It seems to be working again. Maybe next sync will be back to normal. Thanks much. Dale :-) :-) Oh, keep us updated on when we can change our settings to the new and improved stuff, after the bumpiness is gone of course. :-D
