[00:13] hi spiv, how are you? and what fabulous adventures will you have today? [00:16] poolie: working towards bug 309682; I have a patch that works, but polishing all the little issues the patch glosses over is surprisingly involved. [00:16] Launchpad bug 309682 in Bazaar "tags are copied but their revisions may not be (affected: 0, heat: 10)" [Low,In progress] https://launchpad.net/bugs/309682 [00:16] how about a catch up call in a few minutes? [00:16] Sure [07:26] hi all ! [07:43] Hi vila, Hi all [07:43] GaryvdM: hey ! [07:50] vila: I hope you don't mind me asking about test writing a test. For bug 588698. The current tests that deal with merging merging new roots, crisscross merges, etc only check the shape of the graph after the merge. There are no asserts on the state of the files in the wt. This is done in other test that don't look at the shape of the graph. Would it be ok if my test for this bug did both? [07:50] Launchpad bug 588698 in Bazaar ""bzr merge" fails "Branches have no common ancestor" (affected: 1, heat: 8)" [Undecided,Confirmed] https://launchpad.net/bugs/588698 [07:51] GaryvdM: if you feel the need then go for it [07:51] there is no absolute rules about what a test *must* check [07:52] Ok [07:52] too little is as bad as too much but this can be rather subjective at times [07:53] I would like to do both, because I'm not sure exactly it should work, and I would like to define it in a test. [07:57] GaryvdM: may be two tests then ? [07:58] GaryvdM: or more :) [07:59] GaryvdM: ideally a test should check one thing to enhance the overall defect localization [07:59] vila: But the actions that the 2 test would perform would overlap 95% [08:00] GaryvdM: that is, a single defect is caught by at least one test which makes it obvious what the defect is or at least narrow down the code that needs to be investigated [08:01] GaryvdM: it's hard for me to judge without concrete examples, but sometimes this indicates tests that are too high-level [08:01] GaryvdM: in this case drilling down to get closer to the code you want to test avoid the duplication [08:03] GaryvdM: in some cases though, due to some bad layering, you just can't avoid it so just go for the duplication but add comments or FIXME explaining the issue [08:03] Ok [08:04] GaryvdM: feel free to submit early versions for feedback, MPs can be used for that too (if properly explained) [08:04] GaryvdM: the first thing to optimise for in a test is clarity [08:05] GaryvdM: refactoring to reduce duplication is often helpful for that goal of course :) [08:05] hello vila [08:05] poolie: hey ! [08:05] GaryvdM: but it's important that the *intent* of a test is clear: if it's not, then when it fails, or when it needs to be updated for API or behaviour changes, then it's unclear what should be done. [08:05] poolie: dear PP, I havean MP approved but its pre-requisite, could you help me ? https://code.edge.launchpad.net/~vila/bzr/671050-config-policy/+merge/40343 [08:06] s/but its/but not its/ [08:06] GaryvdM: so if there are multiple aspects you want to verify it can be clearest to make multiple tests, so that each can have one explicit purpose. [08:07] ok [08:12] GaryvdM: where I find it gets tricky is when I'm not sure yet what the behaviour should be, and I'm writing the test to help me discover that... :) [08:12] spiv: And that is the case here... [08:12] But I guess it's like any other sort of authoring: you just keep revising till it makes good sense. [08:12] vila, done, thanks for asking [08:14] GaryvdM: so it's fine to start with an exploratory test (or tests) that probably do too much, so long as you are aware that once you've explored and hopefully understood the new territory it's probably worth reviewing the tests. [08:14] GaryvdM: (yes that sentence has lots of qualifiers, I'm not sure these are hard-and-fast rules...) [08:15] poolie: great ! I'll tweak the comment, that's a point with quite deep implications that should be better addressed with the new config scheme but some parts are still unclear in my mind, so yes, a FIXME is appropriate [08:16] spiv: should we talk about https://code.edge.launchpad.net/~spiv/bzr/checkout-tags-propagation-603395-2.2/+merge/40406 ? [08:17] vila: I chatted with poolie about it a bit [08:18] vila: on one hand, I'm pretty confident about the backwards compat stuff... but on the other the bug report has been pretty quiet, so the urgency for getting it in 2.2 is low. So I'll just land it in 2.3 for now. [08:18] vila: (if later we decide it might be good to have in 2.2 after all... well, we know where to find the patch!) [08:18] vila: thanks for the review [08:20] spiv: ha great, I feel relieved :) [08:32] yay :) [08:33] i had such a good day of mgmt today [08:33] (imho :-) [08:44] poolie: way to go :) [08:46] poolie: mgmt taks are the hardest to quantify which is a source of frustration when you try to summarize: "what the hell did I do today/this week/this month" :D [08:47] yep [08:48] AAAARGH, I hate vbox when is starts to randomly generates mouse clicks all over the place ! [09:07] ! [09:07] that's what cats are for :) [09:08] ok i think that's enough fun for today [09:09] hehe === Guest8056 is now known as jelmer [10:55] Hi, I'm running bzr 2.3b3 on CentOS 5 (python2.4), bzr-svn 0.7.5, subvertpy 1.0.4 and getting 'function' object has no attribute 'decode' when trying to pull svn branches ; stack trace http://pastebin.ubuntu.com/533419/ [11:06] awilkins: bzr-svn bug, try trunk ? [11:06] awilkins: file a bug otherwise [11:07] awilkins: I agree with vila [11:08] Looks like it's passing a generator to a function that expects a string [11:09] Going to try it with 2.2.1 [11:12] Ah, well that produces a different error, so that's progress. I think the previous thing is a change to the API in 2.3 vs 2.2 ; the contructor in 2.2 expects a generator function, in 2.3 it expects a string [11:14] Now it's a 2.5-ism I think ; 2.4 has no "any() " function, right? [11:23] hmm, 2.2 was expecting a callable not a generator but yes, that's the offending change [11:23] but where is any() involved ? [11:23] vila, The calling code calls it a generator ... I'm not very pythonic I'm afraid [11:23] any() is in bzr-svn [11:23] logwalker.py [11:23] Just patching it [11:24] Grr. qbzr needs more context menus. Just want to be able to blame something and do a switch -b from the log menu [12:00] jelmer, Looks like you already noticed that logwalker.py python2.4 bug :-) [12:06] awilkins: Noted === oubiwann is now known as oubiwann-away === oubiwann-away is now known as oubiwann === Ursinha-dinner is now known as Ursinha === zyga is now known as zyga-food [14:28] mgz: testtools-0.9.6 has been installed on pqm [14:28] mgz: don't rejoice too fast though, we lost subunit in the process :-} [14:29] mgz: this was an announce from the be-ready-but-not-too-fast dept === zyga-food is now known as zyga [15:02] I'm mainly an svn user, and I want to get a checkout from bzr://dxx-rebirth.bzr.sourceforge.net/bzrroot/dxx-rebirth . I've tried bzr co, bzr pull, bzr branch, and I get errors saying "not a branch". bzr init says that it's a "Shared repository". How can I get a copy? [15:03] hey hangfire [15:04] jelmer: hey [15:04] hangfire: you'd want bzr branch or bzr co, but to check out an individual branch rather than the full repository [15:04] jelmer: How can I get a list of branch nameS? [15:04] hangfire: There should branches underneath that repository, and those are what you deal with/check out in bzr. [15:04] jelmer's clearly on it. :) [15:05] hangfire: Actually, looking at this again, is there any reason you're using bzr:// rather than http:// ? [15:05] Odd_Bloke: hey! long time no see :-) [15:05] jelmer: That's what's listed on sf.net :P [15:05] jelmer: Indeed. [15:05] jelmer: I've been hanging around a bit more because I heard there was a job going. ;) [15:06] jelmer: ah! got it. Thanks [15:06] Odd_Bloke: thanks too! [15:07] Odd_Bloke: Ah, right, that one :-) [15:07] jelmer: Congratulations on that, by the way. :) [15:07] Since I was really spending time contributing to bzr (and other FS projects) I've gained both a job and a girlfriend, so my time is considerably more scarce than it was. [15:08] Odd_Bloke: Thanks! [15:08] Odd_Bloke: Ahh! I wondered what had happened to you. [15:09] The job is with credativ, who work with free software, so it's not all bad. [15:09] I'm just spending my time working on business logic stuff like OpenERP. [15:09] And sysadmin stuff, and some website work in Django. [15:09] Odd_Bloke: Ah, cool. Wasn't Chris or Johnny working there as well? [15:10] jelmer: jonnylamb works as Collabora. [15:10] Or at least did. [15:10] Which may be where you're thinking of. [15:10] I'm pretty sure I met another friend of yours who worked there, perhaps somebody other than Johnny or Chris. [15:10] Well, that's hardly fair. Messing with bzr hasn't gotten me a job or a girlfriend :( [15:11] jelmer: Tim Retout? [15:11] Brad Smith, and Chris Halls are the other DDs who do/have worked here. [15:11] And I assume you only know DDs. :p [15:11] Odd_Bloke: I think so. [15:12] fullermd: Waaah. :p [15:13] Odd_Bloke: (-: [15:14] OpenERP, which I spend most of my time working on, has a pretty lame upstream, I should probably get back into spending some spare time doing FS stuff. [15:15] I vaguely recall seeing something about openerp and bzr recently [15:15] somebody wanting to extend bzr-stats [15:16] They do use Launchpad. [15:16] At least for interfacing with contributors/users who are external to their partner programme. [15:17] ah, cool [16:29] wonder if anyone can help. i think i'm not sure if i'm using import-upstream correctly or not. [16:29] $ bzr branch lp:ubuntu/natty/euca2ools natty.dist [16:29] $ cd natty.dist [16:29] $ bzr import-upstream 1.3.1 ../dl/euca2ools-1.3.1.tar.gz [16:30] results in http://paste.ubuntu.com/533507/ [16:30] i'm on natty, but i think i'd seen this before [16:46] smoser: I believe you need to add --version before the 1.3.1 [16:46] no. you do for merge-upstream, import-upstream wants it that way [16:46] Also, isn't it merge-upstream [16:46] (at least per its usage) [16:46] oh. ETOOMANYCOMMANDS [16:47] i actually want the import-upstream rather than merge-upstream. i just want the upstream pulled in, and then will merge it manually (basically dropping all ubuntu changes and patching in) [16:47] merge-upstream just leaves me with dozens of conflicts [16:47] james_w, ^ you have thoughts on above ? [16:48] smoser: is the debian/watch screwed up or is euca2ools-1.3.1-src-deps.tar.gz the right thing? [16:48] maxb, i'm not sure. i didnt' even look at the watch. silly me. probably should have looked there first. [16:48] smoser, please file a bug [16:48] I think the watchfile is erroneously too permissive [16:49] james_w, ok [16:53] smoser: fwiw, commenting out the line it breaks on appears to allow it to function correctly [16:53] it would appear to simply be a missing "if upstream is not None:" [16:54] smoser, lp:bzr-builddeb should have a quick fix for that problem [16:54] maxb, indeed [16:54] does anybody know why lazr.uri is not included in the OSX bundle (http://wiki.bazaar.canonical.com/MacOSXBundle/SnowLeopard)? it's needed by lp-propose [16:55] salgado, does lp-propose depend on launchpadlib, or just lazr.uri? [16:55] james_w, probably launchpadlib [16:56] haven't checked, but it didn't work for martohls because lazr.uri was missing [16:57] salgado, right, I'm wondering if launchpadlib is bundled, or it's just reporting the first of a few missing dependencies [16:57] I don't know who builds the bundle though [16:58] launchpadlib is not included in the bundle listing on the wiki [17:02] james_w: Oh, btw, remember I said I was going to fix the missing tags issues blocking UDD imports? Well, just so you know, I fixed one locally and then found the importer did all kinds of bizarre stuff with parallel importing into squeeze and sid, so I got blocked on having time to dig into that weirdness. [17:02] maxb, bizarre how? [17:03] Importing the same upstream version multiple times was the most obviously wrong thing that I recall [17:04] bugger. i had opened a bug. but it appears launchpad isn't wanting me to do that now [17:04] Also doing history-diverged distinct imports of the same debian version number on the squeeze and sid branches [17:05] jam1: ping === jam1 is now known as jam [17:05] maxb, the latter is intentional if the branches have previously diverged [17:05] hi vila [17:05] jam: how are things going ? [17:08] pretty good today. how about you? [17:08] jam: testtools-0.9.6 has been installed on pqm BUT subunit has been removed [17:09] jam: mthaddon is adding subunit-0.0.6 from our stable ppa again, but the build is still ongoing [17:09] sigh [17:09] jam: since I will EOD soon, it would be nice if you could check how it goes [17:10] jam: I'm not asking for landing my stuff, just make sure we *can* land something :-/ [17:11] sure [17:11] ha, upgrading testtools broke landing? [17:11] jam: what are you working on these days ? hpss on lp ? [17:12] mgz: AIUI testtools requires some version of subunit which wasn't the one installed [17:12] mgz: my previous ping was to warn you that we *should* be able to finally land your branches so you may want to refresh them [17:12] ah. it... shouldn't work like that, subunit depends on testtools not visa versa, but I can imagine something broke. [17:13] vila: well, they'll need to head merged, they predate the NEWS split. [17:13] mgz: yeah, so that may means shuffling the news entries anyway [17:17] vila: so what's up with the 'temp-commit-file' being sent every hour or so? Is this just PQM fallout? [17:17] and is there an RT for the breakage that I should be following? [17:21] vila: I'm planning on sending a mail to the list about some possible "next things" for me. Commit to stacked branch, Branch.open() round trips over hpss, etc. [17:21] jam: yup, pqm fallout [17:22] jam: yes, 41340, it has been closed while testtools was installed but I think it's the one to re-open [17:23] jam: commit to stacked branches would be nice, AIUI, some udd devs prefer checkouts [17:23] jam: and on lp that means stacked right ? [17:24] vila: well, it can mean stacked, yes [17:24] I think really what they want is shallow [17:24] which is something I poked at a while ago, which could really use a good hpss verb for it [17:25] I'm now getting "Connection closed: Unexpected end of message" when trying to use bzr+ssh ... sftp works for the same branch [17:26] The server logs the startup of the remote bzr instance... [17:27] awilkins: can you try running with -Dhpss ? [17:27] HPSS calls: 2 (1 vfs) SmartSSHClientMedium(bzr+ssh://None@cu013/) [17:29] james_w, bug 676606 [17:29] Launchpad bug 676606 in bzr-builddeb (Ubuntu) "import-upstream stack traces without upstream repository (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/676606 [17:29] Why did this start happening? http://buildbot.twistedmatrix.com/builders/hardy64-py2.5-select/builds/448/steps/bzr/logs/stdio [17:29] awilkins: there will be some information in ~/.bzr.log indicating what requests were done, etc. [17:30] And the full log : http://pastebin.ubuntu.com/533527/ ; nothing unordinary on the server I can see [17:30] smoser, thanks [17:30] smoser, did you try the fix? [17:30] just getting there. [17:31] awilkins: so on the client side, it looks like we sent a request and got back no content in return [17:31] "buf[:10]=''" [17:31] means that there was no content in the reply [17:31] jam, this is through an ssh tunnel ; I have a shell open on the same connection which works fine, as does SFTP. [17:32] So there is a server though which tunnels are established to get access to the servers inside [17:32] awilkins: sure, is it ssh inside the tunnel as well? [17:32] or is it raw bzr:// ? [17:32] etc [17:32] jam, It's bzr+ssh:// through the same tunnel that the ssh shell connection is working through. [17:32] These lines are a bit surprising, too: [17:32] 0.152 ssh implementation is OpenSSH 0.974 result: ('ReadError', 'home/awilkins/ace/.repo/workbench/trunk') [17:33] james_w, fix seems to work. [17:33] jam, The version, or the lack of / on the front of the path? [17:33] (it actually looks like we got an earlier failure, and are trying to continue working, when we shouldn't) [17:33] awilkins: try this: "echo hello | ssh bzr serve --inet" [17:33] the full string we are sending is "bzr serve --inet --directory=/ --allow-writes" in case that matters (it shouldn't) [17:34] looks like "cu013" is [17:34] jam, this is an instance of bzr in my home folder on the server and is being accessed via setting BZR_REMOTE_PATH, not via the normal PATH [17:34] That *should" return "ok\x012\n" [17:34] awilkins: well, then try that first [17:34] jam, returns ok [17:35] awilkins: you are setting BZR_REMOTE_PATH and not via config, right? [17:36] another thing to check is that the remote bzr is executable, but you seem to have validated that with the "echo hello" check [17:36] you could try: [17:36] jam, setting it on the same command line - without, you get a command not found form the server [17:36] echo hello | ssh cu013 $BZR_REMOTE_PATH serve --inet [17:36] to make sure you have the remote path set correctly [17:37] awilkins: I think you might have a username set wrong: [17:37] [ 9024] 2010-11-17 17:27:21.522 INFO: HPSS calls: 2 (1 vfs) SmartSSHClientMedium(bzr+ssh://None@cu013/) [17:37] None@ ? [17:38] (we may just be displaying it when we shouldn't, because it is using the default) [17:38] jam: I see that almost everytime [17:38] jam: exactly [17:38] jam, That's just the parameter in the stack trace ; I've been using this config for ages though [17:38] jam, It works fine [17:38] (for ssh) [17:38] It previously worked fine for a similar server [17:38] smoser, excellent, thanks for testing [17:39] so, now for the general bzr education [17:39] But had to start using a different one in the same cluster (it's CentOS 5 in a collabnet cluster) [17:39] i did the above, and imported upstream tarball [17:39] and i can bzr diff -r tag:upstream-1.3.1 [17:39] but in bzr tags output i see: [17:39] upstream-1.3.1 ? [17:40] I believe that is expected, because whilst you have imported the revision, it is not (yet) in the ancestry of your current branch, so cannot be given a revno [17:40] why is that? and what is the repercussion of it. [17:41] hm.. so maybe import-upstream isnt what i want then? [17:42] Well, at this point you are free to 'bzr merge -r upstream-1.3.1 .' [17:42] jam, I think I might just be being an idiot about how to set an env variable [17:42] smoser, import-upstream is only a building block for whatever you want to do [17:42] smoser, so maxb is right that a merge is one of the possible next steps [17:43] yeah. ok. i think i'm set now. [17:43] awilkins: what shell are you using? [17:43] maxb, regarding the watch file, it does seem its incorrect. it gets a -src-deps download. i'll fix that. [17:43] though if it is changing from "not found" to actually reporting something, that seems like progress [17:44] (export BZR_REMOTE_PATH=...) seems like it should work for "bash"s, "set BZR_REMOTE_PATH=..." I think is tcsh. [17:44] jam, I'm using bash locally and on the sever [17:45] awilkins: fwiw it seems to be failing at the first RPC, so I'm not sure yet that bzr is able to start the remote bzr correctly. [17:45] was using # BZR_REMOTE_PATH="/home/awilkins/bin/bzr" bzr pull bzr+ssh:// [17:45] Without the first part it complains about not finding bzr, but produces the same error [17:45] With it, it doesn't [17:45] (complain about not finding the command) [17:46] I know it's running on the server because the logs are showing up the serve --inet --directory=/ commands [17:49] jam, Hmm, the serve attempts that respond to the "hello" command have a return code 0, the others have no return code. [17:49] awilkins: you pretty much have to have a return code... [17:50] ah, you mean on the server it doesn't show as returning? [17:50] that sounds like it might be segfaulting [17:50] how did you install the code there? [17:50] (did you compile extensions on a different platform, and then copy it?) [17:50] jam, Yes, but they are not logging it - gets as far as "bzr-svn: using Subversion 1.4.2 ()" then stops [17:50] jam, compiled in the same folder it's running in [17:51] awilkins: using "make" ? [17:51] jam, yes [17:51] jam, bzr 2.2.1 using the tarball and building from the included c files [17:53] awilkins: so one quick check, try going to the server, and using ~/bin/bzr log /home/awilkins/ace/.repo/workbench/trunk [17:53] in case that segfaults for some unknown reason [17:53] and how is ~/bin/bzr running in the same dir that it was compiled? (just a symlink?) [17:53] jam, that runs just fine ; ~bin/bzr is a symlink, but I've tried the direct path as well with the same results [17:55] jam, I'll get the server to run the selftests [17:55] and just to be sure "ssh cu013 bzr log /home/awilkins/ace/.repo" also works, right? [17:56] (well, add 'trunk' there) [17:56] jam, .repo is actually a standard folder, the subfolders of it are repos [17:57] jam, that works... it also works on the server (accidentally put the command there) [17:58] awilkins: I would try 'bzr selftest -s bp.svn' first since you mentioned it [17:59] vila, Gah, no testtools [17:59] As an aside, I hate CentOS [17:59] * vila suggests >=0.9.6 :) [18:00] yum is especially pants [18:00] awilkins: no bzr packaged there ? [18:00] vila, Nope [18:01] vila, I dare not add too many repositories, because the last time I did it upgraded some component to be inbcompatible with the setup these servers have where they mount your home folder from a SAN somewhere [18:01] weird... I was sure I saw someone mentioning updating bzr for Red Hat with a simple command... where... where did I read that (a bug report ?) [18:01] Broken LDAP library or something [18:01] oh [18:01] * awilkins tries yum install bzr [18:02] I broke it once like that and they rewarded me by taking away my ability to trash the server image... which seemed odd, because I was going to fix it by trashing the server image... [18:03] This is a CollabNet build farm, what do you expect, they are still in love with svn. [18:04] I hope it really annoys them that I use my home folder to mirror all the SVN repos in the project as Bazaar branches, but frankly they probably haven;t noticed. [18:04] Maybe if you checked that homedir into svn... [18:05] svn is the best subversioning system, all more advancved once support it, so you can easily use git/bzr/hg insteand of svn [18:05] That's ironically "meta". Even more ironic given that the lead "programmer" on this project has actually written a versioned object database that actually stored it's repository (note- repository, not working copy) in an SVN working copy >-o-< [18:06] That's a pinched agony face, by the way, not a goatse-ascii (accidental) [18:06] You get extra points if your svn->bzr conversion scripts automatically notice the new stuff in svn, and check out a bzr conversion of your homedir checkin in your homedir... [18:18] jam, It is a segfault [18:18] awilkins: well, at least I was right... now to figure out why [18:18] jam, Started another port tunnel for plain bzr:// and ran a server on the remote shell [18:19] jam, It's something in bzr-svn [18:19] awilkins: do you need to have bzr-svn available? [18:19] jam, start it with --no-plugins and it works just fine [18:19] I guess you were saying everything is running in svn upstream [18:20] jam, I need it on the server shell but not when I'm pulling remotely [18:20] It's just a staging area to reduce my download bandwidth really - some of these branches are fricking huge [18:21] hey guys... i did an apt-get update with an apt-get upgrade on hardy and now I get "bzr: ERROR: exceptions.ImportError: ('Unable to load subvertpy extensions: %s', 'No module named client')" [18:21] So I can work around it by moving the plugin and putting a BZR_PLUGIN_PATH in the remote script for bzr [18:21] it was fine before I did the update ... I"m running ubuntu 8.04 server [18:23] any ideas on how to fix that? [18:24] brianjarita, were any of the components installed manually rather than via apt? [18:24] nope [18:25] i have bzr 2.1.1-1, bzr-svn 1.0.2-2 and bzrtools 2.1.0-1 installed [18:27] awilkins: or use BZR_DISABLE_PLUGINS, bzr help env-variables will tell you if it's available [18:28] vila, would that work for the remote server? Does SSH pass those env variables (or just a limited subset like LC) [18:30] brianjarita, (I keep wanting to type "brainjar"), those are not the most recent versions of those packages for Hardy in the bzr PPA (I know they're not from the default Hardy repo, because that's still at 1.13) [18:31] i see 2.2.1-0~bazaar1~hardy1 [18:31] brianjarita, Could you upgrade them to the newest versions in the PPA? (bzr-2.2.1-0~bazaar1~hardy1, bzr-svn-1.0.4-1~bazaar1~hardy1, bzrtools-2.2.0-2~bazaar1~hard1) [18:32] root@dev:~/Source# dpkg --list|grep bzr [18:32] ii bzr 2.2.1-0~bazaar1~hardy1 easy to use distributed version control syst [18:32] ii bzr-svn 1.0.4-1~bazaar1~hardy1 Bazaar plugin providing Subversion integrati [18:32] ii bzrtools 2.2.0-2~bazaar1~hardy1 Collection of tools for bzr [18:33] brianjarita, So why do you have 2.1.1-1 above? [18:33] sorry i was on the wrong terminal [18:33] i was on lucid at 10:24AM [18:33] that last post is hardy [18:33] Linux dev 2.6.24-26-server #1 SMP Tue Dec 1 18:26:43 UTC 2009 x86_64 GNU/Linux [18:34] I presume you need bzr-svn :-) [18:35] bzr 2.2.1-0~bazaar1~hardy1, bzr-svn 1.0.4-1~bazaar1~hardy1 and bzrtools 2.2.0-2~bazaar1~hardy1 are all installed [18:35] 2a format has O(1) access time for text objects? [18:36] brianjarita: it looks like you have a broken python-subvertpy [18:36] awilkins: I imagine we only pass a limited subset of env vars, probably just the ones that ssh itself defaults to passing [18:37] awilkins: Did you figure out why bzr-svn was breaking your setup? [18:37] hey jam! [18:37] knittl: they are stored delta compressed, so not exactly O(1), and the index files are btrees, so looking up the location of the text is more O(log(n))... [18:37] hi jelmer [18:37] python-subvertpy is 0.7.5-1~bazaar1~hardy1 [18:37] jam: is there a reference somewhere? [18:38] knittl: is there a specific question I can help answer? [18:38] jelmer, Alas, no, it's segfaulting with no stack trace, I've not got testtools installed yet 'coz I can't find a CentOS package name for it (grr) [18:38] jam: still writing on my thesis :P [18:38] and i have a line in it, that says »O(1) lookup time for any version of a file \todo{cite,verify}« [18:39] so i came to verify [18:39] awilkins: what version of subvertpy? [18:39] IMO O(1) is pretty poorly defined. And usually means you have to actually find the terms and determine that this part is a minimal part of the overall time, etc. [18:39] jelmer, 0.7.5, compiled from tarball. It pulls SVN branches just fine [18:39] O(1) is generally constant and not depending on number of commits, number of branches, number of files, etc. [18:40] jelmer, I may have patched it slightly for that not-importing-pycompat thing [18:40] knittl: I would guess that we aren't strictly O(1). If I would guess, I would at least give it O(log(N)) of "stuff" [18:40] awilkins: what are you trying to do ? [18:40] i need evidence to back that up [18:41] there are no books on bzr, so bazaar internal documentation/format documentation is best i can get [18:41] knittl: inventories (mapping Revision id => tree => actual file content) is stored as a tree structure, so that is generally a log(N) lookup. [18:41] what is N in O(log(N))? [18:41] jelmer, I'm pulling SVN branches to my home folder on this server (because the SVN repo is in the same server rack and thus it's fast there), then pulling those bzr branches via bzr+ssh:// to my local machine [18:41] knittl: Indices that map from a given text key (file_id, revision_id) to actual file content are btrees, which tends to be log100(N) lookup [18:42] awilkins: and pulling the bzr branches over bzr+ssh:// fails? [18:42] what is N? [18:42] knittl: the raw text content is stored in a group of zlib.compress(lots_of_delta_content) [18:42] which is O(N_in_the_group) which is not strictly bounded, but significatly smaller than the N of all text content [18:43] jelmer, Or if you manually configure another tunnel and use plain bzr:// from a server started on the shell ; it segfaults, but not if you use --no-plugins. The only plugin outside the default is bzr-svn [18:43] inventory would be O(log(Num_files_in_the_tree)) [18:43] jelmer, Ill just be extra thorough and try just disabling bzr-svn [18:43] i'm still very disappointed by bzr's technical documentation :( [18:43] file_key => pack file is O(log100(Num_all_texts_stored_in_the_repository)) [18:43] awilkins: I wonder why bzr-svn kicks in at all though [18:44] knittl: it isn't a VCS for Comp Sci majors ... [18:44] awilkins: the remote directory doesn't have .svn directories or anything like that? [18:44] let's say i can ignore compression [18:44] jelmer: we're looking up a branch, that generally involves bzr-svn [18:44] knittl: zlib.decompress is going to be O(size_of_file_content) [18:44] i said i _can_ ignore it ^^ [18:44] and given everything I've stated, is likely to be the dominating factor [18:44] jam: but we check for .bzr before checking for .svn, and the .svn check happens using os.path.isdir(). [18:44] why btree and not a hashmap? [18:45] jelmer, The remote folder is a bare branch in a bare repository [18:45] Sorry, slipping into git-ism - --no-trees [18:45] awilkins: is it a shared repo? [18:45] jam, It is [18:45] jam, I will try one of the other repos [18:45] I have many here [18:45] awilkins: then is is "repo/.bzr repo/branch/.bzr/" which would mean we have to 'search" === oubiwann is now known as oubiwann-away [18:46] knittl: our keys aren't hashes to start with (vs git) [18:46] and many operations look for "similar" data === oubiwann-away is now known as oubiwann [18:46] like log going over revisions tends to look at user-2001a, user-2001b, etc [18:47] so you get locality by using a btree vs a hashmap [18:47] same for text content [18:47] ok [18:47] diff looks for 2 texts of file-id1, rev1, rev2 [18:47] repo layout is as at http://pastebin.ubuntu.com/533547/ [18:47] jam: so where is documentation that can back up everything you said? [18:47] I like this layout because you can do switch -b with ease [18:48] knittl: ultimate documentation is in the code :) [18:48] i'm afraid IRC will not be allowed as citing source [18:48] look in doc/developers/* [18:48] and bzrlib/btree_index.py and bzrlib/groupcompress.py bzrlib/repofmt/groupcompress_repo.py [18:48] there should be some slightly technical docstrings [18:49] jam: but in awilkins situation we'd still not have to check for .svn as we'd find a .bzr controldir in every directory we browse, right? [18:49] awilkins: Can you perhaps run your bzr serve process in gdb ? [18:49] jam: hm. ok [18:49]