[00:00] ok, this makes performance tolerable, just fixing this depth-of-query bug [00:14] abentley: a thought, isn't 'is_ancestor()' just 'return self.heads([ancestor, descendant]) == set([descendant])' [00:14] Could be. Haven't thought of it that way. [00:15] AFAICT it should be equally efficient [00:16] That seems right to me. [00:19] yah it is [00:19] and it exposes the bug in heads, because making it the same errors on the test that is_ancestor does not access all history [00:19] :) [01:18] hi all! i have a couple very very basic questions about bzr. [01:18] (trying to decide between bzr, darcs, and mercurial) [01:18] First of all... does bzr have any support for forests like Mercurial's Forest Extension? [01:21] work is in progress to add support for nested trees (equivalent of forests as I understand it) [01:21] superset of forests, because nested trees recurse indefinately, forests are a single construct [01:22] where is LarstiQ anyhow ? :) [01:22] Second question... how well does bzr handle binary files? [01:23] (pdfs, icky-word-processor documents, images... up to about 5mb) [01:23] lifeless: he had problems with his internet connection after his holidays [01:24] lifeless: haven't spoken to him in a couple of weeks [01:26] bbiab [01:26] jauricchio: binaries are fine [01:26] jauricchio: they can be a bit slow to diff; but other than that we just preserve them as-is. [01:28] lifeless: Does bzr diff magically avoid unchanged files? [01:28] lifeless, did you see my discussion with aaron on dirstate-with-subtree? do you think now be a good moment to encourage packs-with-subtree over packs-without-subtree? [01:28] jelmer: no, I didn't. [01:29] jauricchio: what do you mean? If you mean, do unchanged binaries make 'bzr st' and 'bzr diff' slow - no they don't [01:29] Yeah that was the question. [01:30] So slowness is only incurred when the file is actually changed [01:30] that's good :) [01:30] if you touch the file we sha it [01:30] if the sha is different we will diff it [01:30] (roughly). There are some tweaks in different circumstances. [01:30] makes sense. [01:31] Workflow question. Let's say I'm a developer working on multiple features for a release of a projects. So I make a branch of our most recent version to record my changes that will go into the next release. Now let's say I've got 5 features I'm adding. I get them done, commit them all locally, but then let's say a feature gets pulled. Is there a way to identify code belonging to a feature so that it can be easily added/removed without creating a b [01:32] Vantage13: your sentence is being truncated [01:32] Vantage13: 'without creating a b [01:33] 10:32 < l [01:33] ' [01:33] without creating a branch for every feature? [01:35] or how do people usually handle this scenario? [01:35] I think you wanted to create a branch for every feature. Branches are cheap. :) [01:36] jauricchio: branches are, but working trees are not. Currently our code base is about 2GB, so 5 working trees would be 10GB of space per developer... [01:36] Hm... fair enough. (That's a *lot* of code, man...) [01:37] Darcs would call this a "spontaneous branch". Prefix your commit messages with something, and you can work with 'all patches prefixed with (matching) some text' [01:38] Vantage13: there is a 'switch' command in bzrtools [01:38] the one thing I thought might deal with this would be using a shared repo and doing a bzr switch for each feature. So switch to main version, branch feature1, commit, switch back to main version, branch feature2, commit, switch back, etc. Then merge them all later... [01:39] Vantage13: this lets you transform a working tree from branch A to branch B quite cheaply [01:39] lifeless: exactly what I was thinking [01:39] lifeless: does what I described sound right? [01:41] yup [01:42] lifeless: Is there a way to 'switch' and create a branch at the same time? e.g. switch back to main after feature1, then create a branch for feature2 in the same working tree, then switch to it? (to avoid having to create a second working tree at all) [01:47] Vantage13: why would you create a second working tree? [01:48] lifeless: I wouldn't want to. I'd just want to create a branch and switch to it from my current working tree (which would be on the main branch) [01:48] lifeless: I'm wondering if I can do that without creating another working tree [01:48] Vantage13: 'bzr branch main new-branch && bzr switch new-branch' [01:48] won't create a working tree unless your repository is configured to make a working tree [01:49] so just disable creating working trees [01:49] lifeless: ah... [01:51] So, another question. Suppose I have a directory within a repo. I'd like to pull it out of the repo with all changes applicable to it, and make a new repo containing only it. With leading pathnames removed. [01:52] That is, projects is my repo. I want to take projects/foo/baz and make a new repo containing the contents of baz with all history. [01:52] With baz as the top level of the new repo [02:00] jauricchio: I think "hg transplant" could do that (or at least do the reverse, moving baz into project/foo), but I'm not sure if it preserves cset IDs. [02:00] jauricchio: I don't know of a way for bzr. [02:01] It's okay if cset IDs are lost [02:01] My use case is, I've been working on this little baby project that didn't deserve its own repo. Then I decide it does and I want to share it with the world. [02:04] Peng: answering questions here with 'hg can do X' isn't exactly helpful. [02:04] jauricchio: 'bzr split' can do that [02:05] lifeless: /me checks docs [02:05] lifeless: Heh, sorry. :P [02:05] Peng: You're more than welcome to say things like 'packs at 10% faster for me, but you're still 40% slower'. Thats extremely useful to know. [02:06] lifeless: 'split' not found in the user reference at doc.bazaar-vcs.org [02:06] jauricchio: 'bzr help split'. [02:06] not installed currently :\ [02:06] ah. Well then. We have the feature. [02:06] :) cool [02:07] and naturally we're expanding on it and improving it as time goes by. [02:07] of course [02:09] ok, thanks for your help lifeless, Peng, and jelmer. bzr looks to be what i need! [02:09] bye [02:09] Cool. [02:10] Peng: speaking of which, are you still dogfooding packs from time to time ? [02:12] jelmer: so do you mean bug 131667 ? [02:12] Launchpad bug 131667 in bzr "--dirstate-with-subtree is documented in the man page" [Medium,Fix committed] https://launchpad.net/bugs/131667 [02:12] yes [02:13] I would love someone to sit down and take on the patch [02:13] larstiq was working on it but hes disappeared [02:13] the patch to make nested-by-reference trees robust [02:13] lifeless, hi, so to check that plan: [02:13] this is what is needed to make -subtrees a default format and trigger the format bump [02:13] - make new knit repo containing bzr.dev [02:13] - reconcile that. [02:13] - make a new pack repo [02:14] - pull bzr.dev from the first repo [02:14] - pull packs branch [02:14] (or bzr upgrade --experimental in the reconciled repo) [02:14] but yes, thats the right list [02:19] lifeless: I keep a copy of bzr.dev and repository in pack format and pull and diff frequently, but that's the extent of my dogfooding. [02:20] ok [02:20] FWIW, I never reconciled it. [02:20] did you try the C sequence matcher thing ? [02:20] which speeds up diff, and would AIUI make your home dir versioning tolerable or even pleasant [02:22] lifeless: I switched it over to hg before I found out about that, and I've never gotten around to trying it. [02:22] Hmm. I could right now, but Firefox is hogging so much RAM it wouldn't be remotely accurate. [02:22] thats fine, don't worry about it [02:25] Mozilla should pay me for all the RAM upgrades I have to do for Firefox. [02:25] less tabs++ :) [02:25] Yeah. [02:25] Less Flash++ too. [02:25] That's what's really killing it. [02:37] poolie: how is it going ? [02:37] reconciling again [02:37] i may skip that as i'm pretty sure i did that in the same repo on friday [02:42] * Peng sighs. [02:42] switching terminals [02:43] Firefox froze right before I was going to shut it down. [02:45] :( [02:51] Hmm. I should probably just cp instead of using "bzr branch". [03:00] abentley: you're bouncing [03:08] Yes. Sorry. [03:08] Updated to gutsy, and it's giving me probs. [03:10] :( [03:12] Uh-ohs. [03:12] Branching the pack version of my homedir crashed with a KnitCorrupt error. [03:12] But I think that branch might be older than the most recent pack format. [03:13] yes, you probably have annotated knit data in it [03:13] Yeah. [03:13] Yeah, I think it might be like the very first revision it's saying is corrupt. [03:14] Or, the first file. [03:20] * Peng watches the progress bar. === kiko-fud is now known as kiko-zzz [03:24] A 700 MB .pack file. That scares me. [03:25] It was 743 MB with annotations, now it's 712. [03:29] thats cause you have a lot of data with lots of changes [03:30] Well yeah. But I'm afraid of it. [03:30] New bug: #155629 in bzr "newly-created dirstate file appears blank on curlftpfs filesystem" [Undecided,New] https://launchpad.net/bugs/155629 [03:31] One little bit out of 6 billion could be wrong. [03:32] no different to have many 10M files [03:32] lifeless: With 0.91 with Pyrex and dirstate, real time is 3m9.784s, user is 2m56.132s, sys is 0m10.781s. That might be like a 20 or 30 second improvement. [03:33] Peng: how many files are there there ? [03:33] lifeless: Uhh. A lot. [03:33] Peng: and are you committing a merge, or just a regular commit ? [03:34] Peng: and finally, had you just added new files before the commit ? [03:35] lifeless: What command tells me the total number of files? [03:35] bzr inventory | wc -l [03:36] lifeless: 4695. [03:36] lifeless: In that commit, 39 files changed. Not a merge, and no new files. [03:36] had you run bzr add? [03:37] (bzr add in 0.91 destroys the stat cache) [03:37] lifeless: Nope. [03:37] lifeless: uncommit, maybe a status or two, then commit. [03:37] thanks [03:38] thats very slow compared to my current results with packs, which is encouraging [03:38] I'm testing packs right now. [03:39] BTW, hg is like 30 seconds. ;P [03:39] yah [03:40] Also, I caught it at up to ~355 MB of RAM, and I bet it was bigger at other times. [03:40] Wow. [03:41] real 1m44.768s [03:41] user 1m37.652s [03:41] sys 0m5.437s [03:41] Packs *are* faster. [03:41] The new .pack file is 726 KB. [03:42] hmmm, not that much faster [03:42] I'd love it if you could repeat that [03:42] Just run it again? [03:42] with --lsprof-file foo.callgrind [03:42] then gzip the callgrind file and mail it to me [03:42] Gack. [03:43] this won't give me anything private [03:43] just the callgraph and timings [03:43] so I can see where the slowness is coming from [03:43] I know. [03:43] I said "Gack." because I had just started running it again. [03:43] ;) [03:44] just ctrl-C it [03:44] I did. [03:44] It'll be done shortly. [03:45] thanks! [03:45] real 2m0.958s [03:45] user 1m38.290s [03:45] sys 0m22.328s [03:45] Huh. [03:45] I would've expected user time to be higher due to lsprof. [03:47] * Peng sighs. [03:51] New bug: #155632 in bzr "KeyError: 77 in pycurl_errors.errorcode" [Undecided,New] https://launchpad.net/bugs/155632 [03:53] poolie: how goes it ? [03:53] lifeless: What's your email address? [03:59] robert at ubuntu [04:01] Blaah, you have more email addresses than I do. [04:01] ubuntu.com? [04:01] yah [04:01] lifeless, i think that's the same error i saw on friday [04:02] so [04:02] Wasn't it @canonical.com two months ago? [04:03] yes [04:03] its there too [04:03] you coulda use the prior address :) [04:06] I'll send it in a second. [04:09] Sent. [04:15] Peng: thanks [04:17] Peng: 67% is in get_content_maps [04:17] Peng: which is building up the copy of the the text to diff against [04:17] 10% in IO [04:17] we can't reduce that much [04:17] actually, 5% [04:18] 5% parsing the deltas from disk [04:19] ohfuckme [04:19] Peng: I can see an easy 17% win [04:19] we're memory copying stuff we don't need to, because of a general 'get many versions' function [04:20] Peng: if you look at bzrlib/knit.py [04:20] Peng: the function get_content_maps [04:20] New bug: #155637 in bzr "patch confict should be an internal error" [Low,Confirmed] https://launchpad.net/bugs/155637 [04:20] see the coyp() calls in there - there are two I think. Guard them with e.g. 'if multiple_versions:' [04:21] and at the top of the function do [04:21] multiple_versions = 1 != len(version_ids) [04:21] this should save 17% trivially. [04:24] lifeless: Cool. [04:24] Hold on. [04:25] lifeless: _get_content_maps? [04:26] yah [04:26] line 1000 in my knit.py [04:27] Exactly 1000? [04:27] Anyway, done. [04:28] lifeless: Want a new callgrind file? [04:30] nah, just run it without callgrind and see if it helps [04:30] Well, I ran it with callgrind and it helped. [04:30] Uhm. [04:30] 56 seconds vs. 1m38s. [04:31] great [04:31] Yeah. [04:31] theres another win of the same size in _apply_delta [04:31] in the same file [04:31] will be a little more tricky to fix that without leading to bugs [04:31] I'll do both today though [04:32] I helped make Bazaar faster. Cool. [04:33] yup [04:36] Well, I'd be happy to re-run it in the future if you ever want me to. [04:36] tomorrow probably ;) [04:36] and thanks [04:37] Heh, okay. [05:15] * ig1 food [05:52] lifeless, ping? [05:53] hi [05:54] so lifeless, 3 patches today (so far) - what order do you want them reviewed in if any? [05:55] don't care about order [05:55] just about completeness [05:55] FIFO is fine [05:55] and probably best [05:55] ok - I'll start with the tests one now [05:55] oh that one can be ignored [05:55] leave it till later [05:56] that's why I asked :-) [05:56] graph.heads then === AnMaster_ is now known as AnMaster [06:36] i've turned my check-knits branch into a plugin [06:37] it's faster than a full check (because it does less) [06:37] it may be useful [06:40] ig1: how is the review going ? [06:41] getting there ... [06:41] haven't looked at the graph code before [06:41] you have an import pdb but onothing else stands out so far [06:42] s/onothing/nothing/ [06:42] do I? oh foo [06:42] in test_graph.py [06:43] also 2 lines immediately before run_heads_break_deeper ... [06:43] otherwise tests look good [07:01] is that 'merge it' [07:01] or 'I'm still thinking' ? :) [07:02] I'm still thinking - need another 20-30 minutes I think [07:13] ig1: well, next patch is up [07:14] ok - not thru yet to me - will check again soon [07:18] there it goes [07:20] Peng: 2851 [07:20] Peng: thats the revno in repository with a bugfix to remove all three list-copies. [07:22] Peng: it will also, incidentally, reduce memory pressure, but probably not much [07:58] bug 154283 [07:58] Launchpad bug 154283 in bzr "indexerror in Knit._get_components_positions pulling in pack repo" [Undecided,New] https://launchpad.net/bugs/154283 [08:12] join-branches.txt-20050309044946-f635037a889c0388^@robertc@robertcollins.net-20050919060519-f582f62146b0b458^@^@1747020^M1746789^I1747020^@ 42658896 124$ [08:12] Took the words right outta my mouth. [08:15] You have strange things in your mouth. [08:18] It's like that thing with the old lady who swallowed a fly. [08:19] lifeless: that review finally mailed - few tweaks only as best I can see [08:27] lifeless: Holy crap. With callgrind, user time went from 56 seconds last time to 19. Real time was still at 56 seconds, but Firefox is open now so everything is probably laggier. Sys time went from 23s to 21s. [08:28] lifeless: Trying again, real time is down 10s and the others are down 1 or 2. [08:36] ig1: yup, copacetic [08:36] ig1: will do tomorrow. [08:36] Peng: so is this good ? [08:37] lifeless:quikc Q [08:37] what's the idea behind the version_id param in the apply_delta API? [08:37] Peng: what is real time sitting at without callgrind ? [08:37] ig1: KnitContent objects have a version === pcapriotti_ is now known as pcapriotti [08:38] ig1: Plain ones use this for all lines; Annotated ones carry it per-line [08:38] so the parameter is to totally transform the content object from state to state [08:38] Hold on. I'm brushing my teeth. [08:39] and self_version_id only gets set for one, not the other, is therefore by design? [08:39] yes [08:39] s/self_/self._/ [08:39] ok - thanks [08:40] I'm still playing with svn-import. Does anyone know why I'd get a "server certificate verification failed" on one gutsy computer and not on another, connecting to https://docteam.ubuntu.com/repos? [08:41] check for /etc/ssl/ca-certificates.crt [08:41] if its missing run update-ca-certificates [08:41] real 0m22.511s [08:41] user 0m17.378s [08:41] sys 0m2.758s [08:41] lifeless: ^ [08:41] Peng: how does this compare to hg ? [08:41] Umm. [08:42] Very good. [08:42] well? [08:42] thanks :) [08:42] lifeless: it was present in /etc/ssl/certs/ [08:42] I ran the update anyway, no change [08:42] Last hg one I did was: [08:42] real 0m45.080s [08:42] user 0m13.716s [08:42] sys 0m2.316s [08:42] mdke: sorry yes thats the right place. Other than that I have no suggestions. [08:42] ok, thanks anyway [08:43] Peng: hmm, still need to shave off lots of user time. But I knew that [08:43] lifeless: one was executed over ssh, could that make a difference? [08:43] Bzr and hg aren't committing exactly the same data. [08:43] So it's not an entirely fair comparison. [08:43] Peng: bzr's committing less? [08:43] I don't know. [08:43] ah [08:43] so its roughly the same but not identical ? [08:43] Bzr is using two-month-old data. Since then, my IRC logs have grown larger, but I've also switched from Opera to Firefox. [08:44] Hm. [08:44] I think hg is about the same as it was two months ago. It used to take about 30 seconds, but I'm not sure if that was real or user time. [08:44] If it was real time, the extra time is just due to Firefox hogging RAM. [08:47] gnight all. [08:47] Good night. [09:02] lifeless: BTW, bzr is probably committing more changes. Bzr is doing 12 hours of changes while hg is doing 1. === Mez is now known as Mez|Away [09:10] Is it possible to pull the bzr.dev branch over the bzr protocal [09:10] All the docs point to http urls [09:18] GaryvdM, you should be able to get it from [09:18] bzr+ssh://bazaar.launchpad.net/~bzr/bzr/trunk [09:18] you need to have a launchpad account [09:18] we'll offer public bzr:// soon [09:20] Not to be a troll, but is bzr any less slow than http? [09:21] I think there are fewer round-trips, so probably. [09:22] It takes a very long time to pull changes to bzr.dev. [09:22] Of course, the one time I time it, there aren't any new changes, and it takes 3 seconds. [09:23] * Peng wanders off. [09:29] ok so it's [09:29] KnitVersionedFile(file:///home/mbp/newbzr/dest2/.bzr/repository/text%3ATestUtil.py-20050824080200-5f70140a2d938694) [09:30] bzr: ERROR: Revision {robertc@robertcollins.net-20050919044328-0205c679f3051340} not present in "". [09:34] hi all [09:34] i would like to know, whether there are any tools for viewing the bazaar content [09:34] like for subversion we have, trac, websvn etc [09:36] Morning [09:42] i would like to know, whether there are any tools for viewing the bazaar content [09:42] like for subversion we have, trac, websvn etc [09:47] indraveni, yes, look at loggerhead [09:53] indraveni: There's also a bzr plugin for Trac. [09:55] Peng: acording to http://weblogs.mozillazine.org/jst/archives/2007/02/bzr_and_different_network_prot.html bzr is faster than http [09:55] I'm going to test it now [09:55] I live in South Africa - We have slow internet connections. [10:00] bzr+ssh = 12 sec [10:00] night all [10:00] http = 8.9 [10:00] no changes in the tree on either [10:02] Peng: bzr can be faster than http; packs help with this, on knits latency sucks arse. [10:03] What I wonder is how efficient bzr's smart server is, espcially compared to hg. Hg only uses a smart server, so it must have had a lot of tweaking. With bzr, the smart server is only starting to catch on. [10:04] There is that hpss stuff. === Mez|Away is now known as Mez [11:06] New bug: #155730 in bzr "reconcile doesn't adjust knit index references to otherwise-unreferenced file revisions" [Critical,Confirmed] https://launchpad.net/bugs/155730 [11:45] On http://bazaar-vcs.org/BzrDevelopment , the Release revids have not been updated for a while [11:45] How can I find out what they are for newer releases? === Mez is now known as Mez|Away [12:00] GaryvdM: I was going to guess `bzr tags`, but somewhat astonishingly there aren't tags for releases in their 'bzr.dev' branch [12:00] Sorry, those revids are only available to Members of the Brotherhood. === Mez|Away is now known as Mez [12:01] Who does the releases? === kiko-zzz is now known as kiko [12:01] Well, the releases don't come from bzr.dev. They have their own branches. [12:01] (and bzr.dev can't have tags anyway, in its current form) [12:02] hi all: does anyone know a good method for doing "bzr pull" over an unreliable connection? [12:02] all: my connection only lasts a maximum of 12 minutes at a time, but the pull operation takes longer (because it's a big tree). [12:03] all: I'm using bzr+ssh://....... [12:03] all: I'm open to using a workaround, such as downloading the tree via HTTP, in multiple chunks. [12:04] Well, pull saves what it gets, in some granularity. So as long as it takes you less'n 12 minutes to get a single "hunk" (probably the changes or a subset of the changes to one file, with knits), each pull should move forward. [12:04] I tend to think "kill your network admin in his sleep" is a more satisfying solution, though. [12:05] fullermd: I'd like to do that to my ISP. [12:05] i think jsk would quite like to take that approach [12:05] :) [12:05] * jsk has been plotting revenge for some days now [12:05] Oh, ISP's even easier. You know they're all in one office ;) [12:05] Take off and nuke the site from orbit. It's the only way to be sure. [12:05] fullermd: :) [12:05] fullermd: (bzr.dev is not tags compatible? You guys are weird) [12:06] AfC: bzr.dev is still branch5. I think some Linux distros are still shipping 0.11, so if we updated it they couldn't access it. [12:07] Oh [12:07] It's probably about time that it would be "OK" to make that switch these days. [12:07] Well, the default format has changed to dirstate-tags. [12:07] * AfC refrains from commenting on distros that have such lame upgrade policies, although he notes down a reminder to rant about it again when giving his next conference keynote. [12:07] Hasn't been any big pressure to, though. I wouldn't be too surprised if it stayed as-is until there's been a couple releases with packs, then it gets moved there. [12:08] like, uh, dapper ? [12:08] fullermd: So you suggest the following steps: [12:08] 1. run "bzr pull --remember bzr+ssh://..." [12:08] 2. [12:08] 3. [12:08] 4. do a ^C to kill the "bzr pull" [12:08] 5. rerun "bzr pull --remember bzr+ssh://..." [12:08] 6. repeat 2 onwards... [12:08] where "..." represents the full path [12:08] Well, you'd only need the --remember once. But yeah, that's the best I've got. [12:08] The subsequent commands won't need --remember [12:08] fullermd: cool. I'll give it a try. thanks :) [12:08] * jsk resumes his plotting... [12:10] fullermd: you know, that's not the sort of environment that I would have thought about, but I am curious how the packs modality will work in the face of partial transfers. [12:11] Well, with a buttload fewer round trips, there's a good chance packs will get done sufficiently quicker that you wouldn't have to many mid-flight disconnects. [12:11]