[00:02] I remember seeing it, but I'm not sure which version of it that was [00:02] jelmer: I'm wondering if I should depend on bzr-fastimport or not... I'm not sure if it's reliable [00:02] felipec: what else should it depend on? [00:04] jelmer: nothing... write my own [00:04] ah, sure [00:05] jelmer: that's what I did for mercurial [00:06] jelmer: the first push works fine... but not the second: http://pastie.org/5174454 [00:06] smells to me like an issue in bzr-fastimport [00:06] felipec: apart from the _find_ancestors bug (which is an issue in core bzr) bzr-fastimport's exporter works really well, and has been around for a long time [00:07] jelmer: I see... but that bug is rather important [00:12] felipec: sure, but probably easier to fix than to NIH bzr-fastimport [00:13] ... and it doesn't seem unlikely you'll hit it too if you implement your own exporter [00:15] jelmer: yeah, but how long has it been there? It seems like several years [00:15] jelmer: and yeah, maybe I'll hit it... but maybe not :) [00:16] felipec: I think it's mostly the git-bzr folks that have hit it; I certainly have never come across it [00:21] jelmer: well, I hit it [00:22] 100% reproducible [01:07] jelmer: http://pastie.org/5174655 [01:08] er, rather check the raw one: http://pastie.org/pastes/5174655/text [01:09] ./test.sh bzr-fastimport [01:09] bang! [01:13] felipec: sorry, I meant I never hit it when using bzr-fastimport myself; I did manage to reproduce it after reports from users [01:14] I've never had the time to investigate further though, and have since moved on to other things [01:14] riight [01:15] so there's no hope of somebody actually fixing this bug [01:15] also: fastimport.errors.UnknownFeature: Unknown feature 'done' - try a later importer or an earlier data format [01:16] felipec: it's a bug in bzr core, I think there were people working on that [01:17] jelmer: how do you know it's a bug there? [01:18] felipec: I debugged this stuff earlier; bzr-fastimport is using the appropriate APIs, it's breaking deep in the bzr index handling code. [01:21] jelmer: can you point me the the point where bzr-fastimport is using those APIs? [01:21] felipec: it should be in the backtrace [01:24] jelmer: the backtrace only shows trying to access something on the index [01:24] not what puts things there [01:35] jelmer: also, if this is not related to bzr-fastimport, there should be a standalone test that reproduces this... and where is the bug report? [01:36] felipec: https://bugs.launchpad.net/bzr/+bug/541626 [01:36] Ubuntu bug 541626 in git-bzr-ng "'BTreeBuilder' object has no attribute '_find_ancestors'" [Undecided,New] [01:40] jelmer: that says the fix is released [01:41] felipec: there is some talk at the bottom of that bug report refuting that [01:41] felipec: also, this was fixed pretty recently - are you running bzr from trunk? [01:41] jelmer: and all the comments after that saying that the bug is still there were ignored [01:41] jelmer: 2..5.1 [01:41] felipec: that's definitely from before the change that claimed to fix it (which was 3 months ago) [01:42] jelmer: so you want me to download the lastest when in fact the people in there say the problem is still there? [01:43] felipec: It's worth a shot - I don't know if the people who are saying that are running the latest version. [01:43] lets see [01:48] jelmer: do you have any comments in how the bzr-fastimporter API is used? http://pastie.org/5174765 [01:48] export_branch() and do_export() [01:51] also, you shouldn't assume the prefix is 'refs/heads', I see some temporary branches are created where they shouldn't [01:52] felipec: that's not my code :-) [01:57] jelmer: 'you' as 'you guys' [02:00] felipec: I'm no longer really involved. [02:01] felipec: anyway, what would you suggest as alternative place for termporary branches? [02:03] jelmer: well, I don't know what are temporary branches, but they should use the same namespace [02:04] jelmer: for example, I pass ref='refs/bzr/origin/master', and I would expect 'refs/bzr/origin/tmp' [02:06] hmm, bzrlib/_static_tuple_c.c:35:33: fatal error: _simple_set_pyx_api.h: No such file or directory [02:13] all right, hacked setup.py to disable that warning [02:15] jelmer: still fails [02:29] a shorter version of this? bzr log -r X --show-ids | grep 'revision-id:' | sed -e 's/revision-id: //' [02:32] bzr version-info --custom --template '{revision_id}\n' -rX [02:33] fullermd: thanks [02:38] jelmer: hmm, fatal: Missing > in ident string: > 1172879596 +0200 [02:46] jelmer: fatal: Path bzrlib/tests/per_repository/test_merge_directive.py not in branch [03:26] how can I go back to a previous version? [03:26] bzr update -r bzr-2.4.0 leaves the whole working directory in a bad state [03:46] is there shallow clone support? [03:53] To the former, update pull or revert, depending on just what you want in "go back". If the changes end up running across unclean bits of the tree, "bad state" is not unexpected. [03:53] For the latter, that would be stacking. But I'm not sure you want to mess with that. [04:13] jelmer: how am I supposed to export only a subset of revisions? bzr fast-export --baseline bzr-2.3.4 -r "bzr-2.3.4..bzr-2.4.2" <- this is definitely not working worrectly [04:15] fullermd: bzr revert -r bzr-2.3.4; bzr pull -r bzr-2.3.4; bzr status <- I still see a lot of stuff there [04:18] I said 'or', not 'and' ;p [04:19] And yes, doing backwalks from a non-pristine tree is likely to lead to fewmets lying around. [04:22] fullermd: I know, but I tried both to make sure :) [04:25] bzr update -r X && bzr revert [04:43] damn it, I don't inderstand why bzr log -r bzr-2.3.4..bzr-2.4.0 wouldn't show bzr-2.3.4 [04:47] You need -n0 since the 2.3.4 tag doesn't wind up on the mainline. [04:54] fullermd: thx [05:01] fullermd: the first revision I see is 5609, the second is 5609.48.4 [05:01] but there's tons of changes in between [05:09] I don't. Bottom of the list is 5609.51.2, which is the one with the bzr-2.3.4 tag on it. [05:38] fullermd: do a diff [05:40] Of the tags? That's not gonna tell me much about any revs... [05:41] fullermd: bzr diff -r 5609..5609.48.4 [05:41] but I guess this is what I want: bzr log --exclude-common-ancestry -n0 -r bzr-2.3.4..bzr-2.4.0 [05:43] Well, that tells me "here's a big diff", but I'm not sure what else to take from it :p [05:51] found the bug [05:51] http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/revision/5757.2.1 [05:51] jelmer: it was you [07:19] jelmer: the bug was in bzr-fastimport: https://launchpadlibrarian.net/121914657/bzr-fastimport.patch [07:25] it has to repack on every run? that seems like overkill === yofel_ is now known as yofel [12:23] hi there [12:24] I have a big issue with yum. basically I need bazaar>=2.4.1 to use the -d option, and the best version I find through all my repositories is 2.1.2 : http://sprunge.us/KHcg [12:25] Any yum/rpm user here who knows what's going on ? [12:47] not a yum or rpm issue [12:47] you can just install it from source if you like [22:23] jelmer: found the bug [22:24] this time for real :)