/srv/irclogs.ubuntu.com/2012/08/20/#bzr.txt

stewarthi all! Help! We appear to have a broken BZR repository, we've tracked it down to lp:percona-server/5.1 revision 459, which was merging in a bzr-git branch. now people can't checkout lp:percona-server-5.100:41
fullermdstewart: You should mention the error to make it a little easier for people...01:57
fullermdAssertionError: ('not present: %r', StaticTuple('', '', 'TREE_ROOT'))01:57
stewartAssertionError: ('not present: %r', StaticTuple('', '', 'TREE_ROOT'))01:57
fullermdThat's happening during making the working tree.  So the data all transferred OK, just something in the latest rev makes dirstate all cranky.01:57
stewartfullermd, snap. that's it :)01:58
fullermdI can hack around it by doing a 'rm -rf *; bzr revert', and seem to get a good tree.01:58
stewarthuh01:58
stewartweird....01:58
stewartand concerning01:58
fullermdI don't know where to start on digging up what in the rev is doing unexpected things to dirstate.01:59
stewartat some point, this is going to completely blow up in our regression testing system.01:59
fullermdIt DOES create a fair bit of the tree before blowing up, but I don't know why.01:59
fullermdWell, it only happens on creating the tree from scratch.02:00
fullermdI can `update -r` among revisions fine, and revert has no trouble.  But doing an initial creation of the WT (e.g., bzr remove-tree ; bzr co .) croaks.02:00
fullermdThat's as far as I can go with it.  It may be enough to give a good start to someone who knows the code though.02:02
fullermdvila or jelmer may be around in 6 or 8 hours; they can probably help you more.02:03
fullermdBut at least you can work around it.02:03
stewartfullermd, yeah, it'd be nice to work out how to fix this... I'm currently thinking of re-creating history since the problem revision and overwriting the tree.02:04
wgrantstewart, fullermd: An HTTP branch worked fine for me.02:14
wgrantbzr+ssh did not02:14
stewartwgrant, okay... that's weird.02:14
wgrantRather02:14
wgrantRetrying to confirm...02:15
spivwgrant: that is very weird, if true!02:16
spivDefinitely sounds like something wonky in tree building/TreeTransform02:16
wgrantAh02:16
wgrantIt was also bzr 2.1.4 on the host that worked02:16
wgrantThat might be relevant02:17
spivwgrant: ooh, a regression then?  That's a useful hint!02:17
wgrantI'll retry HTTP with something newer02:17
fullermdYeah, I can't imagine how http vs ssh can make a difference, since it's happening well past when the data's transferred...02:19
wgrantWe had a similarish problem a couple of months back02:20
wgrantWhere something was corrupt and confusing the smartserver to not send enough02:21
wgrantIIRC02:21
fullermdI'd expect the updates and reverts to have trouble too if it were really short data.  Seems like just checkout that's croaking.02:26
wgrantIndeed02:26
AfCDoes the [bzr] push-and-update plugin have a proper Debian package?05:07
nigelblifeless: I got it fixed. Basically, I hadn't done bzr launchpad-login for my tarmac user :)05:37
=== lifeless_ is now known as lifeless
mgzmorning08:14
=== zyga is now known as zyga-afk
LeoNerd[offtopic]: does anyone know if there's something up with launchpad's bzr sync lately? I committed something to a personal repo on Friday, but LP still hasn't mirrored it yet.10:08
LeoNerdbzr revno lp:pangoterm => 480   vs   bzr revno http://bazaar.leonerd.org.uk/code/pangoterm => 48210:09
mgzLeoNerd: there was a window during the datacenter move where things were slightly borked10:09
LeoNerdHrm.. I knew about the move so I didn't get too upset over the weekend, but ought it to have caught up by now?10:09
mgzwhat I'm not sure is if this particular thing is still borked, or if it will get updated shortly/next time remote changes10:10
LeoNerdOK,.. well I'll keep an eye on it a few days more10:10
mgzLeoNerd: getting fixed now.10:18
=== zyga-afk is now known as zyga
jamLeoNerd: looking here: https://code.launchpad.net/~leonerd/pangoterm/trunk12:20
jamit seems to think it 'successfully' tried to copy the branch on Saturday12:20
LeoNerdYah :/12:21
jamit is already in the queue of things to be checked12:21
LeoNerdHrmm.. OK12:21
LeoNerdOh, it was 06:23 (guessing UTC?), so that might be before I committed it.. it may have been saturday morning when I actually ci'ed the code12:22
jamLeoNerd: most likely UTC, yes.12:23
jamLeoNerd: we currently have 9 jobs running branch copies, however, we can sometimes get into 3000 ish branches in the queue12:26
jamso I don't have a specific eta for your branch.12:26
LeoNerdAhh OK. I'm in no rush, was just making sure it hadn't broken12:27
mgzjam: have we got any sane way of detecting if a rev/branch has an issue with giant binary files?14:39
mgzyou did some manual discovery for the leo-editor problem14:40
mgzLelak has a problem where currently trying to use his shared repo triggers OOM on repack, but there are 100 branches and picking out the non-borked ones to a fresh repo doesn't seem easy14:41
jammgz: I think I looked at the index files using "bzr dump-btree --raw ...tix" and looking for things with large ranges14:41
mgzokay, what you did before: https://answers.launchpad.net/bzr/+question/175127#comment-414:43
mgzcurrent problem: https://answers.launchpad.net/bzr/+question/20536214:43
LelakThanks mgz!14:45
mgzthe issue is we don't have any way of fixing this apart from manual intervention by someone who understands the repo format?14:46
Lelakmgz: this was for me?14:48
mgzjam: so, do we have any practical suggestions at all?14:50
fullermdIt seems like it would be reasonably easy to bung up a plugin that does a foreach(rev in repo) { print size of change in bytes }.  Though it'd probably be awful slow...14:51
jammgz: I don't have a simple script that detects it, but iterating over branch.repository.texts.keys() (and some associated info in the index there) would certainly be possible.14:52
mgzthat sounds like a reasonable thing, what I'm not clear on is the details of a function that would do rev -> size of texts, compressed size of texts14:56
jammgz: note that the (file_id, revision) tuple for a text is the same revision_id as the actual commit revision.14:56
jamso the mapping to revision is pretty trivial, IMO14:57
jamif you are looking at "what revision introduced X" it is X's revision_id :)14:57
jamif you are looking for "what data did rev X introduce" that is a bit harder, but we already have "get_revision_delta" and friends for that14:57
mgzhm, so I guess the real desired output is "what is the last rev of this branch that doesn't have giant texts"14:58
jammgz: And I'm saying it by answering the "when were the giant texts introduced" and then just get_parent_map(introduced)14:59
mgzwon't catch OOM issues from a 1MB jpg changing every rev, but should get the common case we care about14:59
mgzokay, I'll have a stab at that.14:59
Lelakmgz: after making the new branches to the new clean shared repo now I´m getting this error: bzr: ERROR: Parent not accessible given base15:16
LelakHow is the right procedure to avoid this error when branching from the bronken repo?15:17
mgzLelak: I think you just want to reset the parent15:18
Lelaksorry I don´t know how to do this15:18
Lelak=(15:18
Lelakediting the branch info?15:18
Lelaktext file inside the .bzr folder?15:18
mgzLelak: can use `bzr config parent_location`15:19
Lelakthank you mgz!!! sorry for my ignorance15:20
mgzto get the location of in the old branch, and then use = to set it in the new branch15:20
LelakI was looking your talk with jam. Do you think you would be able to have a script that tells where the problematic revision is?15:21
mgzLelak: yup15:23
LelakGREAT!!!15:25
Lelak:DDD15:25
=== deryck is now known as deryck[lunch]
=== beuno is now known as beuno-lunch
=== beuno-lunch is now known as beuno
mgrandihow do you deal with conflicts when17:42
mgrandiall the programs im using want the left and right file, but bzr wants the changes to be in the 'this' file?17:44
mgrandiaka i have 3 files but the programs want two, and modify those files instead of the one bzr looks in17:45
mgzmgrandi: see bzrlib/mergetools.py perhaps? or ask on the mailing list.17:53
mgzthere are various different example tools that take some of this/this_temp/other/base/result as args depending on what they expect17:55
mgzjam: okay, so the core question I still don't know how to answer on the which-revs-are-bad front, but I threw together a plugin that does... something17:56
mgrandiyeah, i guess i was confused on what the 'result' file should be17:58
mgzprobably not correct for the general case, but has a go: lp:~gz/+junk/bzr-repobloat17:58
mgrandijust the file without the .base .other .this extensions?17:58
mgzmgrandi: yup.17:58
mgzthe one that actually contains the conflict markers17:58
jammgz: as a small point, most plugins put __init__.py in the top level dir, so that you can just 'bzr branch' them into your plugin dir.17:59
jammgz: and if you are going to lock the branch, you probably just want to do that at the beginning in cmd_*, unlocking and then re-locking might clear some of the caches.18:00
jamyour sorting is also a bit odd, but otherwise that seems to do what you were wanting (taking the compressed size as the key to indicate how bloated it makes things)18:01
mgzthe keys being _basis_end and _delta_end is confusing, but I'm assuming delta follows straight on?18:03
mgzI was a bit worried because one of the larger values on the testtools repo was just changing four copyright headers18:03
mgzmaking it produce useful output is just some more work to try harder to give useful info on the bad revs18:05
mgzshould bump the lower bound to 16MB and make it a param. anything else past that? there's no easy way of getting the decompressed size I take it (not unpacking all texts is a goal)18:07
mgz...and I need to leave18:07
mgzwgz is on to log though18:07
=== yofel_ is now known as yofel
danm_Do either the pipeline plugin or the loom plugin allow you to re-order your changes?19:29
danm_Along the lines of "hg qpush --move some-patch" ?19:31

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!