[00:31] If I have a remote branch with some ghosts, how do I fix them? If I fetch-ghosts on a local copy and then push, it does nothing. [00:46] jml: what bug number is your stacked performance # ? [00:46] wgrant: you need to fetch-ghosts directly on the remote branch [00:46] I;m not sure if the cli supports that or if you'll need to [trivially] patch the command first [00:46] lifeless: bug 331823. [00:46] Launchpad bug 331823 in bzr "Pushing an update of a stacked branch to Launchpad sometimes takes nearly an hour" [Critical,New] https://launchpad.net/bugs/331823 [00:47] wgrant: Hmmm - fetch-ghosts does not have a -d option. It should have... [00:47] lifeless: Thanks. [00:47] jml: its almost certainly the interface fixes for hooks [00:47] garyvdm: What would -d do? [00:47] lifeless: ok. [00:48] wgrant: normaly a -d option lets you specify the branch/directory to perform the action on [00:48] garyvdm: Ah, right. [00:49] a> bzr push b == bzr pull -b a [00:49] Err [00:49] a> bzr push b == bzr pull -d b a [01:02] my next patch drops push-trivial-branch to 44 hpss calls [01:03] spiffy [01:14] What does hpss stand for? [01:14] high performance smart server [01:25] is loom included in the OS X dmg file? === monty is now known as montywi|zzz [02:20] lifeless: 44 seems high, what was it? and what is a trivial branch for this example? [02:41] thumper: 107 [02:41] thumper: a trivial branch is a trivial branch [02:41] current bzr.dev is 64 [02:42] lifeless: like a single revision? [02:42] yah [02:42] lifeless: to a stacked branch? [02:42] no [02:43] current bzr.dev stacked is 88 [02:43] for the equivalent test case [02:46] my branch drops that to 68 [03:14] beuno, http://www.ericsink.com/entries/git_immutability.html [03:15] The streaming push stuff should help "push a couple new revisions to an existing branch", right? [03:16] Peng_: modulo bug 331823 [03:16] Launchpad bug 331823 in bzr "Pushing an update of a stacked branch to Launchpad sometimes takes nearly an hour" [Critical,New] https://launchpad.net/bugs/331823 [03:18] rockstar: nice [03:18] Well, I don't use stacking. For my usual "bzr push-and-update" case, I think it's helped nicely. [03:18] lifeless, I thought so. This is something that's always bothered me about a DVCS in general. [03:18] Seems to be about 7-10 seconds now, when it used to be maybe twice that. [03:18] I still don't really like `bzr uncommit` either. [03:19] Peng_: cool [03:19] Peng_: sweet [03:20] "Some folks say that Git's killer feature is its index. That's like saying that C's killer feature is the ability to cast an int to a pointer." [03:20] Peng_: http://bazaar-vcs.org/SmartPushAnalysis1.13 has some early numbers, FWIW. 1.13 final is likely to be significantly better than those numbers. [03:21] Peng_: glad to hear the improvements exist for real users :) [03:22] spiv: Oh, thanks for the link. [03:22] Thank you for your work! :) [03:24] Faster push? Sweeeeet! [03:42] fullermd: ... but that's true :-) [03:43] spiv: any truth to the rumour that v1.13 will be release on the 2009-04-01? ;-) [03:48] spm: you'd have to ask the release manager ;) [03:54] Hm. `bzr help commands` seems to see the new plugin I'm writing, but actually invoking tho command throws a NotImplementedError [03:54] Any idea why that might be happening? [03:56] rockstar: what's the traceback? [03:56] rockstar: I bet something in your command is triggering a raise of NotImplementedError ;) [03:57] spiv, the only thing in the command is a docstring and a pass [03:57] spiv, http://pastebin.ubuntu.com/122179/ [03:58] rockstar: so you don't implement a run method on your command object? [03:58] * rockstar facepalms [03:59] Was doing that in the __init__ Thanks for the extra set of eyes there. === chx_ is now known as chx [04:09] abentley: ping [04:10] jml: pong [04:10] abentley: I'm looking at the lp-open patch... [04:10] abentley: I would like to be very careful that Branch.open doesn't do network operations in the tests. === Guest44001 is now known as Spaz [04:12] abentley: sorry, I'm trying to think about how to formulate an actual _question_ [04:12] jml: Seems ironic, considering what you're testing... [04:12] abentley: yeah, I know. but I'd like the tests to not suck :) [04:14] jml: The approach of using Branch.base was a suggestion, not a requirement. If you want to land the current patch first, that's fine with me. [04:14] abentley: ok. I'll leave that bit as-is. [04:14] self.assertEqual( [04:14] ['Opening https://code.edge.launchpad.net/~foo/bar/baz in web ' [04:14] 'browser'], [04:14] self.run_open('bzr+ssh://bazaar.launchpad.dev/~foo/bar/baz')) [04:14] abentley: ^^ that's the thing I'm not sure how to test. [04:16] jml: I guess you could register your own https handler. Seems a bit overkill [04:16] abentley: yeah. [04:17] Sorry, I meant bzr+ssh handler [04:18] jml: So this looks like a blackbox test. Is it? [04:18] yeah. [04:18] Does it need to be? [04:18] umm. [04:19] no. It was the easiest way to do it when the command was smaller. [04:19] there are also unit tests for the feature. [04:20] It sounds like this test is redundant. Is that right? [04:21] not quite [04:21] I tell you what the Right Thing is [04:22] _possible_locations and _get_web_url ought to be unit tested [04:23] and then that test would reduce to 'attempt to look up whatever is passed on the command line' [04:24] Sounds good. [04:26] anyway, I've filed https://bugs.edge.launchpad.net/bzr/+bug/333681 and replied to your review [04:26] Ubuntu bug 333681 in bzr "Make lp-open also check Branch.base" [Low,Triaged] [04:26] abentley: do I need to send another bundle or a progress diff or something? [04:28] jml: Yes, you should submit a new merge directive, not an incremental diff. [04:32] thanks. [04:38] why would 'info' not print anything. [04:39] if it crashed? [04:39] lifeless: return code 0, say the logs. [04:40] yeah, looks like non-existent branch. [04:40] bzr info in a bzrdir with no branch or repo says nothing silently [04:40] i meant to file a bug about that... [04:41] for example: [04:41] mwh@grond:trunk$ bzr info sftp://bazaar.launchpad.net/~mwhudson/bzr [04:41] mwh@grond:trunk$ [04:41] mwhudson: please do [04:41] mwhudson: yeah, that's what I'm seeing. [04:41] I'll do it [04:42] jml: thanks [04:42] mwhudson, lifeless: https://bugs.edge.launchpad.net/bzr/+bug/333684 [04:43] Ubuntu bug 333684 in bzr "bzr info fails silently when pointed at a bzrdir with no branch, repo or checkout" [Undecided,New] [04:46] incidentally, info -v does *way* too much. [04:51] spiv: in this comment -- https://bugs.edge.launchpad.net/bzr/+bug/255292/comments/22 -- you say "capture the SFTP conversation" [04:51] Ubuntu bug 255292 in launchpad-bazaar "MemoryError/OverflowError in _read_info_file during branch unlock when pushing over SFTP" [Undecided,Incomplete] [04:51] spiv: presumably you want some sort of unencrypted version?, rather than the data sent on the wire? [04:51] gotta say the whole green flash when changing a bug title is ... odd [04:53] lifeless: file bugs about it on Launchpad if you want to. [05:06] jml: fwiw, the copying of .bzr to backup.bzr on upgrading a launchpad branch seems to trigger that bug a pretty large fraction of the time [05:06] jml: oh, I do [05:06] jml: if you want a test case [05:06] mwhudson: that's good to know. [05:07] mwhudson: right now, I just want to make some movement on it. [05:41] jml: yes please [05:42] jml: unless you want to provide me with tools to decrypt your SSH conversations ;) [05:42] spiv: do you want to provide me with tools to record a decrypted SFTP session? [05:42] i imagine hacking paramiko is going to be required :/ [05:46] mwhudson: gosh, I haven't hacked paramiko to get debugging information in _months_ [05:52] jml: I *want* to [05:52] jml: that unfortunately doesn't mean that I *will*... [05:52] Basically, what mwhudson said sounds like the most likely route. [05:54] Someone should write a pipedump util, like tcpdump for interprocess pipes ;) [06:08] jml: btw, I've just sent a probable fix for your bug to PQM [06:08] spiv: the hour-long push bug? [06:08] spiv: thanks. [06:27] jml: yeah [06:27] igc [06:27] is back [06:27] welcome back! [07:00] hi all [07:26] hi vila [07:26] hey Ian ! [07:54] vila: can we mark http://bundlebuggy.aaronbentley.com/project/bzr/request/%3Cm2prhqzm09.fsf%40free.fr%3E as merged now? [07:54] igc: man, why are you *all* looking above my shoulder ? :-) [07:55] I think it's merged, I'm trying to understand why it isn't :-) [07:56] Would it help if I looked at your knee instead? [07:56] igc: I think what happened is that poolie merged it more or less manually, I'm checking that [07:56] fullermd: leave my knees alone too, please ! [07:57] fullermd: I mean, I'm an honest person, how dare you young man looking at my knees [07:58] hello vila [07:58] vila: I assume you mean "over my shoulder" .. [07:58] YOU claim you're honest. I think you have shifty knees. [07:58] vila: I'm just cleaning out the merge Q - you're patch just happened to (still) be in it [07:59] igc: damn, over my shoulder, yes. Remember to tell you the favorite expression of my gf grand-mother one day :) [07:59] igc: damn, over my shoulder, yes. Remember me to tell you the favorite expression of my gf grand-mother one day :) [07:59] vila, i'm pretty sure i did merge that, maybe [07:59] probably manually because all bb has is a patch not a bundle [07:59] poolie: we are all pretty sure :) [08:00] * fullermd ponders. [08:00] As more people are pretty sure, does that make the total likelihood higher or lower? [08:00] I mean, a bunch of numbers [certainty] less than 1, multiplied together, get smaller and smaller... [08:07] poolie, igc: right, the only missing bit is a depreceation test, I'll send it to PQM and BB should catch up [08:09] poolie, igc: err, not even that much in fact, only some review feedback is missing regarding adding some try/finally around some f.write() calls [08:09] yes i was merging it for 1.12 so i didn't actually do the tweaks [08:09] and the deprecation mention in NEWS [08:09] would be good to add them if you want to tidy up though [08:10] poolie: doidn it right now [08:10] poolie: doing it right now [08:15] thanks vila [08:19] * vila slaps his knee: *Don't* run selftest in a bound branch, you know that damn it [08:20] vila, what happens? [08:21] poolie: I get prompted for my id_dsa password since the test suite is isolated from my ssh agent [08:21] this is due to 'bzr info' being used by some tests as a 'do something but not that much' command [08:22] it's a known problem related to the branch nick [08:22] vila: sounds like they are not properly isolated; which tests === montywi|zzz is now known as montywi|meeting [08:23] it may be that we're trying to open the branch to print the revision of the source tere [08:23] tree* [08:23] err wait, not bzr info, bzr version, sorry for the confusion [08:26] lifeless: they *are* isolated ans SSH_AUTH_SOCK is cleared, that's the problem :) [08:27] vila: if htey are isolated the fact that your branch is bound should be irrelevant [08:28] well, not really *the* problem, that's only one way to look at it, it's just that bzr version get some information from the branch for the bzr it is running, which IMHO, makes it an unfortunate choice for that kind of tests [08:28] * vila searching for those tests again [08:29] vila: the gathering of data of the bzr running the tests should be outside the test isolation [08:32] lifeless: have a look at bzrlib.tests.blackbox.test_selftest.TestRunBzrSubprocess.test_run_bzr_subprocess and tell me if you will try your approach or choose another command :) [08:35] vila: it looks like an isolation issue to me [08:35] vila: I *bet* the cwd in one of tise is wrong [08:36] vila: and in fact it is, its running the bzr under test rather than [e.g.] an exported copy or some such [08:37] lifeless: I *agree*, but do you you really want to export bzr to run these tests ? [08:37] I meant, I agree that's an isolation issue, but the cure sounds a bit excessive [08:38] vila: perhaps --version shouldn't connect to bound branches in this way [08:38] lifeless: I think I remember tracking the problem until an access is made to the branch *nick*, so not really a --version directly related issue [08:39] yes, nick ill be the trigger [08:41] and still from memory there is a default value which says get the remote one when we access the nick, but changing that wasn't an option, so I back-tracked and finally thought that the right fix was to not *use* --version when possible because that was not worth the effort, and since this was introduced by yet another totally unrelated patch, I just went unbinding my branches when needed :-) [08:42] I mean, I mentioned the problem just after the patch was merged but... there was more important issues around that patch [08:46] In other news, I can confirm that our ftp support hasn't regress under python-2.6 and that all the failing ftp tests were indeed caused by medusa not being compatible [08:50] http://benchmark.bazaar-vcs.org/rrd/runtime-common-suite-all.png [08:54] lifeless: what was that thing ( I think it was you that showed me ) that lets me manage multiple deb packaging branches from a single thing? [09:01] bzr-loom? [09:01] nightall === mvo__ is now known as mvo [09:09] mtaylor: autoppa [09:10] lifeless: hell yes! thanks === mvo__ is now known as mvo [10:33] spiv: it landed! [10:33] spiv: if you have a script to record the timings, it could run overnight :P [10:36] spiv: also, train ride home == VF decorator fully tested. [12:07] hello, I got bzr: ERROR: Invalid http response for http://bazaar.launchpad.net/%7Enotify-osd-developers/notify-osd/main/.bzr/repository/packs/535754cb35e490c69b794a3cc65ffee4.pack: Expected a boundary ()yo,4lJD726(aEMWnFZV) line, got '' [12:08] bzr 1.11 on Fedora 10 , bzr branch lp:notify-osd , I does not supply my lp login yet [12:13] Sounds like the "defective squid" error === awilkins is now known as awilkins_mmmPie === thunderstruck is now known as gnomefreak [12:43] I directly connected to the internet, no proxy is used except for DNS proxy === thunderstruck is now known as gnomefreak === chx__ is now known as chx [12:55] night all [12:55] good night igc [12:55] it's great to have you back [12:55] have I said that already? :) [12:57] night igc, the document looks great, I'll review fully later [12:57] hey beuno [12:58] hi james_w [12:58] how's it going? [12:58] good thanks, you? [12:58] thanks beuno [12:58] thanks james_w [12:59] pretty good, trying to catch up on work, as always :) === awilkins_mmmPie is now known as awilkins [15:16] hi, I'm looking for some (wise) advice about some almost standard options like --include(-i) and --exclude(-x) [15:16] does --include implies that its argument (list of an items) should be used instead of default one? [15:17] or it can be used as "add this items to default list"? [15:17] fast-import-filter command e.g. used first variant: --include list used as default processing list [15:18] any suggestions? [15:20] bialix: I don't remember having ever encountered the second variant, so go with your first variant [15:21] my question related to my scmproj plugin. I have several ways to select components for processing. Yep, the first variant is most logical, and I hope "standard" way to doing this [15:21] vila: thanks [15:21] I'm not sure you need a --include option as opposed as accepting arguments to define your list [15:22] then, --exclude applies to your arguments *or* the default value for your arguments [15:22] I need --include because I'm using arguments for other purposes [15:22] s/as opposed as/as opposed to/ [15:22] -i/-x pair should work just fine [15:24] but... I wonder, why bzr uses -i/-x form as short names for include/exclude, while hg uses -I/-X [15:24] IIRC [15:24] tar defines: --files-from (files listed into a file) and --exclude-from (files listed into a file too), zip defines -x files and includes files specified as arguments [15:24] bialix: dumb luck :P [15:25] bialix: tar defines -X as an alias for --exclude-from, zip defines -x files... [15:26] rexbron: I don't understand your joke [15:26] bialix: And this comes from a case sensitive OS :-) [15:26] vila: I like zip. -x ftw [15:27] no need to hold shift in the end [15:27] ok, bzr is simpler [15:27] reduced wear on the little-finger tendons [15:27] :-) [15:27] bialix: diff defines -x pattern and -X file (containing file names) :-) [15:27] OMG [15:28] How people use Emacs without getting swingeing tendonitis I'll never know [15:28] bialix: on unix, man(1) is your friend :-) [15:28] but in my case it's `diif -x` [15:28] ctrl-alt-meta-ow-shit-my-hand-is-now-a-claw [15:28] awilkins: because they started young and are trained :) [15:28] Escape-Meta-Alternate-Control-Shift ftw :) [15:29] Ah, so you're saying Emacs is the editor for chinese acrobat children? [15:29] and del? [15:29] awilkins: You didn't know *that* ? [15:29] bialix: real programmers don't need del :-) [15:30] oh [15:30] vila: Putty screwed up Backspace when I'm editing files in nfte on Linux, and have to use Del. This always make my crying [15:31] * awilkins gets around this by using Windows via rdesktop on Linux [15:31] * bialix has no such luxury [15:31] Especially since they installed some kind of security product that stops the Windows Vista RDP client working properly [15:32] bialix: besides del is achived with Ctrl-d under emacs :) [15:32] It's really good when you try to open a \\tsclient\ drive and the server BSODs [15:32] ctrl-d deletes selected region for me in fte [15:33] ok, I have answer I've looked for. thanks [15:34] bialix: nah, delete-region is C-w :) [15:34] :-D [15:34] I'd better to do not continue this finger battle [15:35] hehe, I think being comfortable with emacs *requires* to know at least ~50 key bindings, efficient ~100, hacker mode ~150, after that you'd better learn the commands themselves in case you forget the key bindings :) [15:36] How do I disable a plugin? [15:36] cd ~/.bazaar/plugins ; mkdir DISABLED; mv bogus-plugin DISABLED [15:37] cody-somerville: why do you need to disable it and what plugin is it ? [15:37] vila, gtk [15:37] vila, it prevents me from using bzr when X isn't available [15:37] urgh, is it dbus related *again* ? [15:38] yup [15:39] bialix: by the way, qbzr still blows out when I try to run selftest with python-2.6 (for which I don't have pyqt4) [15:39] file a bug please [15:39] cody-somerville: I think this has been fixed at least a dozen of times already :-/ [15:40] vila: IIRC I dont try to fix selftest w/o PyQt4 yet [15:40] bialix: I did and I thought you fixed pretty quickly, only to discover later that the problem was still there [15:40] vila: this is different problem [15:41] I've fixed bug-url command, but you now talks about selftest [15:41] why you run selftest for qbzr if you don;t have qt? [15:42] I run selftest and that includes qbzr because it's installed [15:42] the problem is that qbzr *aborts* at load time instead of raising some import error or something that disables it without aborting the current command [15:43] please, file a bug about selftest [15:43] I'll fix it shortly [15:44] qbzr has a lot places where we import pyqt4 lazily, but some internal modules are not so lazy [15:46] hmm... I guess it wasn't bzr-gtk that was causing the dbus issue [15:46] * cody-somerville tries removing bzr-dbus [15:47] vila: btw my fix is not released yet [15:47] bialix: and you think I'm not running qbzr trunk ? :-) [15:48] bialix: no time to file bug, here is the fix: http://paste.ubuntu.com/122430/ [15:48] bialix: :) [15:48] vial: you said about "installed" version [15:48] sorry, vila ^ [15:48] bialix: tested against 2.5 with pyqt4 and 2.5 without :) [15:48] bialix: sorry about what ? Providing qbzr ? You should be proud instead :) [15:49] sorry about typo in your nickname (I wrote vial) [15:49] the main author is luks [15:49] bialix: I'm running lp:~qbzr-dev/qbzr/trunk@revno 623 [15:49] I'm just hacking it and maintain it [15:50] vila: your fix is quick hack, I'll try to investigate the problem a bit deeper [15:52] bialix: sure [15:52] bialix: and thanks [15:52] for what? [15:52] if you don't have qt you can't use qbzr [15:56] vila: bug #33389 [15:56] Launchpad bug 33389 in samba "Winbind does not start on boot" [Medium,Fix released] https://launchpad.net/bugs/33389 [15:57] no Bug #333892 [15:57] Launchpad bug 333892 in qbzr "selftest crashed if qbzr installed without pyqt4" [Undecided,New] https://launchpad.net/bugs/333892 [15:58] bialix: thanks ! And blame launchpad for eating the spaces in the patch :-) [15:58] bad lp, bad lp. go to the corner and think about it [15:59] vila, it's the world crisis, we had to cut down on food for servers, so now they're after characters. Just wait until they find out how yummy a's are [15:59] * bialix waves [16:02] whoa [16:02] * jelmer is running bzr log on a 190k ooo bzr branch [16:03] bzr sure doesn't like that [16:03] jelmer: 190k revisions I presume ? Having fun ? :-) [16:03] vila: yeah [16:03] vila: brisbane-core rocks btw [16:03] vila, without it it would've taken me days to get this import [16:03] now it took me around 14 hours [16:05] jelmer: good to know, did you talk with igc about it ? [16:05] vila, no, not yet [16:05] it takes about 100 seconds before "bzr log" even gives any output.. [16:06] jelmer: a bare 'bzr log' ? Without any options ? No hidden alias or something ? [16:06] vila: yep [16:07] running with lsprof now [16:08] jelmer: how many packs ? [16:08] vila, 30 [16:08] the largest is 640 Mb [16:09] ... whoah. [16:10] vila, the problem seems to be that it has to walk the graph all the way down to the bottom [16:10] Do they have lots of binary files? (Clip art, logos, etc?) [16:10] NfNitLoop, they mainly have a big history (270k revisions) [16:10] vila, and most revisions are on the mainline [16:11] jelmer: it shouldn't need to walk the whole graph for a bare 'bzr log'... at the least in common cases... [16:11] vila: it has to determine the revno's [16:13] jelmer: yeah, nevermind, I certainly know that and I mixing potential optimizations with actual code ;) [16:13] vila: :-) [16:13] vila: I'll certainly talk to Ian about it [16:14] Ian's revno cache plugin could certainly help there, until we implement some lazy revno tricks [16:14] vila: after the initial wait, it's pretty decent [16:15] I haven't tried his revno cache plugin yet, I'll give it a try [16:15] jelmer: yeah, once we get the graph loaded, log is really streamed [16:15] jelmer: me neither but I saw the code passing around :-) [16:17] vila: same story for "bzr viz" btw, it Just Works except that the initial ancestry browsing is a bit slooow [16:17] jam: http://paste.ubuntu.com/122440/ can fix two more failing tests but I'm affraid the approach can be rude for performances, thoughts ? [16:17] jelmer: bzr viz lacks the nifty +/- of qlog :-) [16:18] vila: To quote lifeless: Patches welcome (-: [16:18] jelmer: not that it will solve the problem you're referring to :-) [16:19] jelmer: hehe, I looked at it once,... and had to work on other things... [16:19] jam: come back ! :) [16:25] vila: do you know why a push from development5-subtree into 1.9-rich-root would use a lot (1Gb) of memory? [16:26] jelmer: in bbc ? [16:26] vila: yeah [16:26] revno 3834 may be ? [16:27] vila: is that the cause or the solution ?:-) [16:27] jelmer: I think it's the cause, but if you don't use it already, let see if it's a solution :-) [16:28] jelmer: and it's the cause, we really like to know as it's part of a streamed push whose purpose is to avoid consuming too much memory :-) === mark2 is now known as markh [16:29] jelmer: and *if*it's the cause, we really like to know as it's part of a streamed push whose purpose is to avoid consuming too much memory :-) [16:36] vila, is it right that that no longer gives any progress indication? [16:37] jelmer: right ? no. Known ? I think so. IIUC part of it was lost during the last big merge made by jam [16:40] thrope, fwiw this is wrong: http://projects.scipy.org/pipermail/scipy-dev/2009-February/011210.html [16:40] thrope, clones *are* the same, and the bzr metadata is not visible as long as you're running svn >= 1.5 [16:41] morning all. [16:42] if bzr blame shows a revision number like "297.2.3" how do I find the "main" revision that introduced the change? [16:42] jelmer: You don't even need to run svn > 1.5 repository [16:42] jelmer: Works fine with a 1.4 format repo and 1.5 libraries [16:43] latexer: You'd need to know which branch that revision came from to find the "main" revision.... or you could just branch it at that revision, and hey presto, you have theat revision [16:44] awilkins: can I at least find the "merge point" that introduced the change? [16:44] latexer: You have qbzr or bzr-gtk? [16:45] awilkins: I think i've got bzr-gtk installed on this box. [16:46] hrm... nope, I removed it cause it kept spitting warning about not working with my bzr version. [16:46] * latexer re-installs. [16:48] hi enigma42 [16:48] awilkins: Ah, I thought that was specific to the collabnet server [16:49] jelmer: I've been using file:/// to push branches into a 1.4 repo locally [16:50] The repo has to be compatible with our server and since I'm the server admin I can't be bothered to upgrade it to 1.5.x [16:50] awilkins, but does that use file proeprties or revision properties? [16:50] jelmer: I'll take a look at the repo [16:50] If you want a copy it's only a couple f meg [16:51] awilkins: ok.... now what? I have a *lot* of revisions in this branch... [16:51] awilkins: the log view doesn't show the revision numbers... [16:52] jelmer: bzr:file-ids? Seems to be using revprops [16:54] awilkins: So nothing shows up in "svn diff" wrt properties? [16:54] On a file across two revisions? [16:54] * awilkins looks [16:59] jelmer: Hello [16:59] jelmer: Not ignoring you...I had just stepped away from my desk. [17:00] awilkins, any kind at all (but bzr-specific, of course) [17:00] Ok, I'm having trouble with the CLI (used to tortoise), and I have to cath my train now, I'll check later === beuno_ is now known as beuno [17:15] vila: just seeing how things are going for you [17:15] jelmer: Oh...one thing comes to mind about 0.5... [17:15] jam: hi ! [17:15] jelmer: Sometimes, a push or a pull takes *forever* [17:16] latexer: I was hoping to get close with 'bzr log -r 297.2.3 -n1 ', but it doesn't do exactly what I'm looking for [17:16] When I turn on transport logging, it looks like it is fetching revision information on rev at a time. [17:16] And for my project, that's several hundred revisions. [17:17] jelmer: Maybe this is due to having a mix of file properties and revision properties? [17:17] enigma42, 0.5.2 should be a lot faster [17:17] (The total push time is about 9 minutes for no changes.) [17:17] jelmer: OK. Let me grab it and try it out. I didn't realize there was a new release. [17:17] jelmer: I guess I haven't been checking it daily recently. ;-) [17:18] jam: I'm back on bbc fixing tests [17:20] vila: sounds good. [17:21] How is the current state for bbc? [17:21] (Just curious if merging bzr.dev made it a lot better or worse) [17:22] jam: Currently working on 'CHKInventory' object has no attribute 'apply_delta' [17:23] jam: merging made it a bit worse, but I've already fixed some, we are not *that* far the previous point [17:23]