[01:07] igc: cool! [01:14] zooko: please let us know if you have more ideas or anyone interested in being a GSoC student [01:15] Will do. [01:37] igc: you have a present [01:42] ok, got a merge/rename issue [01:42] just trying to figure out how to make it jive [01:42] trying to pull a branch (including all its revisions) into another tree. now this has been done before (drizzle plugins) so I know it can be done. [01:43] I branch off the original, create a subdir of choice, then move files from the branch into that subdir, then commit (so the commit contains the creation of hte dir plus the renames). [01:44] branch off the mainline I want to pull in to. bzr merge -r1..-1 from the branch where I just did the rename foo [01:44] then it goes weird. [01:44] the subdir doesn' exist yet but its parent does, so the parent of the mainline gets renamed to .moved. but also the files inside the newly merged dir get shows as base/other. this makes no sense as there is no conflict [01:45] thoughts anyone? lifeless poolie [01:45] i think you want -r0..-1 there not -r1 [01:45] otherwise it will try to merge everything but the first revision [01:46] arjenAU: I suggest the merge-into plugin [01:46] arjenAU: it automates all of this [01:47] poolie: ah was stewart trying to confuse me ;-) this is what he wrote earlier [01:47] lifeless: oh does it! [01:47] lifeless: ? in email? [01:48] lifeless: fast commit maybe? [01:48] igc: yes indeed [01:49] jelmer: you too may be interested in CommitBuilder.record_iter_changes [01:50] igc: btw [01:50] + parents = graph.get_parent_map(revision_ids) [01:50] + self.revision_ids = [r for r in revision_ids if r in parents] [01:50] if you don't need the ordering [01:50] self.revision_ids = list(parents) [01:50] will be faster [01:50] poolie: ok your hint gets me a fair way there. apart from the plugin, how to resolve the .moved thing; which things do I move where to resolve it properly? [01:53] lifeless: right. I haven't thought of that. I'm not sure if the ordering is important in send. abentley? [01:53] igc: I suspect it topo sorts lower down tbh [01:54] lifeless: and well done on record_iter_changes() [01:54] igc: so you're likely causing multiple index reads with the current code; I'd suggest combining the filtering and topo sorting steps [01:54] igc: thanks; proof will be in the pudding [01:54] lifeless: I won't get it reviewed today sorry. I'm off in an hour [01:54] igc: oh, I wasn't asking for you to review; just that you can merge it and use it in fastexport [01:55] :) [01:59] * spiv just sent a patch for https://bugs.edge.launchpad.net/bzr/+bug/109143 [01:59] Ubuntu bug 109143 in bzr "hpss does not support ~ (tilde) for home dir access on bzr:// or bzr+ssh://" [High,Fix committed] [01:59] arjenAU: something like this [01:59] bzr mv parent parent.new [01:59] bzr mv parent.moved parent [02:00] bzr mv parent.new/subdir pante [02:00] (should be) bzr mv parent.new/subdir parent [02:00] then parent.new should be empty so [02:00] rmdir parent.new [02:00] also you could file a bug because we shoudl be able to do better [02:00] poolie: well the merge-into plugin apparently does it? says lifeless [02:01] just trying to do it without so I know hwat's going on [02:01] i'll try what you wrote. I did something similar but got something wrong along the way [02:02] igc: send uses a set there [02:02] igc: so its definitely not order sensitive [02:04] poolie: I think your method did the trick, thanks. [02:09] spiv: re: Support bzr+ssh://host/~/path: thanks! now we're going to have to fix Launchpad :) [02:11] jml: you mean to make push bzr+ssh://bazaar.launchpad.net/~/launchpad/foo work? [02:11] yeah. [02:11] well [02:11] Low [02:11] :D [02:16] spiv: awesome! [02:16] jml: easy to do, though [02:16] orthogonal even [02:17] jml: set the initial working dir in your server to /~foo rather than / [02:17] jml: oh, and teach the server to accept --directory=/ in the bzr serve invocation [02:18] er, [02:18] jml: oh, and teach the server to accept --directory=. in the bzr serve invocation [02:19] I hear VFS's are good at changing things [02:19] hm [02:19] as lifeless says, you could treat the path /~/ specially already for clients that don't interpret it specially. [02:19] i want to rethink almost always having the username in the branch url [02:20] many things that are not series are still project wide [02:20] poolie: for Launchpad? [02:20] mm [02:20] but not this month :) [02:20] * lifeless breathes out [02:21] poolie: did my reply about your changes to test_remote make sense [02:22] yes i think so [02:22] cool [02:22] i'll revisit it after lunch [02:22] was too tired to work out the right thing last night [02:22] heh, and ironically enough jml was distracting me by talking about whether anything is objectively right or not :) [02:23] poolie: *I* was distracting *you*?! [02:23] very much :) [02:24] see. that's subjectivism for you. [02:26] How much more efficient will BBC be over dumb protocols like http than btrees? [02:28] I've gotten really spoiled by the hpss streaming stuff, so now http feels slow. :P [02:34] You're planning to start versioning the Pyrex .c files? Why? So users won't need it? [02:34] Because testsuite passed on 1.13final but the Pyrex stuff isn't in the tarball [02:35] That's a different issue. [02:35] Well, versioning the .c files is a way to solve it, I guess. [02:35] Since I caused the problem, I'll beg to differ, ...exactly :-) [02:37] I did open a bug about a warning that pyrex wasn't installed when I ran the test suite, but everything passed and a discussion between several developers presented versioning the .c as a way to prevent this sort of thing [02:37] Peng_: there was a brief discussion about it on the list about a week ago, IIRC. [02:38] spiv: Oh. I must've missed that. [02:38] Bug #340209 [02:38] Launchpad bug 340209 in bzr "The python package 'Pyrex' is not available under ubuntu when python-pyrex is installed" [Undecided,New] https://launchpad.net/bugs/340209 [02:38] Or perhaps in a bug? [02:38] It'll make for uglier diffs on the rare occasion they're changed. [02:39] I got a tweak status on Bungle Buggy, I read the HACKING doc, still don't know what it means exactly, any more info? [02:39] It'll make tracking bzr.dev easier and the release process a bit simpler too. My main worry is that we wouldn't want the versioned .c files to get out of sync with their source .pyx files. [02:40] Peng_: bug 336933 [02:40] Launchpad bug 336933 in bzr "version control the pyrex output files" [Wishlist,Triaged] https://launchpad.net/bugs/336933 [02:40] (hey cool, that bug number almost has rotational symmetry) [02:41] * spiv looks forward to bug number 886988 ;) [02:41] spiv: Oh, thanks for the link. [02:58] * igc lunch and medical stuff for the rest of the day [02:59] spiv: I want pqm to update them, and noone else to [03:00] BasicOSX: there is an older bug vis-a-vis the .c files, your incident is just meat for the grinder reinforcing it :) [03:06] BasicOSX: it means 'make the recommended changes please [ unless you disagree in which case discuss ] and then submit it to pqm' [03:24] BasicOSX: http://bundlebuggy.aaronbentley.com/help describes the meaning of the different votse. [03:24] "votes", rather === timchen119 is now known as nasloc__ === abentley1 is now known as abentley === abentley1 is now known as abentley [04:00] Ok, I screwed up. My initial commit was of the wrong package. How do I start over? [04:01] sorry in advance for the "save the noob" question" [04:04] adelie42: uncommit or delete [04:04] adelie42: e.g. rm -rf bad-branch :P [04:06] ok, that is what I ended up doing. deleted everything, did an uncommit, pulled the right trunk (well, source which wasn't bzr), bzr add, bzr commit, bzr push [04:08] guess that more or less took care of it [04:12] hey, do you know something [04:12] lazy inventories would be a really good idea [04:18] mwhudson: we have them [04:18] mwhudson: see --gc-chk255 [04:18] lifeless: yes i know [04:19] sadly, not every branch on launchpad is going to have them for a goodly while [04:19] mwhudson: once we have a production format, we can nagware on them :) [04:19] What, you can't force everyone to upgrade or delete their branches? ;-) [04:19] mwhudson: anyhoo; you're facing 'fast on xml' vs 'fast on chk' ? [04:20] Peng_: well, 'can' is a vague concept [04:20] lifeless: well, i think i can avoid loading inventories at all in quite a large number of cases, but it requires vague contortions [04:20] lifeless: it's 'fast on everything' vs 'fast on chk' [04:21] (well, text extraction is faster on chk right? so it will still be faster there) [04:22] * mwhudson goes to fix more obvious sillinesses [04:23] mwhudson: fast on everything is good; but I don't see how you can avoid inventories except when only showing revisions [04:23] lifeless: by slightly extending the information loggerhead already caches [04:24] mwhudson: mmmmm if this is fileid,revid pairs, then its not a slight extension [04:24] i can avoid loading inventories on revision pages when the revision's been seen by the cache [04:24] lifeless: something like that [04:25] mwhudson: I'd be happier hearing that your moving closer to the bzr metal, not further;) [04:26] yeah [04:26] i don't know whether it's worth it [04:26] how many things in CS cannot be solved by adding a layer [04:26] anyway, let me go for sane use of bzr api first off, indeed [04:41] * mwhudson finds a todo in the bzr source from version 0.0.6 [04:44] mwhudson: which one [04:45] lifeless: unifying get_revision_inventory with get_inventory [04:49] lifeless: how evil is constructing revisiontrees directly? [04:49] eh, maybe i can just cache them somewhere (per request) [04:50] mwhudson: repo.revision_trees([list]) should be very fast [04:51] lifeless: .25s per revision for launchpad [04:56] I got a new project I want to work on, but there is no bazaar trunk. There are three brances of the packaging information, but not for the osurce (https://launchpad.net/ubuntu/+source/kdegames). Is the best thing to do just to start a branch, call it source, and branch off of that? What is the way to be doing this? [04:59] adelie42, https://code.launchpad.net/kdegames [04:59] jelmer's branch doesn't seem to be packaging [04:59] * mwhudson wants bzr 1.13 on launchpad [04:59] * pygi looks [05:00] mwhudson: Why? Streaming? [05:00] yup, it seems code [05:00] Peng_: yes [05:00] Peng_: i feel fairly confident that roundtrips affect me more than you :) [05:00] https://code.launchpad.net/kdegames is only the code for the installation data, not kdegames source [05:00] mwhudson: .25s for repo.revisions_trees(50 items), or .25s*50, or .25s for repo.revision_trees([1 item]) ? [05:00] mwhudson: Heh, good point. [05:01] The bad thing about all these performance improvements is that it makes old versions feel so slow. :( [05:01] adelie42, https://code.launchpad.net/~jelmer/kdegames/trunk [05:01] ? [05:01] lifeless: well, futzing with timeit, it's .25 for one revid, and .45s for two [05:01] ah [05:01] lifeless: i don't care about more than 2 :) [05:01] mwhudson: oh, I'd assumed you'd care about the full page [05:01] adelie42, not sure it's most recent obviously :p [05:02] lifeless: ? [05:02] Peng_: are you noticing improvements? [05:02] pygi: ok, it looks like that was what I was about to make [05:02] thanks [05:02] mwhudson: revision_trees does one batch IO to read all the deltas, and then composes them separately, its _way_ faster than doing separate calls- N rather than N^2 roughly [05:02] modulo constants etc [05:04] lifeless: no request in loggerhead (now, anyway) considers more than two revisions [05:04] uh [05:04] revisiontrees [05:04] mwhudson: ok [05:05] mwhudson: how do you populate the 'files changed' then, for the history view [05:05] lifeless: ajax [05:05] one revision at a time [05:06] mwhudson: oh right; isn't that slow? [05:06] Can anyone test bzr 1.13 from the beta-ppa before I roll it out to the main ppa? [05:07] johnf: does your build have the .so's ? [05:07] lifeless: if everyone who loads a changelog page clicks 'expand all', it's a pessimisation overall yes [05:07] lifeless: hmm let me check [05:07] lifeless: Pushing a handful of revisions to my bzr.dev server takes 11 seconds at the most (and that's including push-and-update). I pushed to LP today, and it took 28. So, yes, major improvements. :) [05:07] Peng_: sweet. [05:08] Peng_: how does that compare to hg now? still quite a bit slower I imagine [05:08] * mwhudson wonders when his commit to lp:loggerhead is going to complete [05:08] lifeless: I have no clue at all. I haven't done any small pushes with hg recently. [05:08] Peng_: hooray [05:10] lifeless: _patiencediff_c.so ? [05:10] lifeless: Pushing ~17 revisions in hg took 3.41 seconds, so there's still a ways to go, I guess. [05:10] johnf: should be 5 or so [05:10] johnf: the 1.3 tarball failed to include many .c files - see the list [05:10] ok [05:11] johnf: running 'setup.py build_ext -i' will generate the .c files [05:11] as long as you have pyrex installed [05:11] uhm [05:11] ahh that could be the problem I had earlier [05:11] do this - read the release notes for release managers [05:11] these tell you how to get the .c files [05:11] then stash them into a patch for your 1.13 build [05:11] and you can use your normal build procedure to do that [05:12] is that something new? or has it always been the case? [05:12] I'll update debian/rules to do it [05:17] johnf: its a 1.13.tar.gz special [05:17] won't be needed for 1.13.1 [06:03] lifeless: before I spend time on this is 1.13.1 coming out in the next few hours or next few days? [06:03] short on time at the moment. vquence product launch is tomorrow [06:04] actuallty I've worked it out so doesn't matter [06:13] johnf: :P [06:14] johnf: congratulations :) [06:14] re the launch [06:14] poolie: thanks! [06:16] johnf: indeed, grats [06:26] lifeless: what are your thoughts on the old packages for unsupported releases in the ppa. eg 1.12 package for feisty. Should we delete them? [06:41] * fullermd notes that he just shrugged and added a pyrex dependancy to building the 1.13 port. [06:42] It's so tiny, 's hardly worth even questioning about. [06:44] johnf: no thoughts offhand - mail the list? [06:45] spiv has headed off [06:45] I'm halt()ing [06:45] we got the smart server not making third party requests today, but that will land tomorrowish - some polish needed [06:45] it reveals that branching from a stacked branch is actually only 23 hpss client calls [06:46] poolie: ^ === sabdfl1 is now known as sabdfl [07:31] lifeless: nice [07:31] johnf: is there any benefit in deleting them? [07:31] i wouldn't [07:32] poolie: nah just that they are hanging around and will be fairly old in a few months. [07:36] ok new bzr packages with .so files in. Could someone pease give beta-ppa a quick test? [07:39] oh i see and they're not being replaced by new ones [07:39] still, i probably wouldn't worry [07:39] maybe add a note to the ppa description that they're not being updated? [07:39] it might be better than nothing though... [08:01] ok good idea [08:02] ok on the basis that no one has complained or cares to check I'm going to release the 1.13 packages to ~bzr ppa [08:08] mwhudson: where in python are files implemented? [08:09] johnf: you've given it a spin ? [08:09] yup [08:09] then its been tested :P [08:09] well an update, commit and bzr bd anyway :) [08:10] I haven't used copy between PPAs before. Should I just reuse existing binaries or rebuild [08:15] done [08:26] hi folks [08:26] bzr: ERROR: Specified file "arch/ppc/mm/Makefile" is outside the current view [08:26] how do i fix that? [08:29] all i'm doing is init and add of a large tree [08:35] sabdfl: that looks like a bug in views; views only apply to the development tree format, so I'm assuming you are experimenting with brisbane-core [08:35] lifeless: Objects/fileobject.py [08:35] yup [08:36] sabdfl: uhm to fix it, you could bzr remove-tree, bzr reconfigure --(looking) [08:36] sabdfl: and please do file a bug that this happened, it suggests an issue with the default heaviour of views) [08:36] bzr remove-tree && bzr reconfigure --tree [08:37] doing that immediately after 'init' before add should fix it, I hope [08:37] or perhaps 'bzr view --delete --all' [08:41] view --delete --all doesn't help [08:41] view --switch off doesn't help either [08:41] sabdfl: we're mainly testing with large imports not fresh trees. I'll file a bug for you as it sounds like its generally borking in some respect [08:42] sabdfl: what specific format is this with, and how are you invoking add - 'bzr add', 'bzr add .', 'bzr add *', something else? [08:42] sabdfl: I'm sorry that I can't dig deeper right now, social event kicking off around me [08:44] mwhudson: I was trying to figure out why my parallel test runner was buffering 90 odd lines (from a child process) [08:44] lifeless: am init'ing as follows [08:45] bzr init --format=gc-chk255-big [08:45] find [a-z]* -type f -exec $bzr --no-plugins add \{\} \+ [08:46] sabdfl: I'd try just 'bzr --no-plugins add', as we scan for paths ourselves. Filing bug and am gone. (sorry!) [08:46] lifeless: good luck with that [08:48] ok thanks [08:51] bzr add Just Worked (nice!) but there are still problems with views later, when I try to add a specific file it fails [08:51] even if i switch views off [08:51] igc: ^^ [09:04] is it possible to merge two bzr repositories into one, keeping the history from both repos? === thekorn_ is now known as thekorn [09:25] j^: branch? yes [09:27] sabdfl: I'll take a look [09:33] thanks igc [09:40] bob2, no not branch, guess it somewhat works with join/split [09:47] j^: are you sure you don't mean branches? [09:56] j^: "merging" repositories is just a matter of branching all the branches from one to another [09:59] sabdfl: try rev 3889 of brisbane-core now [10:14] bob2: j^ thought you meant the command, "bzr branch" [10:15] oh right [10:16] j^: your question doesn't quite make sense in bzr terms; perhaps you meant to ask "is it possible to merge two branches with unrelated history?". Yes; use "bzr merge -r0..-1 url/of/other/branch" [10:17] * igc afk - might be back later [10:42] hi i'm trying to use bzr, i want to look at revisions not diffs and grab one... any guis ? [10:43] i get a float division if i put . for branch location [10:45] spiv, ah so i can merge branches with unrelated history, thats what i was looking for yes, have to projects that turned out to be one now. so wanted to get them in one branch [10:45] bzrlib/_dirstate_helpers_c.c:330: warning: cast from pointer to integer of different size [10:45] sigh [10:45] * lamont goes to see if the bug is filed already [10:46] nm found olive [10:54] wait a second [10:54] can i have a branch within a branch ? [10:56] igc: that fixed it - thanks! [10:56] d-b: sure you can [10:57] you mean, you have your branch in ./ and then say a branch of zlib in ./libraries/zlib/ ? [10:58] well my gui isn't working for it and its really really annoying [10:59] mmm how about getting a certain revision ? [10:59] bzr pull is it ? [11:00] yup [11:00] -r revisionspec [11:01] try bzr help revisionspec [11:28] lifeless: hi [11:28] lifeless: your last reply to me about progress bars was empty, was that intentional ? :-) === `6og is now known as Kamping_Kaiser === thekorn_ is now known as thekorn === thekorn_ is now known as hekorn === hekorn is now known as thekorn === vednis is now known as mars [14:07] hello, are nested trees supposed to work currently (in 1.13) or should I just move along? [14:12] I'm looking for a way to have external (referenced) branches inside a main branch, where I can work on them locally in the branch but also can push/merge/pull external changes [14:20] here's what I do: http://dpaste.com/16007/ [14:20] clbry: if you only need that at one spot, and don't need operations to work on the entire collection, you could just use seperate branches [14:21] clbry: http://launchpad.net/bzr-scmproj is another option (just like config-manager) [14:23] LarstiQ: I'd like to reuse the bar project without having to worry about crashing different projects if I modifiy the bar project inside the foo project (but beeing able to pull external changes and to push local changes in a controlled way). and I'd like to have a single checkout of the foo project, automatically including the bar project. perhaps I should give up the latter [14:25] clbry: the former needs no exra support, the latter can be done with scmproj, and for bzr native worked on http://bazaar-vcs.org/NestedTreeProgress [14:28] thx, I'll look into scmproj === kiko-afk is now known as kiko === serg_ is now known as serg [15:32] Peng_: poke [15:39] hey vila, how's it going? [15:40] jam: I'm writing code so ugly I prefer to hide :) [15:45] jam: quick call ? [15:45] sure [16:06] is it necessary to register an ssh key for each machine that is going to connect to bazaar? Virtual or otherwise? [16:07] adelie42, only for write operations [16:10] So if I have 2 computers I use and each got 2 test environments and I want to be able to push from all of them, I need to register 6 individual keys? [16:10] yes, or use the same ssh key [16:11] I can just copy ~/.ssh/id_rsa* to whatever machine I want to use? [16:12] and set the email address to the local user? [16:13] adelie42: yes [16:15] ok, thanks (This really makes me wish I just kept all my data on usb) [16:23] adelie42: eh [16:23] adelie42: now I'm not sure I said yes to what I said yes to :) [16:24] oh? with what regard? [16:24] adelie42: you only need to have 1 key. [16:24] would it be reasonable to file a bug for more things (specifically I care about log) take -c? [16:24] +to [16:24] adelie42: assuming you're talking about Launchpad interaction [16:24] I dislike having to remember different options to get info about a single revision :) [16:25] LarstiQ: yes [16:25] Ng: that's reasonable. There has at least been discussion about it. log and diff have different inclusion rules [16:26] Er? [16:26] Somebody already added -c to log. [16:26] I have a computer at home, and a computer at work. Each computer has a test environment. Fhe best thing to do, it seems to me, is copy my private and public key from each of the hosts to the guests and just have the two registered [16:26] More broken, IMO, since -c now means DIFFERENT things in the different commands. [16:28] Ng: your desire is reasonable, I now hand you over to fullermd to settle the issue ;) [16:28] fullermd: ah, that could be my fault, the machine I was on only has 1.5 [16:28] adelie42: push to where exactly? [16:29] NEWS lists it for 1.8. [16:29] win, thanks :) [16:30] while we're on -c, is there an invocation to svn for -1? It doesn't like HEAD for -c either :/ [16:32] pushing to launchpad [16:34] adelie42: then you'll need 1 or more keys. More than one if they give access to other things than launchpad and/or have different security considerations. [16:34] adelie42: you can live with just 1 if you don't care for seperation [16:34] The virtual machines in question are ONLY for patch testing [16:35] adelie42: do they need to be able to push to launchpad themselves then? [16:35] seems like they don't [16:35] mm [16:35] maybe you guys know [16:35] how wouldi change the http links in loggerhead to https [16:36] i've been digging through the code and i haven't found where that part in constructed yet [16:36] technically, I guess not. Though I don't see why it wouldn't just be easiest to have the machine saved clean with the hodt key, and when testing is good and done, push before resetting for next test [16:37] Kobaz: are you using loggerhead behing apache proxying? [16:37] yeah [16:40] Kobaz: https://bugs.edge.launchpad.net/loggerhead/+bug/260547 [16:40] Ubuntu bug 260547 in loggerhead "start-loggerhead script doesn't properly set the wsgi.url_scheme from the server.webpath option" [Medium,Fix committed] [16:40] Kobaz: though really a different bug should be filed for the issue you and I are seeing [16:46] is there some way to enter the debugger when a test raises an (unhandled) exception? [16:46] BZR_PDB doesn't work in that case at least [16:47] Meh, I was just considering resurrecting my enhanced stack trace code, but I can't find it anywhere [16:47] It wasn't much though, just changed the code that prints the stack trace so it listed the values of variables and parameters [16:48] jelmer: it works, you just don't see what you're doing ;) [16:48] jelmer: nose has -s for that, don't know offhand how to so for bzr [16:49] LarstiQ: nose doesn [16:49] 't work very well for bzr plugins yet though [16:49] jelmer: ah, I hadn't tried it on bzr yet. [17:15] Hi all [17:16] jelmer: I seem to be running problems when rebasing a bound branch, is that expected? [17:17] fullermd: that should be me, a couple of years ago :) Or at least many months [17:17] (running *into* problems) [17:17] fullermd: search bug number and see comments there [17:19] fullermd: bug #248427 [17:19] Launchpad bug 248427 in bzr "bzr log -r REVNO does what bzr log -c should do" [Wishlist,Fix released] https://launchpad.net/bugs/248427 [17:23] Lo-lan-do: hi! [17:23] Lo-lan-do: no, that's certainly not expected [17:23] Lo-lan-do: unless you were expecting it to rebase between the local copy and the master branch [17:23] Not really [17:24] http://pastebin.com/f643767bf [17:25] If I unbind, then rebase seems to work (in progress, but it's committed a few revs already) [17:32] But then of course I need to push --overwrite afterwards :-/ [17:32] It may (or may not) be relevant that "bound=True" is specified in my ~/.bazaar/locations.conf and that this setting seems to override any setting in the branch's branch.conf. === ja1 is now known as jam === thumper_laptop is now known as thumper === nevans1 is now known as nevans [18:36] Lo-lan-do: so where would it get the master branch? === thekorn_ is now known as thekorn [18:55] jelmer: Er, what? [18:58] Lo-lan-do: the local of the master branch a branch on your machine is bound to [18:58] Sorry, I didn't mean to sound rude. [18:58] where would it get that? [18:59] as I assume not all of your branches are bound to the same location.. [18:59] I'm confused [19:00] Could we reuse the terminology in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=520302 ? [19:00] Debian bug 520302 in bzr-rebase "bzr-rebase: Can't rebase a bound branch" [Normal,Open] === beuno_ is now known as beuno [19:28] Unrelated: I've seen quite a few commits on bzr-git recently, some of them mentioning file ids and sha checksums... does that imply that roundtripping is being worked on? [19:35] jam, hi [19:35] hi rockstar [19:35] jam, could I call you? [19:35] Lo-lan-do: I'll reply to the bug [19:35] Lo-lan-do: no, roundtripping is not something I intend to work on soon [19:36] Lo-lan-do: it's also a lot trickier with git since it doesn't have proper custom revision properties where we could stash bzr metadata [19:37] rockstar: sure, can you give me about 5 minutes? [19:37] jam, yeah. Skype? [19:39] jelmer: Thanks, and thanks. [19:39] Lo-lan-do: dpush already works to some degree though [19:39] Lo-lan-do: well, it *works* but it breaks on some branches [20:29] Peng_: so i didn't break anything for you with yesterday's landing? :) [20:39] jelmer: probably needs a flag added to bzr's test runner, its the debug() method in the test suite, and we should support it ok [20:40] jelmer: you pinged last night too? === thumper_laptop is now known as thumper === nevans1 is now known as nevans === kiko is now known as kiko-afk [21:11] i suppose it was inevitable that a thread about kB and KB and KiB would end up being not worth reading [21:12] lifeless: I might have [21:12] lifeless: but about something different then, can't remember what abour exactly [21:16] lamont: its pyrex :( [21:17]