[12:03] btw there's some docstring corrections in my pack-repo branch [12:04] I'm thinking about this knit change [12:04] heres what I plan: [12:04] - add a new subclass of knit that writes a different knit record but can read either [12:04] - add a new interknit to convert data from regular knits to this [12:05] change packs to use the new knit [12:05] abadger1999: Thanks. I've emailed the other contributors, to confirm it's okay with them (though I understand I'm not required to by law). [12:05] That's excellent. Thanks for helping me clear that up. === kiko [n=kiko@canonical/launchpad/pdpc.supporter.active.kiko] has joined #bzr === kiko is now known as kiko-afk [12:11] I am still getting the same error on windows : bzr: ERROR : ERROR 2 The system cannot find the file specified [12:11] has anyone seen this error? [12:11] no [12:11] if you run with BZR_PDB=1 you can drop into pdb and poke around [12:11] or check .bzr.log for a backtrace [12:11] it's windows though [12:12] ye [12:12] s [12:12] bzr version will show where the log file is [12:12] (bzr --version) [12:13] abentley: BTW, I have a little patch that makes python setup.py sdist include the COPYING file [12:13] http://toshio.fedorapeople.org/packages/trac+bzr-install.patch [12:13] intriguing! thanks. [12:15] I don't understand your setup.py change. [12:16] I'm not sure why, but setuptools is deciding not to include COPYING in the tarball even though it is listed in data_files [12:16] moving it from data_files to MANIFEST.in makes setuptools more cooperative. [12:17] weird. [12:17] There's also some setuptools documentation that makes me think that data_files is for real data_files that the python module depends on at runtime [12:18] While MANIFEST.in can feed files into the tarball that aren't put into the installed module tree. [12:18] Okay, I'll take it on trust. [12:19] heh. Thanks :-) [12:30] lifeless: I don't know if the bzr.dev deb Recommends xdg-utils, but it should. (The recent bzr send updates use xdg-email if possible) [12:30] probably doesn't. [12:30] I haven't started building dailies yet though [12:30] Okay. [12:31] Just thought of that, reading today's IRC log. [12:31] thanks [12:31] uhm, where to record this :) === cprov is now known as cprov-out === Janzert [n=Brian@75-134-223-54.dhcp.trcy.mi.charter.com] has joined #bzr === jelmer [n=jelmer@a62-251-123-16.adsl.xs4all.nl] has joined #bzr [12:42] does anyone know why someone would be getting these errors: http://paste.ubuntu-nl.org/35614/ [12:43] it looks like it's trying to run putty and failing === igc [n=igc@ppp121-45-197-71.lns1.bne1.internode.on.net] has joined #bzr [12:43] morning [12:44] poolie: I believe it's related to: https://bugs.launchpad.net/bzr/+bug/107155 [12:44] Launchpad bug 107155 in bzr "_get_vendor_by_inspection incorrectly determines "plink" to be the executable" [Medium,Confirmed] === bac [n=bac@canonical/launchpad/bac] has joined #bzr === sabdfl [n=sabdfl@ubuntu/member/pdpc.silver.sabdfl] has left #bzr [] [12:48] hi igc [12:49] it is :D [12:49] beuno, yes, that looks like it [12:49] morning poolie. Feeling better today? [12:49] suggest you try the workoround [12:49] it fixed it for him, thanks poolie [12:49] igc: no :) [12:49] beuno, could you try to write a patch for it that changes the code that determines the ssh version ? [12:51] poolie: I can give it a try, yes :D [12:51] I'll have to find a pc with windows around the office to test it, but I guess it shouldn't be too hard === jml [n=jml@ppp108-61.static.internode.on.net] has joined #bzr === abentley [n=abentley@bas8-toronto63-1088754407.dsl.bell.ca] has left #bzr [] === p4tux [n=p4tux@189.169.75.18] has joined #bzr === abentley [n=abentley@bas8-toronto63-1088754407.dsl.bell.ca] has joined #bzr === BjornT [n=bjorn@canonical/launchpad/BjornT] has joined #bzr [01:27] would anyone have a guesstimate for when win32 0.90 installers will be up? [01:28] Janzert, typically they come within a day or two of the release [01:28] I'm not sure who is building them this time [01:28] alexander haro? [01:29] ok, thanks === orospakr [n=orospakr@bas4-ottawa23-1167864821.dsl.bell.ca] has joined #bzr [01:32] yah [01:32] might need a oing === mthaddon [n=mthaddon@canonical/launchpad/mthaddon] has joined #bzr === mw is now known as mw|out === tonyy [n=anthony@ubuntu/member/tonyyarusso] has joined #bzr === tonyy is now known as tonyyarusso === spiv [n=andrew@canonical/launchpad/spiv] has joined #bzr === markvandenborre [n=mark@ubuntu/member/markvandenborre] has joined #bzr [02:24] ok, should have our 0.90 debs up shortly, last build glitches for feisty gutsy sid seem fixed === lifeless foods === n2diy__ is now known as n2diy [02:35] btw, in case anyone cares I asked Apress and O'Reilly if they had any plans for a Bazaar book. Both said no, not at this time, but were open to proposals. [02:37] if they pay me a million dollars I will write two books on bzr === bac [n=bac@canonical/launchpad/bac] has joined #bzr === orutherfurd [n=orutherf@dsl092-164-022.wdc2.dsl.speakeasy.net] has joined #bzr === beuno [n=beuno@201-213-170-7.net.prima.net.ar] has joined #bzr === NamNguyen [n=namnt@148.177.217.131] has joined #bzr [03:34] spiv: hows that digit ? === bac [n=bac@canonical/launchpad/bac] has joined #bzr [03:35] lifeless: in motion ;) [03:36] digit? === lifeless defers to spiv [03:38] I used a phrase like "I need to extract my digit" in a call yesterday when talking about getting the latest hpss fetch optimisation work up for review. [03:44] lifeless, there's an extension of look before you leap [03:44] which is about giving nice error messages if someone uses an api wrongly [03:45] for example if you give just a string rather than a tuple to an index as a key, [03:45] it just fails to match, or gives you a 'weird' error when trying to insert [03:45] i would have thought this was a bug, but it's probably not - checking everything takes time [03:45] and once i realize it's my bug it won't happen again [03:46] right [03:46] you do pay the cost of developers being more mystified when they have bugs though [03:47] so possibly we should arrange to run with -O in normal use, but with assertions on in development [03:47] so I'd be much happier if "asd"[0] [0] errored [03:47] that sorta thing [03:48] well in this case its a string blackhole [03:48] (1,2)[0] [0] errors [03:48] another thing like that was the patch from aaron i reviewed a while ago [03:48] things that are meant to yield a sequence of strings can silently return just a string instead, potentially making you do much more work [03:48] yup [03:49] my pet wish for python - have a byte data type. not *bytes*, *byte*. [03:49] mm [03:53] woot [03:53] so gzipping is a net win [03:53] we spend 4m20 seconds in IO if we don't gzip [03:53] 1m40 if we do [03:57] this is for a copy of mozilla, naturally === ubotu [n=ubotu@ubuntu/bot/ubotu] has joined #bzr === Janzert [n=Brian@75-134-223-54.dhcp.trcy.mi.charter.com] has left #bzr [] [04:15] poolie, I'm finishing up the patch for bug #107155, should I just send it to the ML with [MERGE] in the topic, or would you like to review it? [04:15] Launchpad bug 107155 in bzr "_get_vendor_by_inspection incorrectly determines "plink" to be the executable" [Medium,Confirmed] https://launchpad.net/bugs/107155 [04:16] beuno: just send to the lsit; things get reviewed there :) [04:17] lifeless, should of guessed, thanks. I'm a bit nervous as this is actually changing code in bzr, I'm not that confident yet :p [04:20] lifeless, do you want to talk about gzip some more? === igc lunch [04:25] sorry, no browser: [04:25] gzip each hunk [04:25] real 5m53.774s [04:25] user 4m7.047s [04:25] sys 0m12.901s [04:25] no gzip [04:25] real 7m8.611s [04:25] user 2m41.846s [04:25] sys 0m16.821s [04:25] gzip entire contents [04:26] real 4m46.153s [04:26] user 4m29.457s [04:26] sys 0m11.961s [04:26] so we spend nearly 50% of our user time doing gzip [04:27] but overall time is IO bound for mozilla's tree if we don't gzip [04:43] lifeless, should of guessed, thanks. I'm a bit nervous as this is actually changing code in bzr, I'm not that confident yet :p [04:43] (sorry, wrong windows) [04:43] :) [04:44] irssi still confuses me with the actual terminal sometimes, so up + enter is dangerous :p [05:06] igc: ping [05:07] hi abentley [05:07] Hi there. === bheekling [n=bheeklin@220.225.2.107] has joined #bzr [05:08] I wanted to try and get a clearer idea of the distinction between "user guide" material and "user reference" material. [05:08] the 'reference' should cover every detail ... [05:08] Does bzr work from behind an http proxy? [05:08] ie, if I set the http_proxy etc variables [05:09] 'cause the hook document was definitely meant as a how-to. [05:09] but not bother explaining how to use those details [05:09] bheekling: yes [05:09] how-to is definitely 'User Guide' material [05:09] it doesn't seem to be working for me, it says "bzr: ERROR: Transport error: Server refuses to fullfil the request" [05:09] abentley: I'm pleased to see hooks added to the User Guide ... [05:09] bheekling: interesting. You might try http+httplib [05:10] rather htan just http [05:10] The list of actual hooks though also lives in the Reference I feel [05:10] and please file a bug with as much information as you have - what proxy server [05:10] igc: I think a certain amount of reference material is necessary to any how-to. [05:11] yes. At least enough to explain things and give samples [05:11] lifeless, what do you mean by http+httplib? [05:12] I guess I could ignore all the other hook types and just talk about the push hook. [05:12] abentley: if and when we get lots of hooks, I don't think I want all of them in the Guide [05:12] And then link to a hook reference. [05:13] That sounds good [05:14] bheekling: 'bzr OPERATION http+urllib://server/path' [05:14] What is strange but true is I often 'bzr pull' my own patches off Bundle Buggy. The hook docs were written at work, but I'll finish them at home. [05:15] I download patches off BB all the time, even though their in my email somewhere [05:16] s/their/they're/ [05:16] igc: I download my own patches, though. [05:16] ok, you win :-) [05:17] can't beat that :-) [05:20] lifeless, it works with that, thanks :) [05:20] bheekling: can you please file a bug? [05:20] bheekling: specify what proxy you have if you know [05:21] lifeless, okay, I'll do that [05:21] thanks [05:29] lifeless, correction, it seems bzr works with my proxy just fine, that problem was a random fluctuation I think :) [05:29] Its importing happily now [05:42] poolie: any further thoughts re whether -D needs to stay a global option or not? I'm planning to make it a "standard option" instead of a global one unless I hear a reason not to [05:43] it affects everythin [05:43] so it should be global IMNSHO [05:44] ok - so it *must* remain global? [05:45] igc, hi [05:45] I think so, because we might do e.g. -Dcommand at some point, to track ui loading [05:45] if we're happy not to do that, then having it standard is ok [05:46] It seems to me that the limitations re global options are aceptable to -D [05:47] profiling is the most boringest thing [05:47] igc, i agree it's ok to change it [05:47] is there a particular motivation for changing it? [05:47] I can certainly see a case where parsing it before anything else would be required [05:47] poolie: just following up your email [05:48] ... where you thought out loud about 'maybe -D doesn't need to remain global' [05:48] IIRC that is [05:49] ok [05:49] annotations cost us heaps [05:49] $ rm -rf .bzr && bzr --no-plugins init --experimental && bzr --no-plugins add > /dev/null && time ~/source/baz/repository/bzr --no-plugins commit -m "Initial commit" 2>/dev/null [05:49] so poolie, given the feedback from lifeless, I'll leave it global [05:49] real 3m50.336s [05:49] user 3m34.897s [05:49] sys 0m10.941s [05:49] thats a 30 second improvement [05:49] on initial commit [05:50] just by not caching annotations [05:50] (4m23 to 3m50) [05:50] lifeless: interesting [05:59] lifeless: that's strange, because annotations do require sequence matching, but so does knit delta generation, and AIUI, they share the same sequence matching. [06:00] we do less string manipulation without annotations [06:00] because annotations are stored as line prefixes in the knit record [06:01] So even changing our annotation representation might help a lot? [06:02] potentially [06:02] lifeless, one thing you could try is using lzo compression [06:02] which uses less cpu than gzip [06:03] I found nearly no difference using one gzip file versus one-per-record [06:03] user 4m29.457s [06:03] user 4m3.963s [06:03] in fact, it went backwards [06:03] which was weird [06:04] Smaller working set, maybe. [06:05] lifeless, is there already a container record that says "give me the contents of the bytes record at (off,len)"? [06:06] poolie: EPARSE [06:06] do you mean API ? [06:06] my index tells me i want the record at a certain location in the container [06:06] yes, api [06:06] mistyped [06:07] pack.make_readv_reader [06:08] excellent [06:09] abentley: I don't think so; compressing the entire pack to a single zip should have nearly identical memory use [06:10] I htink there is still room for considerable noise [06:10] btw feisty gutsy sid repos on bazaar-vcs.org have bzr/bzrtools/bzr-gtk 0.90 now [06:10] lifeless: nice. [06:10] Edgy? [06:10] on my list [06:11] Ah. Not as easy to update, then? [06:11] not quite, got to back out some packaging changes that removed explicit versioning on depends [06:11] etch is the same? [06:12] yah [06:15] can we cast a vote with BB's web interface? [06:15] if you have an account; accounts are granted when abentley things you are sane [06:15] lifeless: i'm running bb on my machine [06:16] but i cant find any button to approve or decline a merge request [06:16] NamNguyen: Congratulations. AFAIK, that's the first independent install. [06:16] NamNguyen: You have to be logged in. [06:16] abentley: and i have logged in [06:16] ManNguyen: have a read of http://bazaar-vcs.org/IanClatworthy/CoreDeveloperHandbook. It should answer some of the questions you had yesterday [06:17] NamNguyen: ^^^ [06:17] So it should show you voting options from "reject" to "approve" on the request page. [06:18] i see a list of tabs, but i dont see any buttons [06:18] lifeless, it looks like i want something like that, but creating a BytesRecordReader, not a ContainerReader... [06:18] You need to go to the page for a particular request. [06:18] poolie: you want one record out? [06:19] well, possibly more than one [06:19] poolie: thats going to perform badly on high latency links [06:19] By clicking on the summary link [06:19] poolie: I don't see why it doesn't do what you need - you iterate the container to get the byte records you want [06:20] abentley: thank you, it's weird, now i can see it, i was so sure i didn't see that before [06:20] oh i see [06:20] No problem. [06:20] there's just one more layer... [06:21] I saw earlier you were upset it used procmail. Does your server not have procmail? [06:21] it's running on windows [06:22] Amazing. [06:22] so i wrote a pop3 client to manually poll at 5-min interval [06:22] and submit it to the web [06:23] Hmm. Maybe that makes sense for Windows. [06:23] yea, it doesn't have local maildir [06:23] but of course, then it wouldn't be "real-time" enough [06:23] cygwin has procmail if you want it [06:25] Well, you certainly can set up a local mail server on Windows, I just imagine it's a pain. [06:25] i'm using gmail apps [06:25] setup.exe from cygwin, select fetchmail and procmail; or at least thats what I'd do:) [06:25] it's better just to write a few lines of pop3 [06:27] lifeless: You shameless former-cygwin-developer, you :-) [06:27] :) === g0ph3r [n=g0ph3r@p57A0BCD6.dip0.t-ipconnect.de] has joined #bzr [06:30] NamNguyen: Well, if you've got any feedback on Bundle Buggy, I'd be interested to hear. But I'm off to bed in a minute. [06:30] linking bb and pqm [06:30] but, good night aaron === AfC [n=andrew@office.syd.operationaldynamics.com] has joined #bzr [06:30] it'd be a complete solution for patch management [06:31] Ah. The reason BB doesn't submit to PQM is because usually by the time a patch has been approved, it no longer merges cleanly. [06:33] so a human is required after all [06:33] Well, for the Bazaar codebase at least. [06:34] it would be nice to have them integrated [06:34] someday [06:34] We are constantly updating the top of the NEWS file, so we get conflicts there. [06:35] the big difference is in userspace [06:35] hg spend 1 minute in userspace [06:35] we spend 3.5-4.5 [06:35] and is it mostly in gzip, or was that a wild goose chase? [06:36] we spend 1m20 in gzip [06:36] gzip each hunk [06:36] (with hot source files) [06:36] real 4m23.884s [06:36] user 4m3.963s [06:36] sys 0m11.649s [06:36] no gzip [06:36] real 7m8.611s [06:36] user 2m41.846s [06:36] sys 0m16.821s [06:36] gzip entire pack [06:36] real 4m46.153s [06:36] user 4m29.457s [06:36] sys 0m11.961s [06:37] "hot source files" === AfC has an image if Bazaar being used by a XXX movie company. [06:38] G'night, folkds. [06:38] folks, even. [06:40] night abentley [06:40] this is interesting [06:40] du -sh .bzr/ [06:40] 142M .bzr/ [06:40] thats the pack repo [06:40] hg had a 280M repo [06:41] with no annotations, naturally [06:41] poolie: up to a chat ? [06:41] (what are annotations?) [06:42] lifeless, in a sec [06:42] (heard them mentioned here a few times as having a space impact) [06:42] AfC, our memory of what revision changed a line [06:42] AfC: precalculated line -> revision id mappings [06:42] it makes gannotate and weave merge fast [06:42] AfC: what makes 'bzr blame' so fast [06:42] Huh [06:42] Neat. Thanks. [06:43] poolie: ok, ring my mobile please, I'm going for a walk [06:44] Pack repo of what? [06:45] mozilla === fullermd blinks. [06:46] That's freakin' small. [06:46] just the initial import i think [06:48] Not sure if you gents saw this on planet.gnome.org or elsewhere, but this post by Alex Gravely is excellent, http://www.beatniksoftware.com/blog/?p=74 [06:50] Oooh, ok. So it's merely "rather nice", not "mind-zonkingly tiny". === orospakr [n=orospakr@bas4-ottawa23-1167864821.dsl.bell.ca] has joined #bzr [07:11] du -sh . [07:11] 669M . [07:11] du -sh .bzr/ [07:11] 142M .bzr/ [07:11] so 550M for the source === ollie_r [n=orutherf@dsl092-164-022.wdc2.dsl.speakeasy.net] has joined #bzr [07:47] holy fuck this test is taking forever [07:47] a$ python -m timeit -s 'from bzrlib.tuned_gzip import GzipFile; from bzrlib.osutils import pumpfile' "of=GzipFile('/dev/null', 'wb'); pumpfile(file('../mozilla.tar', 'rb'), of); of.close()" [08:06] Hmm... bzr branch bzr+ssh:// seems to have a regression compared to bzr branch sftp:// [08:06] bzr branch bzr+ssh://fedorapeople.org/home/fedora/toshio/public_html/bzr-repo/packagedb/fedora-packagedb-stable [08:06] Copying repository content as tarball... [08:06] bzr: ERROR: Tags not supported by BzrBranch5('file:///var/tmp/fedora-packagedb-stable/'); you may be able to use bzr upgrade --dirstate-tags. [08:07] there is a bug on this === duckx [n=Duck@tox.dyndns.org] has joined #bzr === Basic_py [n=Basic@gatekeeper.real-time.com] has joined #bzr === ThomasAH [n=thomas@aktaia.intevation.org] has joined #bzr === siretart [i=siretart@ubuntu/member/siretart] has joined #bzr [08:08] Cool. I'll go look in launchpad. [08:08] (but no fix yet) [08:08] when spivs patches arrive they will fix it [08:12] excellent. Thanks for the info. === aadis [n=aaditya@122.167.214.15] has joined #bzr [08:16] (by deprecating that other api) === allenap [n=allenap@212.233.37.68] has joined #bzr === james_w [i=jw2328@jameswestby.net] has joined #bzr === tonyy [n=anthony@ubuntu/member/tonyyarusso] has joined #bzr === Lo-lan-do [n=roland@mirenboite.placard.fr.eu.org] has joined #bzr === tonyy is now known as tonyyarusso === sverrej [n=sverrej@tul-1x-dhcp016.studby.uio.no] has joined #bzr === dato [n=adeodato@84.120.252.50.dyn.user.ono.com] has joined #bzr === hstuart [n=hstuart@0x503e9913.virnxx12.adsl-dhcp.tele.dk] has joined #bzr === aadis [n=aaditya@122.167.214.15] has joined #bzr === BjornT [n=bjorn@canonical/launchpad/BjornT] has joined #bzr [09:55] spiv, hi? [09:58] poolie: hello [10:01] Hmm, will have to finish this email on the train. === spiv -> gone === dhon__ [n=dhon@60-240-97-109.static.tpgi.com.au] has joined #bzr === Lo-lan-do [n=roland@mirenboite.placard.fr.eu.org] has joined #bzr === herzel [i=herzel@gateway/tor/x-6f1ce91419018516] has joined #bzr [10:07] Hello all. [10:08] spiv, quick call? === mrevell [n=matthew@canonical/launchpad/mrevell] has joined #bzr [10:08] Is there a way to have a branch living under another directory than where the repository is stored? [10:08] no, it has to be contained within the repository [10:09] but, you can just put it elsewhere [10:09] this is more for avoiding confusion than technical reasons [10:09] Is that a theoretical impossibility? [10:09] Ah, no, good. [10:09] um [10:09] the revisions will not be transferred to the repository, but you can push them by hand [10:09] Actually, let me come up with the context. [10:09] let me make sure i understand? do you mean you want a branch whose history is stored in a directory that's not above the branch? [10:09] or you can create a lightwheit checkout of a branch elsewhere in the filesystem === ubuntulog [i=ubuntulo@trider-g7.fabbione.net] has joined #bzr === Topic for #bzr: The Bazaar Version Control System | http://bazaar-vcs.org/ | Bazaar 0.90 is out - http://bazaar-vcs.org/releases/src/bzr-0.90.tar.gz | Please complete the Bazaar User Survey - http://www.surveymonkey.com/s.aspx?sm=L94RvLswhKdktrxiHWiX3g_3d_3d === Topic (#bzr): set by james_w at Tue Aug 28 23:38:27 2007 === ipkiss [i=ipkiss@nat/ecp/x-800f2584e8d354ec] has joined #bzr [10:58] Lo-lan-do: yes, local push will create trees; there should be a bug on that [10:59] 'kay. I can live with that for now, since there's remove-tree :-) === aadis_ [n=aaditya@122.167.176.221] has joined #bzr [11:02] Ah, but bzr branch doesn't know about --create-prefix. === Lo-lan-do goes mkdir === herzel [i=herzel@gateway/tor/x-4dfb4447af28058a] has joined #bzr === luks [i=lukas@unaffiliated/luks] has joined #bzr === gabe_ [n=gabriel@91.84.56.254] has joined #bzr === Demitar [n=demitar@c-212-031-190-120.cust.broadway.se] has joined #bzr === dato [n=adeodato@84.120.252.50.dyn.user.ono.com] has joined #bzr === ubotu [n=ubotu@ubuntu/bot/ubotu] has joined #bzr === dato [n=adeodato@84.120.252.50.dyn.user.ono.com] has joined #bzr === ubotu [n=ubotu@ubuntu/bot/ubotu] has joined #bzr === jelmer [n=jelmer@a62-251-123-16.adsl.xs4all.nl] has joined #bzr [12:30] is there a bzr-gtk 0.90 deb yet? [12:31] there is one in debian, not sure whether it's been uploaded to bazaar-vcs.org or ubuntu yet [12:31] ah === ubotu [n=ubotu@ubuntu/bot/ubotu] has joined #bzr [12:31] thumper: Whoops, I lied. It's post-0.90, so no release yet. [12:32] mwhudson, jelmer, it's up in feisty at least [12:33] at least an apt-get upgrade fetched it for me this morning [12:33] it is? [12:33] ah, ok - so it's up on bazaar-vcs.org [12:33] oh [12:33] i don't have bazaar-vcs.org in my repo list [12:33] I live life dangerously ;) [12:36] well, i run bzr.dev most of the time... [12:36] bzr's managed to take a 30Mb tree and turn it into 51Mb just to import - is that ratio expected? [12:37] hmm, the bzr upgrade on my second box is failing, though [12:37] getting a: error in control file: `Files' value not specified at /usr/sbin/install-docs line 804, line 10 [12:41] elmo: i'm not quite sure what you mean by 'import' [12:41] that ratio does seem a little big, how compressible is the stuff you're importing? [12:42] mwhudson: bzr init; bzr add; bzr commit [12:43] mwhudson: it's /etc/gconf from a feisty fesktop; I suspect very compressible in a tar sense, less so in an indiviual file sense [12:43] i would expect that to increase the size of the tree by ~the size of the tree when gzipped [12:43] each file gzipped independently [12:44] hstuart: hm, me too === ddaa [n=david@canonical/launchpad/ddaa] has joined #bzr [12:46] so... who do we lynch? ;) === asabil [n=asabil@62.70.2.252] has joined #bzr === rocky [n=rocky@stjhnf0121w-142163169024.pppoe-dynamic.nl.aliant.net] has joined #bzr [12:48] hmm... the new feisty deb for bzr 0.90 seems busted? [12:48] slightly [12:48] lol [12:48] kk... just making sure someone knew ;) [12:48] you can solve it by adding this line to /usr/share/doc-base/bzr : Files: /usr/share/doc/bzr/html/index.html as the last line [12:49] not sure whether that's a decent fix, but it got the rest through installation here [12:50] ah thanks [12:51] here's a quick question ... when i install bzr deb it says "INFO: using old version '/usr/bin/python2.3'" because i manually installed python2.3 into /usr/bin ... /usr/bin/python points at python2.5 so why would it be saying that? [12:51] no idea, sorry [12:52] hm... time to ask #ubuntu i suppose ;) === rocky [n=rocky@stjhnf0121w-142163169024.pppoe-dynamic.nl.aliant.net] has left #bzr [] [01:02] hstuart: yeah, known problem (re install-docs). I think lifeless is on top of it. [01:09] ok, great [01:22] yes [01:22] had a missing output dir, but otherwise its looking good === mrevell is now known as mrevell-lunch === bac [n=bac@canonical/launchpad/bac] has joined #bzr === lunatic [n=francois@erlannic.irisa.fr] has joined #bzr [01:42] is it possible to cancel a pending merge ? === NamNguyen [n=namnt@cm246.delta196.maxonline.com.sg] has joined #bzr [01:43] lunatic, `bzr revert`, if I understood you correctly === herzel [i=herzel@gateway/tor/x-63e166cbfb8e4646] has joined #bzr [01:44] yes but revert does not stop the status message to display "pending merge" === ollie [n=orutherf@dsl092-164-022.wdc2.dsl.speakeasy.net] has joined #bzr [01:45] lunatic: it does, it does. at least here it does. [01:46] ok, so I perhaps have a strangeness here [01:46] thanks for all [01:51] lunatic: "revert ." will not clear the pending merge, only "revert" with no arguments. === Lo-lan-do [n=roland@mirenboite.placard.fr.eu.org] has left #bzr ["Leaving"] === cprov [n=cprov@canonical/launchpad/cprov] has joined #bzr [02:02] lifeless: The major costs in annotation, diffing and merging are sequence matching operations. It would be nice to serialize the get_matching_blocks output. Could you investigate how much that costs? [02:03] whats the difference between that and our deltas today? [02:04] hmm, actually 10pm here [02:04] lifeless, one trivial question [02:04] I'm going to finish my talk slides and sleep [02:04] remind me tomorrow :) [02:04] lifeless, does the new (packs?) format produce a smaller file than the knit? [02:05] our knits are now 250MB! [02:05] kiko-afk: launchpads ? [02:05] yes [02:06] 250M seems a little small to me [02:07] i think kiko just means the inventory.knit ? [02:07] $ ls -lh launchpad.packs/.bzr/repository/packs [02:07] total 347M [02:07] -rw-r--r-- 1 robertc warthogs 346M 2007-08-16 07:55 9e0bcc57d834ca3ae0b5f5844d82dedb.pack [02:07] ~$ ls -lh launchpad.packs/.bzr/repository/indices/ [02:07] total 25M [02:07] -rw-r--r-- 1 robertc warthogs 2.1M 2007-08-16 07:55 9e0bcc57d834ca3ae0b5f5844d82dedb.iix [02:07] -rw-r--r-- 1 robertc warthogs 2.1M 2007-08-16 07:55 9e0bcc57d834ca3ae0b5f5844d82dedb.rix [02:07]