[00:12] meep [00:12] Raw size 3461880213 [00:12] Compressed size 141152371 [00:12] Compressed size 508555 [00:13] thats the inventories from my main bzr repo [00:13] Merging with no common ancestor is not working properly for me. [00:13] Jc2k: ^ guess what the bottom compressed size is from [00:13] davidstrauss: what it is doing [00:14] lifeless: http://fourkitchens.com/blog/2009/01/17/distributed-version-control-provides-streamlined-alternative-vendor-branches [00:14] lifeless: I'm trying the commented operation, but with "bzr merge --revision=1..-1 bzr://vcs.fourkitchens.com/drupal/6" as the merge [00:14] lifeless: And I get TONS of conflicts [00:15] if you run bzr init and add in a new tree,then the files have new identity [00:16] so when you merge, and they have the same path, its a file name conflict [00:16] lifeless: how can i force a common ancestor [00:16] start from trunk rather than by doing 'bzr init' [00:16] lifeless: that's impossible. the whole point of this procedure is that you've started your own project on its own [00:16] I'm sorry if I'm not being really helpful - I'm trying to understand what your blog post is about [00:17] lifeless: i want people who have drupal projects in bazaar branches to be able to migrate to using our drupal bazaar branch for upgrades [00:18] davidstrauss: ah [00:18] lifeless: despite having no established common ancestor [00:18] so the -r x..y syntax will force an ancestor of x [00:18] lifeless: yes, but we get tons of conflicts [00:18] but the /content/ of the trees is unrelated, I would expect tons of conflicts [00:18] do you know much about bzr internals? [00:19] lifeless: not for content IDs [00:19] ok, very quick primer so my answers will make sense to you [00:19] hi, quick question, does bzr track file permissions? [00:19] m4v: execute bit only [00:19] only execute [00:19] lifeless: is there a way to force bazaar to understand that file name match = content match? [00:19] m4v: see etckeeper for tracking full permissions, which supports bzr [00:20] davidstrauss: each object that bzr is managing has a path and a fileid. The fileid is the globally unique ID for the object [00:20] lifeless: I can see that now, but that doesn't really make it possible to efficiently merge without common ancestry [00:21] lifeless: I mean, there *has* to be a way to merge efficiently without common ancestry [00:21] davidstrauss: this is a 1:1 relationship in any tree - 1 path, 1 id. [00:21] davidstrauss: over time you can get many different paths having the same id - when things are renamed and so on [00:21] davidstrauss: so, to do a merge with an unrelated tree [00:22] davidstrauss: such that future merges can be no-brainers [00:22] davidstrauss: you have to replace the fileid of *every* file that is in the source tree and in the target tree, with the fileid from the sourcetree [00:22] lifeless: is there a way to do that automatically? [00:23] then you have to do a merge across the two file ids using the specified base, or else the old fileids local changes wil be lost [00:23] lifeless: Is there a way to do that branch-wide? [00:23] you need to identify the common revision in both branches as well [00:24] lifeless: alright [00:24] davidstrauss: so - thats what needs to happen. The bad news is that noone (to the best of my knowledge) has written this code up [00:24] lifeless: identifying the common revision in both branches is already part of my procedure [00:24] davidstrauss: yes, but there is no way to tell bzr at the moment, you only manage to tell it 3 of the 4 coordinates needed [00:25] lifeless: so is there an efficient way to resolve the conflicts? [00:25] vila: I managed to get qbzr to use CLIUIFactory rather than TextUIFactory. [00:26] davidstrauss: it is scriptable in python [00:26] lifeless: has it been scripted? [00:26] davidstrauss: in fact, writing a custom conflict resolver could do it during the merge to make it seamless [00:26] 11:21 < lifeless> davidstrauss: so - thats what needs to happen. The bad news is that noone (to the best of my knowledge) has written this code up [00:27] lifeless: what would the custom conflict resolver look like? [00:28] lifeless: would it be in python or a shell command? [00:31] davidstrauss: I think it would be a subclass of bzrlib.merge.Merge3Merger, though I haven't written a custom one myself [00:32] http://paste.ubuntu.com/106710/ <- knit vs gc compression [00:33] short story, 141MB to 0.5MB, but 10 times slower at extraction, at the moment [00:36] lifeless: what is gc compression? [00:39] davidstrauss: its a new delta compression I'm evaluation for bzr [00:44] lifeless: is there a way to specify an external merge tool that runs in the shell? [00:44] I think the extmerge plugin does this [00:44] note though that I don't think it will handle the file id changing that you need [00:44] ok [00:44] fundamentally this needs code written to support it [00:47] lifeless: I think this is one area git's architecture shines. [00:47] apparently [00:47] well its certainly simpler there, for git or hg [00:48] its the inode abstraction that makes it complex to handle parallel imports [00:48] I encourage you to file a bug, this is something we should put a canned answer to in the core [00:48] ok [00:49] for now, people that want to move onto your branch would be best served by: [00:49] - pull your branch [00:49] lifeless: would that handle the file ID mismatches? [00:49] - apply their local changes as a plain patch (bzr diff -r x..y | bzr patch) [00:49] ok [00:49] commit that patch [00:50] then they are descendants of your branches [00:50] lifeless: so, basically, start fresh [00:50] yes [00:50] lifeless: this seems similar to when you bzr bind after divergence [00:52] gc is faster at compression, sweet [00:55] we have a gc? [00:57] lifeless: https://bugs.launchpad.net/bzr/+bug/318620 [00:57] Launchpad bug 318620 in bzr "When merging two branches without common ancestry, Bazaar provides no means to map file IDs" [Undecided,New] [00:58] jelmer: groupcompress [00:58] davidstrauss: thank you [01:07] What do you guys think about merging a number of revisions that are currently the tip of your mainline, with an older revision, just for the sake of grouping them together? [01:08] I think I better pastebin a dag to explain this.. [01:10] garyvdm: you can do it if you want [01:10] it just makes it look like a merge of a branch [01:12] Here is my dag just to make sure we are on the same wave length: http://pastebin.com/d23836559 [01:14] lifeless, ah, that makes more sense (-: [01:18] jelmer: bzr-svn is working well for me these days, btw. [01:18] spiv, cool [01:18] jelmer: the current 0.5 tip seems to be quite reliable at pulling from python's and twisted's repos. [01:19] jelmer: I have some hackery to submit to make it import faster, though :) [01:19] (e.g. don't import subertpy all the time, etc) [01:19] jelmer: it even does find_tags at a bearable speed now :) [01:20] spiv, patches for import improvements are more than welcome [01:50] hi ho [01:50] I just went bzr init, and bzr stat [01:50] and got a traceback [01:50] is this a known bug? [01:50] bzr: ERROR: exceptions.TypeError: run() got an unexpected keyword argument 'verbose' [01:51] thumper, do you have loom installed? [01:51] thumper, I think you need a newer version of loom [01:51] plugin installed, yes [01:51] using it, no [01:51] it wraps bzr status but doesn't cope with a new argument that has been added to status [01:51] even if you're not using it [01:52] :( [01:53] the last revision of the loom trunk fixes it [01:53] WTF? [01:53] :-( [01:54] bzr log --line -r-10..-1 now gives be non-mainline messages [01:54] this is very new [01:55] and I can't go --line --short, as that doesn't work [01:55] yeah, I can confirm that has changed since 1.11 [01:56] can we change it back? [01:56] it is really annoying [01:57] I'm not sure it's intentional or a regression that is a side-effect of the recent work on log [01:57] I don't think it is intentional [01:57] probably worth filing a bug about [01:58] igc: my log --line now shows non-mainline revisions [02:02] jam: are you around by chance? [02:15] thumper: I thought jam has sent a quick fix to pqm for that but it looks like he hasn't [02:15] I'll do it now [02:28] igc: that'd be grand [02:29] thumper: in the pqm queue now [02:29] * igc lunch [02:29] igc: fantastic [03:08] thumper: try bzr.dev now and let me know if it's still broken [03:08] igc: ok [03:08] oops, 700 unread emails on the bzr list [03:30] hello all [03:30] I am maintaining a Trac with some modifications (my.desktopdoctorsinc.com) using a Bazaar branch. I'm in the process of rebuilding it with upstreamable changes (~30% of the code) separated out. I've built a bzr-loom with 7 patches so far, mostly non-interdependent, and can probably get a few more into upstreamable state. I tend to merge upstream at new releases, the changes are typically larger than the total of all changes in my [03:30] branch, and there are usually 2-3 conflicts. Question is, would I be better off sticking with loom, or keeping separate ordinary branches for these changes? [03:35] either is fine [03:52] igc: lp:bzr is a few revs behind by the look of it [03:54] thumper: it's 3 hours behind, on average ;) [03:55] spiv: funny man [03:55] so when is bzr going to host trunk on LP? [03:58] http://bazaar.launchpad.net/~lifeless/+junk/bzr-compressbench [04:52] goooood morning [05:32] hello pygi [05:47] poolie, :) [05:47] chapter 1 coming to your address this week :) [06:23] lifeless: http://fourkitchens.com/blog/2009/01/19/creating-common-branch-ancestry-hard-problem === aumontabe is now known as abeaumont [07:35] hi all [08:03] hi vila [08:36] What is the status of nested trees? [08:37] They're full of birds? [08:39] davidstrauss: they aren't there yet. interest is being renewed though. [08:39] jml: The Drupal project is very interested in getting this support stable. [08:39] jml: So we can effectively consider Bazaar for module development on Drupal.org [08:39] jml: like, very interested :) [08:41] * fullermd frowns. [08:42] NEWS is looking a little odd. [08:42] sdboyer, davidstrauss: I *think* abentley intends to work on it very soon. [08:42] but I couldn't say for sure. [08:43] poolie: It looks like r3940 spuriously added a whole separate section on top of NEWS [08:46] jml: well, our timeframe for making a vcs switch is anything but clear, but nested trees would be a _huge_ deal for us, so if part of the hold-up is having a really rigorous use case to put the code through, that's something we can provide [08:46] sdboyer: cool :) [08:49] can't https://launchpad.net/bzr-scmproj be used as an alternative? [08:50] maybe! [08:50] * jml doesn't know anything about it. [09:02] * igc dinner [09:03] bzr-scmproj looks kind of clunky [09:29] davidstrauss: it's trying to do it in a kind of minimal but useful way [09:31] luks: Looks like gary merged a conflict in qbzr trunk, just deleting it seems enough though [10:10] hello vila [10:10] hey ! [10:19] poolie: Did you catch my above? [10:28] about news, or about nested trees? [10:28] i saw both [10:28] i'm making 1.11final tonight, and then will merge back and fix the news [10:28] * fullermd nods. [10:28] Just making sure IRC didn't eat it :) [10:29] * davidstrauss smiles in anticipation of 1.11 [10:30] Shucks, that means I have to update the port... === asac_ is now known as asac [10:43] sdboyer, davidstrauss: yeah, that would help [10:43] :-0 [10:43] :-) [10:43] * LarstiQ thinks he may need to rethink the current approach [10:46] LarstiQ: great, we should definitely talk, then. cept probably not at 5am my time :) [10:46] sdboyer: k, I'm in utc+1/+# [10:46] 3 [10:46] sdboyer: It's the same time here [10:46] sdboyer: currently in .nl [10:47] and some of my time in .fi [10:47] Heck, it'll be that time here in about 15 minutes ;p [10:47] I think Drupal could survive without nested branch support by simply having checkouts for each module. It's just not as elegant. [10:48] * LarstiQ nods [10:48] sure. my interest in having nested branches really working prior to us beginning our coding work is that i'd rather do it all in one fell swoop [10:49] * sdboyer is wary that delaying a piece like that until later could very well mean that by the time nested branches are ready, our coders have found other itches to scratch :) [10:50] not essential for implementation, but probably wise. [10:50] however, unlike davidstrauss, who has been talking about needing to go to bed for two hours, i actually AM going to bed :P [10:50] A lot of things are easier to setup than to re-setup.. [10:51] * sdboyer agrees with fullermd wholeheartedly [10:51] * sdboyer waves g'night [11:06] poolie: the only other moves on nested trees has been scmproj, right? [11:10] i think so [11:16] hmkay [11:17] poolie: and/but there is still interest in getting it done? [11:17] (well, I know I'd _like_ to have it, but progress has been meh) [11:18] Oh god. Now that bzr-svn can finally handle a certain pair of branches, bzr-search can't! [11:18] lifeless: ping [11:39] LarstiQ: interested in working on it? [11:39] i heard you had a branch that fixed some subtrees bugs? [11:43] poolie: I have a couple of small fixes. From time to time I try to merge bzr.dev, but with the 100k diffs, it's not the easiest thing to do and not very motivating [11:43] * LarstiQ needs to put more regular time into it to move it forward [11:44] poolie: I'd very much like to get this moving somehow, yes. [11:44] hm [11:44] well, send them up and hopefully we can gradually reduce the problems [11:44] do they fix failures when a subtree format is the default? [11:45] they fix failures on subtree formats, I don't know about specifically that being the default, but with bugs in the usage of subtrees, it's not ready for that yet anyhow [11:48] i'm just wondering what tests you added to get failures [11:48] or what you changed [11:48] since the trunk test suite does not fail, it's presumably not testing everything [11:49] poolie: right, lp:~larstiq/bzr/nested-trees is a continuation from Aaron's branch [11:50] poolie: which is, afaik, the only place where work on by-reference trees is [11:53] poolie: and by reference is I think where the brunt of the usecases are [11:57] lifeless: omg is that groupcompress!?!?! [11:58] pretty amazing :-) [12:03] * LarstiQ goes to lunch [12:06] hello jc2k, james_w [12:06] hi poolie === poolie changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org | please test case-insensitivity in 1.11 (released 19 Jan) | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/ [12:06] hi poolie [12:08] Whee [12:17] I can't seem to find a description of this "groupcompress" thingy that everyone seems to happy about. Any pointer? [12:18] Lo-lan-do: I don't think so. It's a new compression strategy for storage of texts inside packs (or anything else really) [12:19] it's a different way of doing deltas than what is currently used, which gives a large compression win, but has trade-offs in other areas [12:19] Okay. So smaller repository sizes, I guess? [12:19] currently decompression time, and I imagine annotation time, but that may not change as packs already damaged that [12:20] yes, *massively* smaller in the current implementation [12:20] A new storage format too, I suppose. Will it be compatible with the current ones? [12:21] but that is at a cost of a 200% increase in decompression time, which is unacceptable in my opinion [12:21] Um, yeah, sounds not-very-nice indeed. [12:21] yeah, it's just a change in the internal compression, so it will be a new format, but not a watershed one or anything. [12:21] Can throwing more Pyrex/C at the problem improve decompression time? [12:21] (I guess not if it's all in zlib.) [12:21] perhaps [12:22] first thing will be to try limiting the delta chains. That will lose some of the win in terms of compression, but may still lead to a better overall format [12:22] it's currently only for inventory data [12:23] so the point is to speed up commit and extraction [12:23] ah, I thought it was texts too [12:23] the decompression time is something that still needs to be solved before we go ahead with ti [12:23] it could be applicable [12:23] yeah [12:23] is there any plan to move away from XML inventories? [12:23] to file texts too [12:24] however, for reasons i don't want to go into right now, it has some troubles with big files [12:24] ie it'll store too many full texts [12:24] (well, arguably too many) [12:24] Lo-lan-do: it'll be backward/forward compatible [12:25] in the usual way [12:28] Thanks [13:26] hello [13:28] I thought it was possible to do a partial checkout of a bzr branch. I would like to create a branch with only a subfolder ot the complete bzr repository. [13:28] Is it possible ? [13:29] it isn't [13:33] Thank you for the confirmation [13:33] yml, you should, however, be able to export a directory [13:35] beuno: how would you do this ? [13:35] I mean my branch is hosted on launchpad [13:37] yml, ah. I guess you can only do that with local branches === kiko-afk is now known as kiko [13:49] night all [13:55] beuno: I see. Thank you for your help [13:56] g'night igc [13:56] I will create a symbolic link to put the folder in my pythonpath [13:57] Help! Bzr is, all of a sudden, acting bizarrely. It started reporting changed files, but bzr diff gives nothing and bzr commit said "useless commit" I tried installing bzr 1.11 and 1.10 with no improvement. [13:58] I just tried bzr branch bzr/1.10 from c:\ (I'm using XP) and bzr appeared to install, but now I see no installed folder. [14:00] BTW, "changed" files happen just after a fresh bzr branch. Is there a cache that should be cleared? [14:01] you dont do bzr branch bzr/1.10 to install a new version.. [14:03] Jc2k. True, I installed bzr 1.10 from a downloaded zip file. But I wanted to use bzr to grab bzr sources, and that appeared to work. [14:03] does the output of bzr status say "unknown:" and then a list of file? [14:04] No. bzr status says modified. The actual file appears random, but compares binary equal to the file in other branches. [14:05] how odd [14:05] By "appears random" I mean the actual file that is reported varies from time to time, or rather, from branch to branch. [14:05] Yes! Odd indeed. [14:06] i had some weirdness moving branches between linux, flash drive and windows but this was over a year ago [14:07] At first I suspected bad memory. But the oddness happens on all branches. Maybe a bit got flipped in a central .bzr folder? [14:08] not really sure, im not a dev and what bits of the code i know are related to the workingtree stuff [14:08] *arent [14:10] I wonder. Does a fresh install change C:\Documents and Settings\HP_Administrator\.bzr ? I suspect not. Any reason not to trash this? [14:14] Is there a trouble-shooting guide or FAQ? [14:34] Hi guys. I'm wondering how to push my tags to the main branch in LP without doing another revision. [14:35] i can't appear to push because pushing requires a new revision [14:48] superm1: Push will push tags even if there are no new revisions. [14:48] Peng_, is that only with newer versions of bzr? I'm on hardy, so 1.3.1-1ubuntu0.1 [14:49] superm1: I'm not sure, how did you verify that the tags hadn't been pushed? [14:50] superm1: I don't think it's a new feature. [14:50] james_w, i pulled from another computer that's regularly been pulling from that same branch [14:50] ah, ok [14:50] it's probably just broken then, I don't remember it changing [14:52] okay, well surely i'll be doing another revision at some point from this branch then. the tags will get pushed up at that time at least [14:52] WFM in bzr.dev. [14:52] superm1: Does the LP branch support tags? [14:52] superm1: Does it have any tags currently? [14:53] Peng_, oh you know what, i just tried to pull again and i *did* get the tag this time. it must have committed but there was just a delay before it was available [14:53] Oh. [14:53] sorry for the chatter james_w and Peng_ but thanks for helping indicate that it should be working :) [14:54] superm1: If you're pulling from http://bazaar.launchpad.net/, there might be a (short) delay, yeah. There isn't one for bzr+ssh or sftp. [14:54] Peng_, yeah i was pulling from http on the other computer, so that would explain it [14:54] glad to know it works :-) [14:55] there's a bug open about it not telling you what it's done [14:55] "No revisions to push" should be extended to mention that it pushed some tags [14:55] yeah that would be useful [15:03] james_w: Hi [15:03] james_w: Are you aware of any guides about using bzr-loom as alternative to quilt/dpatch for Debian packaging? [15:04] jelmer: I'm not [15:10] beuno, mwhudson: similar to https://bugs.edge.launchpad.net/loggerhead/+bug/260547 when I try to run serve-branches proxied by an ssl apache site, links to ../changes or ../annotate drop back to http [15:10] Launchpad bug 260547 in loggerhead "start-loggerhead script doesn't properly set the wsgi.url_scheme from the server.webpath option" [Medium,Triaged] [15:11] hi, is there any quick way to branch lp:bzr instead of std bzr branch lp:bzr ? [15:11] beuno, mwhudson: should I make a new bug, comment on that one, fix it if it is easy to do? [15:11] it never gets finished for me :( [15:11] bvk: your two alternatives are the same? [15:11] LarstiQ, fix it is always the first option :) [15:11] if not, I think a comment on the bug is useful [15:11] beuno: it is an area I'm rather unfamiliar with [15:11] but I'll have a go [15:12] beuno: any hints on where to start looking? [15:12] bvk, if you mean an alternative URL, try http://bazaar-vcs.org/bzr/bzr.dev [15:13] LarstiQ, jelmer: no, i am looking for any tarbal with repository. is such a thing available anywhere? [15:13] bvk: specifically to get one copy of bzr.dev? I could generate a tarball for you [15:13] I'm curious though as to why branching lp:bzr doesn't work for you [15:13] LarstiQ, jelmer: no, i tried both urls, lp:bzr and http://.../bzr.dev :-( but both timeout from my computer always :( [15:13] bvk: or do you mean, for a given launchpad branch, does it support downloading a snapshot tarball? [15:14] LarstiQ: yes, that would be of great; thanks [15:15] LarstiQ: no, my problem is 'bzr branch lp:bzr' always timesout and doesn't get finish. its too slow [15:15] bvk: ok, it would be good to solve that if possible, but a tarball is coming up for you [15:17] LarstiQ: thanks LarstiQ [15:17] bvk: http://richtlijn.be/~larstiq/bzr.dev-20090119.tar.gz [15:17] bvk: that is my ~/src/bzr/bzr.dev as of now [15:17] bvk: the file is ~5M, if that is too big, I can make a tarball of it after a `remove-tree` [15:18] you would then have to `bzr co .` after unpacking and cding === kiko is now known as kiko-fud [15:19] LarstiQ: 5MB is fine, i can easily download that. [15:22] LarstiQ: Is the branch with full history is of only 5MB? Then why was bzr took more than half hour and still didn't complete :( [15:23] I think LarstiQ left out the repo. [15:23] hmm, good point, I recall it being 40~ ish [15:24] well, i was looking for a branch with full history :( [15:24] bvk: it does seem to be so [15:25] btw, is there any way to make a branch with partial history? say, like 50 days history? [15:25] meh, still not looking at the right place [15:25] bvk: No, there's not. [15:25] bvk: --stacked might help you [15:25] though it does not do it like that [15:25] * Peng_ watches bzip2. [15:27] bvk: http://cheezum.mattnordhoff.com/tmp/bzr.dev.r3945.tar -- it's almost 100 MB, and you'll have to run "bzr co .". [15:28] Ehh, http://cheezum.mattnordhoff.com/tmp/bzr.dev.r3945.tar.bz2 saves about 10 MB. [15:28] hth do I end up with a working standalonish branch but it's .bzr/repository is empty [15:29] .bzr/repository exists but is empty? [15:29] Maybe it's a stacked branch? [15:29] yeah, it is... [15:30] bvk: well. That explains why it is so small. [15:30] and why logging all took longer than expected [15:30] http://cheezum.mattnordhoff.com/tmp/bzr.dev.r3945.tar.gz saves almost as much as the bzip2 version, and I'm going to stop now. [15:31] Thank goodness I don't have p7zip, lrzip and lzma on that machine. ;) [15:31] :) [15:31] nullzip? ;) [15:32] "bzr branch"'s new progress bars are neat. Reminds me a bit of all the info git gives, only prettier. ;) [15:32] bvk: if you do continue downloading my tarball, you should end up with a stacked bzr.devc [15:32] okay, i just found out that i was using bazaar 1.5, where as latest one is at 1.11 [15:32] bvk: Ok, but 1.5 should work fine. [15:33] Well, it'll probably be slower and use more RAM than 1.11, but it'll *work*. [15:35] i just did 'bzr co .' in LarstiQ's 5MB tree and i got 'Bazaar Branch Format 7 (needs bzr 1.6)\n' :-( [15:35] i will upgrade my bzr and will try 'bzr branch lp:bzr' again [15:36] Well, 1.5 can branch from lp:bzr fine. [15:36] Or http://bazaar-vcs.org/bzr/bzr.dev/ [15:37] Peng_: my problem is that it takes too much time. I waited for half an hour and it didn't finish [15:37] Cool, lzma saves close to 20 MB, and that wasn't with the best compression. [15:38] bvk: You can't wait half an hour? What kind of Internet connection and computer do you have? Not some Pentium II on dial-up, right? [15:38] Ohnoes, bzr.dev has a new revision. Now my tarballs are out-of-date. :P [15:39] Peng_: mine is macbook with 256Kbps internet [15:39] bvk: 256 Kbps? Yeah, that could do it... [15:41] ...It'd take you a long time to download 100 MB, wouldn't it? [15:42] bvk: my tarball should give you a workingtree of bzr.dev at a recent revision, plus .bzr/ bits to act as a stacked bzr branch [15:42] Peng_: true...but its UI always made me think it hung and i would endup either killing it in the middle (impatient :D) [15:43] bvk: so if you extrac that, you can run the bzr _in there_ to branch with [15:43] just run path/to/extracted/bzr.dev/bzr branch ... [15:43] I usually try a "watch du -hs .bzr" when I wonder if it's stuck. [15:43] bvk: Well, it probably wasn't hung. And the next version (not today's 1.11) should have much a much more active progress bar when branching. [15:43] Lo-lan-do: did you see the progress indication that's not in 1.11? [15:44] Lo-lan-do: it succeeds in subjectively making me feel it's waaaay faster [15:44] Lo-lan-do: achieved by actually giving information :) [15:44] LarstiQ: I've grown used to just switching to another virtual desktop for a while :-) [15:45] Hmm, it's kind of creepy that the server lets me monitor how far along bvk's download is, and how fast it's going. [15:45] Lo-lan-do: You should try it. It's very nice. It gives a running count of the revisions downloaded. [15:46] Lo-lan-do: I picked up that skill when I was on cable. 8kbs up/down combined. Cable modem attached via serial to the pc. Best idea EVAR [15:48] Peng: I'm switching back and forth between 1.5 and 1.11rc1 these days, actually. [15:48] Lo-lan-do: 1.11 final is out. :D [15:49] 1.11rc1 seems nice, but the corresponding bzr-svn version takes half an hour for every operation I do on a branch bound to a remote SVN repo, so I often downgrade back to a version that "only" takes four minutes. [15:49] Not in Debian yet => it doesn't exist :-) [15:50] (I keep pestering jelmer about it, but I also try not to burn him out) === Spaz is now known as Kittens [15:53] Lo-lan-do: :-) [15:53] Lo-lan-do, I'm trying to get 0.5rc2 out today, hopefully I can have another look at your performance regression after that [15:54] jelmer: I'm trying to single out a bug in svn-import, too :-) [15:54] Lo-lan-do, argh, and I just got the bug count in bzr-svn back to < 30 :-) [15:56] beuno: it looks to me like it may be a bit more complicated than trying to replicate the patch *somewhere* [15:56] jelmer: Okay. Just ping me when it's < 29 then :-D [15:56] LarstiQ, a comment on the bug about the https is fine then :) [15:57] you did install python-pastedeploy, right? [15:57] beuno: yup [15:58] beuno: and it's working fine for my http vhost === kiko-fud is now known as kiko-phone [16:11] beuno: added a comment [16:18] lifeless: is bicyclerepair completely bitrotted? [16:19] any versionedfile API experts around? [16:19] * LarstiQ hides [16:23] LarstiQ, nevermind, already found the problem [16:23] KnitCorruption caused by a text revision that has the same parent twice [16:24] Lo-lan-do, never mind me, it's actually at 27 already :-) [16:25] jelmer: Does 0.5rc2 change anything related to deleted files by any chance? [16:26] Lo-lan-do: some things - what's the error you're seeing? [16:26] bzr: ERROR: Unable to find file id for child 'editreleases.php' in 'gforge/www/project/admin' in