[12:06] lifeless: So you're saying lines are evil? [12:09] abentley: I'm saying there is a significant cost in changing representations (outside of C ?) and that we probably want to really aim for one representation end to end at some point === abentley was kidding [12:10] oh right ;) [12:11] I agree that end-to-end is a useful goal, but it's hard to imagine how to reconcile that with delta compression. [12:12] hg seem to delta on bytes [12:12] I suppose binary delta compression could work. [12:13] the C library they wrote does a line split without copying [12:13] or something [12:13] certainly they don't seem to do splitlines() during commit [12:13] I have pack commit at 3.5x hg commit, I'm trying to pull it down to < 2x [12:15] is the "atexit.register(_rmtree_temp_dir, root)" in TestCaseWithMemoryTransport still present in current bzr? [12:15] it's causing pain with the launchpad test suite === james_w_ [i=jw2328@jameswestby.net] has joined #bzr [12:16] generally, please do not use atexit for test suite cleanup... it's gross [12:16] I don't recall a patch removing that anytime recently [12:16] mind you I don't recall putting that in ;) [12:16] lifeless: I know you have better taste that that, I was broadcasting [12:17] To answer your question "whats the difference between [get_matching_blocks output] and our deltas today", get_matching_blocks doesn't produce a delta, just match regions. Knit deltas can't directly produce get_matching_blocks output (but if you have the fulltexts, then they can accelerate that). Multiparent deltas with a single parent can produce get_matching_blocks output, but with multiple parents, they can't. [12:18] get_matching_blocks is whitespace-ignoring specific right ? [12:18] No, it's generic. It's what we use for everything. [12:19] knit deltas, annotation, diff. [12:19] if we implement diff -w [12:19] or annotate -w [12:19] -w ignores whitespace so " foo = 'bar' " and " foo = 'bar'" are considered to match [12:21] I'm not quite sure what you're asking, but having pre-calculated get_matching_blocks output would allow us to dramatically reduce the regions we compare for arbitrary diffs. [12:22] Or annotate, for that matter. [12:22] presumably via composition of these regions [12:22] Yes. [12:23] I'll think about this some [12:24] It seems like we may have over-optimized "annotate". [12:24] I think we should be able to get diff performance up to where hg have it on arbitrary texts before we implement caching. [12:24] annotate - possibly yes [12:25] While it's nice to be fast, it doesn't have to be as fast as fulltext access. [12:26] And for annotate merge, you don't need annotations for most lines, and you don't need precise annotations for lines that were introduced by common ancestors. [12:26] yup [12:28] So possibly storing get_matching_blocks regions is better than caching annotations. [12:30] it would be less data for sure [12:31] do we have an uncached annotate facility still ? [12:31] or do I have to recreate it to disable the annotation cache in packs? [12:33] I thought only bzrtools did that, until we got weaves. [12:33] Anyhow, I do have the bzrtools code, but I bet it's pretty dated. [12:34] There is the reannotate code, though. [12:34] That should do the trick. [12:35] It annotates from parents to children, not from children to parents. === jml [n=jml@ppp121-44-221-92.lns1.hba1.internode.on.net] has joined #bzr [12:37] so full history ? [12:37] anyhow, we're going to need a cacheless annotate routine somewhere [12:37] Well, if you had an annotated fulltext of an ancestor, it could work from that. [12:38] And for merge purposes, you could start at a common ancestor. [12:39] But if you want the full annotation with no cache, you have to go through history anyway. [12:41] yes full history all sides [12:42] with the potential to stop early if we go from child -> parent === james_w [i=jw2328@jameswestby.net] has joined #bzr === BryceLeo [n=bryce@nj-71-48-102-108.dhcp.embarqhsd.net] has joined #bzr [12:57] anyone had a problem installing the new bzr via synaptic in ubuntu? [12:58] feisty fawn if it matters [12:59] Well, there was a problem reported this morning, but I'm unclear whether it applies to Feisty. [01:00] Does it say "error in control file: `Files' value not specified"? [01:02] yup [01:02] i think i've got a fix [01:02] yup it's super simple [01:03] let me pasebin it right quick [01:04] BryceLeo: fixed packages are already building [01:10] awesome [01:10] well i've got a patch if anyone wants it now [01:11] haha now if only you guys could fix why the python binding for gtkmozembed crashes with https [01:12] hahah [01:12] just figured out why GzipFile is _so_ slow [01:12] it overrides the default compression level for zlib [01:12] GzipFile('foo', 'wb') == gzip -9 [01:12] whoops [01:13] q: why is bzr slow [01:13] a: stdlib fuckage [01:13] Don't the docs say it uses the zlib default? [01:14] it does; but if you aren't the one choosing to use a tool, do you read the docstring? [01:14] its surprising for library bindings to differ between languages [01:15] Oh, GzipFile does say it defaults to 9. === Peng wanders off. [01:15] That doesn't explain why it's so slow for decompression, though. [01:15] I haven't looked into that yet [01:16] but changing it to the default, we're only 2 seconds slower - 38 vs 36 [01:17] Slower than raw zlib? === BryceLeo [n=bryce@nj-71-48-102-108.dhcp.embarqhsd.net] has left #bzr [] [01:22] slower than 'gzip -c mozilla.tar > /dev/null' [01:23] Ah, cool. [01:24] so I'm just testing the change in data size [01:30] Well, I'm kind of at loose ends. If there's some packs work I can do without sync problems, I'd be happy to join in. [01:31] ahha 127MB [01:31] this patch going up for review :) [01:31] abentley: getting the ability to annotate without cached annotations seems to save nearly 1/5 of our current commit time [01:32] abentley: so that would be a good thing, and seems to be unlikely to collide [01:35] 127MB is the size change? [01:39] lifeless: btw, please review my reconcile change. [01:40] Also, does your latest in "http://people.ubuntu.com/%7Erobertc/pack-repository.knits/" have no annotation? [01:42] no, I only played with that locally [01:42] 127M is the new repo size [01:42] the old repo size was 140M [01:42] so its actually smaller ;) [01:43] That makes no sense... [01:44] I'm realizing that child->parent order also matches our expected data ordering better. [01:44] === modified file 'bzrlib/repofmt/pack_repo.py' [01:44] --- bzrlib/repofmt/pack_repo.py 2007-08-28 02:18:13 +0000 [01:44] +++ bzrlib/repofmt/pack_repo.py 2007-08-30 03:44:59 +0000 [01:44] @@ -1035,7 +1035,7 @@ [01:44] self.weavestore._file_mode, [01:44] index=knit_index, [01:44] access_method=knit_access, [01:44] - **self.weavestore._versionedfile_kwargs) [01:44] + factory=knit.KnitPlainFactory()) [01:44] thats the patch to drop annotations - I haven't committed because I expect it to break tests left, right and centre [01:45] your updated reconcile patch - yes, I will review it [01:46] Okay. I will go break some tests >:) [01:48] !?! "bzr selftest annotate" and nothing breaks. [01:49] I don't think you're intelligent, ubotu, believe me. [01:51] Man, this channel is never satisfied. Tests don't pass, people complain. Tests pass, people complain... [01:51] Why are you guys so intent on changing iter_changes? The only case where it's expensive to determine whether a file has changed is when the stat value has changed, but the st_size has not. [01:55] abentley: the annotate tests are probably not strict enough then; at the repo level the API call to the knit will work [01:55] abentley: but it will annotate the entire file as changed in the last commit :( [01:56] Sounds pretty nuts. [01:56] abentley: so that when we hit that case, we don't end up e.g. sha1summing an entire iso twice [01:56] abentley: yeah, supporting annotate() on knits that don't have annotation data in them *is* nuts IMO but its what the original interface offered. === BryceLeo [n=bryce@nj-71-48-102-108.dhcp.embarqhsd.net] has joined #bzr [02:00] bbiab === mw is now known as maway === maway is now known as mw|out === beuno [n=beuno@44-111-231-201.fibertel.com.ar] has joined #bzr === poolie [n=mbp@ppp112-44.static.internode.on.net] has joined #bzr [02:07] poolie: quick call ? [02:08] sure === jml_ [n=jml@ppp108-61.static.internode.on.net] has joined #bzr === jml_ is now known as jml === welterde_ [n=welterde@trujillo.srv.pocoo.org] has joined #bzr [02:33] abentley, lifeless: what's the status of the bad parent references work? I currently have a patch that's marked "resubmit" because it doesn't take broken history like bzr.dev's into account. [02:34] spiv: robert's said he'll review my new patch. [02:34] Ah good. Are you still of the opinion that smart server fetching should compensate for this? [02:36] I think it should not fail silently. It can fail noisily or succeed silently-- your pick. [02:37] i.e. pulling from a broken repo should not silenty break my repo? [02:37] Yes. [02:37] Makes sense. === n2diy [n=darryl@wlk-barre-208-103-148-41.dynamic-dialup.coretel.net] has joined #bzr [02:42] spiv: there is a flag on the repository indicating it can suffer from this form of corruption [02:43] spiv: so if it is set you'll need to check that the knit parents match the last modified in the parent's ancestries. [02:44] this is expensive, so we may want to do a format bump just to ensure that we have a format without the flag set [02:44] abentley: ^ does this make sense to you ? [02:44] spiv: wanna quick chat ? [02:44] lifeless: yeah, that'd be good [02:44] k, I'll ring [02:44] ta [02:46] lifeless: Yes, that makes sense to me. [02:48] Hmm. Maybe it could be a supplemental flag? [02:49] Because it would still be readable by older clients. === orospakr [n=orospakr@bas11-ottawa23-1177651556.dsl.bell.ca] has joined #bzr === igc [n=igc@ppp121-45-197-71.lns1.bne1.internode.on.net] has joined #bzr [03:04] abentley: I meant a flag on the object, not on disk [03:04] abentley: thinking about it some more with spiv; we think the client can check if the delta basis is present and error if its not [03:05] I meant the format bump you were talking about. [03:05] abentley: no, I don't think it can be a supplemental flag or older clients will write to the repo too [03:05] abentley: and could then introduce this defect [03:05] Oh, drat. [03:06] igc: compression fix has landed [03:06] lifeless: excellent - just checked pqm 5 mins ago checking its progress :-) [03:07] Anyhow, I was surprised you said it was expensive to detect this, and I agree it makes sense to error on missing delta basis. [03:14] spiv: Would it make sense to provide a way to do dumb fetch? [03:16] abentley: by dumb you mean the current knit join approach ? [03:16] Yeah. [03:16] For people who can't reconcile the source repo. [03:17] But I also mean, just using the dumb transport. [03:18] But this is only likely to affect initial branches anyhow. [03:18] I think that might be reasonable but given that few people run bzr+ssh-only repo's anyhow [03:24] igc: pushed a pack repo that has the compression fix too, to my 'repository' branch. [03:25] lifeless: thanks. I'm interested in a pack repo with annotations separated next :-) [03:26] igc: I'm working on stripping annotations completely. [03:26] abentley: from knits? [03:27] From packs. [03:27] I guess I was assuming that would be a format bump and it may as well come with the pack stuff? === orospakr_ [n=orospakr@bas11-ottawa23-1177563969.dsl.bell.ca] has joined #bzr [03:27] cool [03:28] Yeah. We'll see. It may not be performant without at least caching get_matching_blocks. [03:31] But since we can extract that from our delta formats, who knows? [03:32] Stripping annotations from packs? As in 'bzr annotate'? [03:32] igc: I pasted the patch for that here [03:32] code,code,code ... measure,measure,measure ... code,code,code ... [03:33] lifeless: ok, I'll grab it later - just trying to get an options patch out right now [03:34] Peng: yes. It's a significant cost when committing large trees. We promise not to break anything. [03:34] It doesn't break anything; all the tests still pass ;) === NamNguyen [n=namnt@148.177.217.131] has joined #bzr === bac [n=bac@canonical/launchpad/bac] has joined #bzr [03:45] abentley: But will it make bzr annotate slow? [03:45] Peng: s/?/er?/ [03:45] yes [03:45] Even slower? [03:46] Yuck. [03:46] One thing I liked about bzr was speedy annotations, and now it'll be worse than hg. [03:46] I know I know, I'd be whining about slow commits if you didn't do this. :P [03:46] Why do you think it will be slower than hg? [03:47] why do you say it'll be worse than hg ? === Janzert [n=Janzert@75-134-223-54.dhcp.trcy.mi.charter.com] has joined #bzr [03:47] I don't know. [03:47] I compared it some time. [03:48] Hold on. === orospakr_ [n=orospakr@bas11-ottawa23-1177651987.dsl.bell.ca] has joined #bzr === p4tux [n=p4tux@189.169.92.184] has joined #bzr [03:55] .... [03:57] Hey, where can I get a copy of the repository branch new enough to access the repository branch? [03:59] http://people.ubuntu.com/%7Erobertc/pack-repository.knits/ ? [03:59] yup [03:59] Peng: see my dogfooding mails to the list [04:00] I didn't think that branch was up-to-date enough. [04:00] abentley: what does auto_merge.py do? === kiko-afk is now known as kiko-zzz [04:00] Peng: I've explicitly stated that I keep it up to date enough to read the other branch [04:01] Peng: its the bootstrap [04:01] Oh. [04:02] NamNguyen: It marks merge requests merged if they have been merged into the mainline. [04:02] abentley: how is that done? i looked at the code but didn't understand it much [04:03] Okay, I get it. [04:03] something to do with merge_id, is it supposed to be unique? [04:03] I need to throw out my old branch of repository, and get it again? [04:03] No, not merge_id. [04:04] First it downloads the latest version of the mainline. [04:04] Then it finds which revisions are newly part of the mainline's ancestry. [04:05] lifeless, are you going to upload a new 0.90 deb? [04:05] Actually, it just finds which revisions are part of the mainline's ancestry. [04:05] poolie: yes when I don't get md5 errors from the deb archive during build [04:05] Then it looks at the merge requests, and sees whether their head revision is in the mainline's ancestry. [04:06] Peng: Please read the mails with [PACKS] in the them on the list. [04:06] Peng: they contain all the relevant info [04:08] Blaaah. [04:09] abentley: suppose that two merge requests branched from a same revision [04:09] I don't know what you mean by "branched". [04:10] they come from a same revision [04:10] The only thing that matters is the head revision-- the newest revision in the merge request. [04:10] So you have two merge requests trying to submit exactly the same change? [04:11] different change [04:11] Where they branched from doesn't matter. [04:12] isn't the head revision the parent revision? [04:12] No. [04:12] The head revision is the youngest revision. [04:12] If the merge request has a bundle, all the other revisions in it will be ancestors of the head revision. [04:13] and when this bundle is merged, is the revision id kept unchanged? [04:14] its revision ids [04:16] Yes, revision ids are never altered. [04:18] i see, so the idea of automerge is to check all outstanding merge requests' latest revision ids to see if they are in the branch [04:19] Right. [04:22] Peng: if you've read the mail and are lost I'll happily help you [04:22] Peng: but I don't have time to simply be repeating myself sorry [04:22] lifeless: Yeah, I get it. I need to get a mail client up and running and start reading the list. :P [04:23] Peng: gmane has it [04:25] I can't get Gmane to load at the moment. [04:25] I'm reading the list on lists.ubuntu.com. [04:25] ok [04:29] Okay! [04:29] are the generated html files going to be called .htm or .html? [04:29] i thought we agreed to change it to .html? [04:30] sup [04:30] hi [04:30] Annotating a 1000-line file with 1600 revisions, user time: [04:30] bzr knits: 1.1 seconds [04:30] bzr packs: 3.6 [04:30] hg: 4.0 [04:31] Bzr 0.90 was a few msec faster than the pack version in a knit branch. :P [04:32] poolie: They're html, but no one has updated the online documentation. [04:32] igc was looking into it last I heard. [04:32] the cron job is running, but maybe it's not copying them across [04:34] poolie: the doc usually gets updated as part of the release rollout [04:35] Peng: ms differences are sampling noise [04:35] I've been meaning to ask you about where James got up to [04:35] Peng: the 3.6 seconds is due to the single text index not doing partial loads [04:36] lifeless: Will that be improved in the future? [04:36] yes [04:36] Yeah, you're right, it was just noise. [04:37] lifeless: Okies. [04:37] lifeless: But removing annotation data will make it slower .. [04:37] thats right. [04:37] but every file version has to get committed by definition === igc lunch - bbiab [04:37] only some get annotated [04:38] so we could for instance have a background task to generate an annotation cache [04:38] fire off a thread as a commit hook [04:38] Huh. [04:38] or cache different data that helps annotations as abentley mentions [04:38] lots of options [04:39] but removing 20% overhead during commit that is only sometimes used seems like a pretty good idea [04:40] Yeah, it does. [04:40] I just liked having fast annotations. :P [04:40] e.g. [04:40] if you ask for an annotation of file X, we cacn cache the results [04:40] New bug: #135770 in bzr (main) "bzr faild ti install (dup-of: 135891)" [Undecided,New] https://launchpad.net/bugs/135770 [04:41] Removing 20% overhead from commits won't change if they're "fast" or "slow", but the change will make annotating "slow" instead of "fast". [04:41] Anyway, I don't want to stop you or anything. [04:41] Just sayin'. [04:41] the way you get from slow to fast commits is by stripping overhead thats not needed [04:42] Well sure. It's a significant improvement and that's a good thing. But commits going from 1s to 0.8 is still "fast", and 10 to 8 is still "slow". [04:42] But annotating going from 1 second to 4 is "fast" to "slow". [04:43] Anyway, I'll shut up. [04:43] The change is a good idea. === michelp [n=michelp@70.103.91.130] has joined #bzr [04:43] I just hope that you'll be able to keep annotating as fast as possible! :) [04:46] lifeless: Got annotation of plain knits tested and working. Where do you want it? Technically, it could even go in bzr.dev, I guess. [04:47] abentley: bzr.dev :) [04:48] abentley: I want to keep the branch as small as possible at all times [04:48] Aw, drat. I'll hafta cherrypick. === BryceLeo [n=bryce@nj-71-48-102-108.dhcp.embarqhsd.net] has left #bzr [] === poolie [n=mbp@ppp112-44.static.internode.on.net] has joined #bzr [05:59] igc: It seems as though the path must start with 'callgrind.out', not just the basename. [06:00] in my code you mean? If so, I'll fix that [06:03] i'm looking into why the docs aren't visible [06:03] thanks poolie [06:04] they are being built; they might not be copied to the right directory, or something like that === orospakr [n=orospakr@bas11-ottawa23-1177651987.dsl.bell.ca] has joined #bzr [06:11] ok i think that's ok now [06:25] Awesome. Now we have a copy of NEWS to point people at. === Chuckie_Ice [n=chuckie_@c-76-28-232-61.hsd1.wa.comcast.net] has joined #bzr [06:27] lifeless: I've got the new annotation code using precalculated get_matching blocks everywhere possible. [06:27] abentley: you're on fire [06:27] That too. [06:27] abentley: +1 to that [06:28] But without matching blocks for the righthand parent of merges, there are still 279 calls. And that's 40% of runtime. [06:29] whats your test file, NEWS? [06:29] Yep. [06:29] revision 2000 [06:29] That still takes 13 seconds. [06:30] So I don't want to go higher. [06:31] I'm not storing any new data, just using the knit deltas to extract get_matching_blocks output. Which is why the 40%. [06:31] Because knit deltas only tell us about the left parent. [06:33] man python you suck [06:33] a$ python -m timeit 's = [] ; s.append((200, 300)); s.pop()' [06:33] 1000000 loops, best of 3: 0.874 usec per loop [06:33] $ python -m timeit 's = [] ; s.append((200, 300)); del s[-1] ' [06:33] 1000000 loops, best of 3: 0.528 usec per loop [06:33] Sheesh [06:33] $ python -m timeit 's = [] ; s.append((200, 300))' [06:33] 1000000 loops, best of 3: 0.398 usec per loop [06:34] .130 to do del s[-1] , .480 to do s.pop() [06:35] If it helps, it takes my system longer to do the pops than it takes yours to do the whole bunch :p [06:35] fullermd: do you see the same relative costs? [06:35] ~1 -> ~2.3. [06:35] Well, ~1 - ~1.25 - ~2.3. [06:36] Eyeballs similarish, yah. [06:36] copy n paste is easier :) [06:36] Little over double cost for pop, 'bout 25% more for del. Close enough. [06:39] lifeless, thanks for making a sid/gutsy repo [06:41] lifeless, poolie: I've started work on a NEWS-specific text merge, but no ETA on completion yet. [06:45] Annotating the latest version of NEWS takes 1m25.767. Eeps. [06:45] g'night. [06:50] lifeless, i think splitting the news might make it easier for people developing across releases [06:50] because their changes would not accidentally end up in a different release === gldnspud_ [n=gldnspud@72.171.93.139] has joined #bzr === Chuckie_Ice [n=chuckie_@c-76-28-232-61.hsd1.wa.comcast.net] has joined #bzr === orospakr [n=orospakr@bas11-ottawa23-1177651987.dsl.bell.ca] has joined #bzr === michelp [n=michelp@70.103.91.130] has joined #bzr === NamNguyen [n=namnt@148.177.217.131] has joined #bzr === igc [n=igc@ppp121-45-197-71.lns1.bne1.internode.on.net] has joined #bzr === n2diy [n=darryl@wlk-barre-208-103-148-41.dynamic-dialup.coretel.net] has joined #bzr === welterde_ [n=welterde@trujillo.srv.pocoo.org] has joined #bzr === jml [n=jml@ppp108-61.static.internode.on.net] has joined #bzr === beuno [n=beuno@ubuntu/member/beuno] has joined #bzr === james_w [i=jw2328@jameswestby.net] has joined #bzr === cprov [n=cprov@canonical/launchpad/cprov] has joined #bzr === sverrej [n=sverrej@tul-1x-dhcp013.studby.uio.no] has joined #bzr === Demitar [n=demitar@c-212-031-190-120.cust.broadway.se] has joined #bzr === herzel [i=herzel@gateway/tor/x-4a64597d1f5da008] has joined #bzr === Peng [n=mnordhof@fl-69-69-148-134.dyn.embarqhsd.net] has joined #bzr === asak [n=alexis@201-26-117-66.dsl.telesp.net.br] has joined #bzr === ubotu [n=ubotu@ubuntu/bot/ubotu] has joined #bzr === gldnspud [n=gldnspud@72.171.93.139] has joined #bzr === kanhaiya1kk [n=kanhaiya@freemap.in] has joined #bzr === ipkiss [i=ipkiss@nat/ecp/x-800f2584e8d354ec] has joined #bzr === BjornT [n=bjorn@canonical/launchpad/BjornT] has joined #bzr === dhon__ [n=dhon@60-240-97-109.static.tpgi.com.au] has joined #bzr === tonyyarusso [n=anthony@ubuntu/member/tonyyarusso] has joined #bzr === siretart [i=siretart@ubuntu/member/siretart] has joined #bzr === ThomasAH [n=thomas@aktaia.intevation.org] has joined #bzr === Basic_py [n=Basic@gatekeeper.real-time.com] has joined #bzr === spiv [n=andrew@canonical/launchpad/spiv] has joined #bzr === abentley [n=abentley@bas8-toronto63-1088754407.dsl.bell.ca] has joined #bzr === mwh [n=mwh@62-31-157-102.cable.ubr01.azte.blueyonder.co.uk] has joined #bzr === TFKyle [i=kyle@71-17-16-130.regn.hsdb.sasknet.sk.ca] has joined #bzr === jdong [n=jdong@ubuntu/member/jdong] has joined #bzr === abadger1999 [n=abadger1@65.78.187.68] has joined #bzr === lifeless [n=robertc@ppp245-86.static.internode.on.net] has joined #bzr === jkakar [n=jkakar@204-174-36-45.dhcp802.dsl.ucc-net.ca] has joined #bzr === NfNitLoop [i=codyc@cpe-70-112-28-217.austin.res.rr.com] has joined #bzr === MishaS [n=MishaS@a91-154-120-151.elisa-laajakaista.fi] has joined #bzr === troy_s [n=aphorism@d206-116-6-170.bchsia.telus.net] has joined #bzr === hmeland [i=29578@klodrik.uio.no] has joined #bzr === SteveA [n=steve@canonical/launchpad/SteveA] has joined #bzr === dholm [i=dholm@gentoo/developer/dholm] has joined #bzr === asak|_ [n=alexis@lnx00.cecm.usp.br] has joined #bzr === sii [n=sii@tranquillity.sii.se] has joined #bzr === taaz [n=dlehn@66.37.66.32] has joined #bzr === metze_away [n=metze@ip-217-172-181-76.mx-netz.de] has joined #bzr === [PUPPETS] Gonzo [i=gonzo@80.69.47.16] has joined #bzr === quicksilver [n=jules@212.69.38.59] has joined #bzr === Admiral_Chicago [n=FreddyM@ubuntu/member/admiral-chicago] has joined #bzr === sevrin [n=sevrin@ns1.clipsalportal.com] has joined #bzr === pete__c [n=pete@015-823-542.area5.spcsdns.net] has joined #bzr === bigdog [n=scmikes@49-66-14-216-arpa.cust.cinci.current.net] has joined #bzr === jeremyb [n=jeremy@unaffiliated/jeremyb] has joined #bzr === _logger [n=_logger@adsl-75-51-62-134.dsl.chcgil.sbcglobal.net] has joined #bzr === radix [n=radix@70.91.133.157] has joined #bzr === alla [n=alla@soy.cyber.com.au] has joined #bzr === elmo [n=james@83-216-156-21.jamest747.adsl.metronet.co.uk] has joined #bzr === dirker [n=dirker@woosome.net] has joined #bzr === johnlr2 [n=johnlr@203-206-162-97.perm.iinet.net.au] has joined #bzr === AndyP [n=andyp@ubuntu/member/welshbyte] has joined #bzr === thumper [n=tim@canonical/launchpad/thumper] has joined #bzr === fullermd [n=fullermd@adsl-072-148-013-213.sip.jan.bellsouth.net] has joined #bzr === Kinnison [n=dsilvers@spoo.flarn.net] has joined #bzr === LarstiQ [n=larstiq@cust.7.157.adsl.cistron.nl] has joined #bzr === meuh [n=meuh@pdpc/supporter/active/meuh] has joined #bzr === Theuni [n=ctheune@uter.gocept.com] has joined #bzr === scaner [n=scaner@211.100.39.250] has joined #bzr === uws [n=mathilda@scrat.hensema.net] has joined #bzr === Odd_Bloke [i=oddbloke@compsoc.sunion.warwick.ac.uk] has joined #bzr [07:02] poolie: thanks for the doc stuff. It looks good except that the 'latest' link is still pointing to some older doc? [07:02] thanks, fixed ? [07:03] poolie: yes, assuming latest means 'current release', not 'development' [07:04] latest is not clear [07:04] we do have bzr.dev for that [07:04] I'd prefer 'current' to 'latest' my self [07:04] maybe we should just get rid of that link and let people who want the latest look at bzr.dev? [07:04] that would do [07:04] 2nd thoughts ... [07:04] I'd like a 'current' link [07:05] latest was meant to mean current release [07:05] I didn't think about clarity enoug at the tome I think [07:05] it's need IMO, I just don't like the name [07:10] can someone glance at http://bundlebuggy.aaronbentley.com/request/%3C2422be180708301335x3103b2c9mbaf318e287b4cf3b@mail.gmail.com%3E [07:10] please [07:11] please :D [07:14] btw, is bundlebuggy a custom thing? it's marvelous :D [07:17] beuno: Yes, but it's open source. [07:18] Peng, aaah, well, it's a great idea/implementation [07:18] Totally. :) [07:26] poolie: that looks fine to me. I'll approve it in BB [07:30] igc, thanks [07:30] yay! does the bug close my itself in LP? === beuno guesses "no" [07:30] which bug? [07:31] the one that the patch is for, #107155 [07:31] python -m timeit '{1:2, 2:3, 3:4}' [07:31] 1000000 loops, best of 3: 0.584 usec per loop [07:31] python -m timeit 'dict(((1,2), (2,3), (3,4)))' [07:31] 100000 loops, best of 3: 2.15 usec per loop [07:32] 'bout the same ratio here. [07:33] just the inner tuple there is tuple is 0.177 [07:39] ok, bye. I need to pack [07:39] aaaaanyway, time I get some sleep, ping me if you need anything else with the patch, night all :D [07:40] beuno, i've just sent it off [07:41] poolie, great, thanks a bunch, I'll close the bug then [07:41] spiv, quick call? [07:42] poolie: sounds good. Two minutes? [07:42] sure, call me when you're ready [07:42] igc, i like custom_help() [07:43] thanks === duckx [n=Duck@tox.dyndns.org] has joined #bzr [08:08] spiv: is http://bundlebuggy.aaronbentley.com/request/%3C20070826091222.GC11127@steerpike.home.puzzling.org%3E merged into the bzr.dev yet? [08:09] igc, would you like a catchup call? when were you going to finish today? === asak| [n=alexis@lnx00.cecm.usp.br] has joined #bzr [08:09] igc: not yet, thanks for the reminder. [08:10] poolie: don't mind either way. Need to wrap up around 6 tonight [08:10] ok, can we talk about 5:30? [08:10] sure [08:10] cool [08:10] i'm stepping out for a bit [08:11] poolie: before you go ... [08:11] I'm about to do some reviews [08:11] any preferences for which ones? === aadis [n=aaditya@122.167.216.213] has joined #bzr [08:16] not in particular, though i do think doing some is a good idea [08:16] i'm just doing yours [08:17] ok - I'll do the --change one from Lucas and the pre-commit hook one === allenap [n=allenap@212.233.37.68] has joined #bzr === g0ph3r [n=g0ph3r@p57A0A9A7.dip0.t-ipconnect.de] has joined #bzr === sabdfl [n=sabdfl@ubuntu/member/pdpc.silver.sabdfl] has joined #bzr === mlh [n=mlh@c211-30-211-232.belrs1.nsw.optusnet.com.au] has joined #bzr === ddaa [n=david@canonical/launchpad/ddaa] has joined #bzr === dato [n=adeodato@84.120.252.50.dyn.user.ono.com] has joined #bzr === Zindar [n=erik@h188n1fls12o803.telia.com] has joined #bzr [09:32] igc, thanks for reviewing the patch for pre_commit hook [09:32] does a commit to CommitBuilder actually commits anything? [09:33] or does it only flag that a commit is done, ready to be flushed out to disk === sverrej_ [n=sverrej@tul-1x-dhcp018.studby.uio.no] has joined #bzr [09:36] few minutes - on phone [09:44] is there a spec or bug or something for the 'bzr cp' feature? [09:45] I'm trying to maintain file templates in a bzr branch. after I change the template, I want all changes I was doing there to be merged into copies of that file. is that possible with bzr? [09:46] siretart, i believe there is a spec discussing how it could work, but it is not implemented atm [09:46] one of the issues is how to determine what changes should propagate or not [09:46] I'd like to subscribe to the spec. do you remember how it was called? [09:47] no [09:47] I imagine that it is tough, though ;) [09:50] NamNguyen: CommitBuilder.commit does the actual commit to disk [09:50] See bzrlib/repository.py [09:50] Well, it's probably not especially easy to do, but working out (and agreeing onn) what it should do is even harder :) [09:52] igc: but if there's an exception in a precommit hook, the whole commit seems to be discarded [09:52] i can be wrong here, but isn't there some kind of rolling back mechanism? [09:54] NamNguyen: looking closer, it looks like self.branch.set_last_revision_info is the final piece of the puzzle ... [09:54] until that final bit is written, the data is on disk by not linked in it seems [09:54] s/by/but/ [09:55] igc: i'm trying to find out if the file is truncated after all [09:55] NamNguyen: so apologies - you could be fine after all ... [09:56] igc: but that might increase the size of the repo if it's not undone [09:56] Maybe - we do have a gc command though [09:56] but then, the next time you commit, it will be written over the same place as the discarded commit [09:57] so i think it all works out [09:57] NamNguyen: my suggestion is to ping abentley in a few hours and get his opinion on precise location ... [09:57] okay [09:57] he did approve your code *and* he knows the commit code really well [09:57] he reviewed it twice, but no harm pester him to do it again [09:58] don't ask him to review the code - just double check on that bit and the consequences of ... [09:58] an exception in the pre-commit hook [09:58] I guess he'll say "all ok" in which case ... [09:59] alright, i'll ask him [09:59] that's great - well done on your first bzr patch! [10:00] I'll be happy to merge it Monday. [10:00] i look forward to handing in more patches :D [10:00] If you want to update the hook doc though before then, even better still [10:00] I look forward to receiving them :-) [10:04] Well, time to go after another good week in the wonderful world of Bazaar ... [10:05] great to see 0.90 ship and lots of neat stuff coming in 0.91 and 0.92 [10:05] Have a good weekend all === mrevell [n=matthew@canonical/launchpad/mrevell] has joined #bzr [10:18] night all === sverrej [n=sverrej@pat-tdc.opera.com] has joined #bzr === Zindar [n=erik@stockholm.ardendo.se] has joined #bzr === aadis [n=aaditya@122.167.223.192] has joined #bzr === gabe_ [n=gabriel@91.84.56.254] has joined #bzr === aadis [n=aaditya@122.167.223.192] has left #bzr [] === NamNguyen [n=namnt@cm246.delta196.maxonline.com.sg] has joined #bzr === Mez [n=Mez@ubuntu/member/mez] has joined #bzr [12:14] so === jelmer [n=jelmer@a62-251-123-16.adsl.xs4all.nl] has joined #bzr [12:14] is there a way to tell bzr/bzrlib to set a timeout on the sockets it creates? === herzel [i=herzel@gateway/tor/x-e3fecb92af2d44ae] has joined #bzr [12:15] or, to ask what i really want to know: not wait for more than some interval (a minute?) for a response from the remote server? === jrydberg [n=johan@213.115.45.46] has joined #bzr === ollie [n=orutherf@dsl092-164-022.wdc2.dsl.speakeasy.net] has joined #bzr [12:31] mwhudson, with python 2.5, yes [12:32] NamNguyen: ? [12:32] socket.setdefaulttimeout(60) [12:32] that's possible in 2.4 already [12:32] maybe you can put it in your sitecustomize.py [12:32] i suppose we could do that [12:32] oh? hah, my bad [12:33] this is code that calls bzrlib apis, so it could just do that during start up [12:33] this branch: https://code.launchpad.net/~ypodim/teleporter/teleporter keeps tripping launchpad up === bac [n=bac@canonical/launchpad/bac] has joined #bzr === arjenAU [n=arjen@ppp215-29.static.internode.on.net] has joined #bzr === matkor [n=matkor@beauty.ant.gliwice.pl] has joined #bzr [12:51] jelmer: Can you merge one typo fix from https://code.launchpad.net/~matkor/bzr-gtk/trunk-matkor ? I emailed phanatic but seems be busy, TIA [12:51] matkor: sure === troy_s [n=aphorism@d206-116-6-170.bchsia.telus.net] has joined #bzr === metze_away is now known as metze === bac [n=bac@canonical/launchpad/bac] has joined #bzr === luks [i=lukas@unaffiliated/luks] has joined #bzr === bac [n=bac@canonical/launchpad/bac] has joined #bzr === mrevell is now known as mrevell-lunch === gabe_ [n=gabriel@91.84.56.254] has joined #bzr === g4bor [n=g4bor@chello089173070091.chello.sk] has joined #bzr === nx [n=hartke@nordcom-adsl-71-148.zfn.uni-bremen.de] has joined #bzr === jrydberg_ [n=johan@213.115.45.46] has joined #bzr === deadwill [n=deadwill@146037.fln.virtua.com.br] has joined #bzr === GaryvdM [n=chatzill@mtngprs2.mtn.co.za] has joined #bzr === zyga [n=zyga@ubuntu/member/zyga] has joined #bzr === cprov [n=cprov@canonical/launchpad/cprov] has joined #bzr === mw|out [n=mw@189.146.15.187] has joined #bzr === mrevell-lunch is now known as mrevell === ignas [n=ignas@office.pov.lt] has joined #bzr [02:42] hi === mw|out is now known as mw === EtienneG [n=etienne@ubuntu/member/EtienneG] has joined #bzr === bac [n=bac@canonical/launchpad/bac] has joined #bzr === cprov [n=cprov@canonical/launchpad/cprov] has joined #bzr === welterde_ is now known as welterde === jamesh [n=james@canonical/launchpad/jamesh] has joined #bzr === cpro1 [n=cprov@200-171-140-32.dsl.telesp.net.br] has joined #bzr === hacklberry [n=hacklber@ppp167-251-99.static.internode.on.net] has joined #bzr === zyga [n=zyga@ubuntu/member/zyga] has joined #bzr === abadger1999 [n=abadger1@65.78.187.68] has joined #bzr === cpro1 is now known as cprov [04:30] hi, where could i get more details about bzr "smart merging"? === z1pp1ty [n=pete@c-67-164-183-147.hsd1.co.comcast.net] has joined #bzr [04:40] i'm looking to use bazaar to do something like this... [04:40] working copy -- bzr --> local svn repo -- svn --> remote svn repo [04:40] I assume it can be done, but are there docs anywhere on how to do something like this? === mthaddon [n=mthaddon@canonical/launchpad/mthaddon] has joined #bzr === bwinton [n=bwinton@mail.phantomfiber.com] has joined #bzr [04:55] where could one get more details about bzr "smart merging"? [05:05] Hacklberry: Google? [05:06] From http://bazaar-vcs.org/BazaarBook#features: [05:06] Smart Merging [05:06] * Merge knows and merges only whats missing. [05:06] * Merge minimizes spurious conflicts. [05:06] * Merge is not tricked by identical changes. [05:10] well the reason why i asked is that when i try to merge into a 'main' branch from 2 branches merge is actually 'tricked by identical changes' === cpro1 [n=cprov@200-171-140-32.dsl.telesp.net.br] has joined #bzr [05:10] Sweet! Do you have a test case? [05:11] what i tried is quite simple - i really think i misunderstood something [05:11] i merge from branch A where i added 3 lines: [05:11] xxx [05:12] yyy [05:12] zzz [05:12] now on branch B i added 3 lines as well: [05:12] qqq [05:12] yyy [05:12] zzz [05:12] and when i tried to merge branch B [05:13] Ahhh... Well, those aren't exactly identical changes... [05:13] he - as i said i misunderstood it then [05:13] If you had committed yyy and zzz in a different step on both branches, then you'ld probably get what you were looking for... [05:14] i.e. branch A gets yyy + zzz, then gets xxx. Branch B gets yyy + zzz, then gets qqq... [05:14] just wondering, what would you expect to be the correct merge here? [05:14] (Now, I haven't tried that myself, but my intuition is that that should work.) [05:15] well i was expecting merge to see that those changes are coming from diff sources [05:15] i was trying to add: [05:15] I mean the result [05:15] I personally can see three possible merges: xxxyyyzzzqqqyyyzz or qqqyyyzzxxxyyyzzz or xxxqqqyyyzzz or qqqxxxyyyzzz [05:15] and all of them seem wrong to me [05:15] (Psst, luks, that's four merges...) [05:16] er, four :) [05:16] I had only three initially [05:16] int foo() { [05:16] Nasty off-by-one error you got there... :) [05:16] return 0; [05:16] } [05:16] on one branch [05:16] int bar() { [05:16] return 0; [05:16] } [05:17] on second branch (both forked from main branch) [05:17] and then i merged into main from branch A [05:18] so let's say some algorithm would merge them, in what other? [05:18] foo and then bar, or the other way around? [05:18] so when merging from B i was expecting merge to pickup that the changes are different, and mark the whole [05:18] int bar() { [05:18] return 0; [05:18] } [05:19] as a block [05:19] and it marked only the function definition, right? [05:19] so i can then manually merge in some tool like kdiff3 [05:19] yes exactly [05:19] hm [05:20] that's how i understood ' Merge is not tricked by identical changes' [05:23] "You may say I'm a dreamer, but I'm not the only one." :-) [05:23] hm, I see [05:24] weave merge marks only the function definitions, merge3 marks whole functions [05:24] but isn't --merge3 the default? [05:25] i tried all 3 algorithms [05:25] but kdiff3 displayed the same [05:27] i thought that bzr uses some unique ids for every change [05:28] so a line of text like abcd from 2 diff sources will be treated as 2 diff entries even if the content is the same [05:28] I think the 3-way merge should do exactly that [05:29] (and it does here) [05:29] ok i m going to try again then [05:30] i mean in the morning :-) it is 1:30am here, i live in Canberra === cpro1 is now known as cprov === orospakr [n=orospakr@132.213.238.4] has joined #bzr === cypherbios [n=cyr@ubuntu/member/cypherbios] has joined #bzr === lhkj [n=rd@85.99.133.55] has joined #bzr === lhkj [n=rd@85.99.133.55] has left #bzr [] === bwinton_ [n=bwinton@mail.phantomfiber.com] has joined #bzr === Odd_Bloke [i=oddbloke@compsoc.sunion.warwick.ac.uk] has joined #bzr === nx [n=hartke@nordcom-adsl-71-148.zfn.uni-bremen.de] has joined #bzr [06:47] whoah [06:48] I just got a warning saying that my Python interpreter doesn't support en_US.UTF-8 [06:48] (during a bzr push) === cprov is now known as cprov-lunch === duckx [n=Duck@tox.dyndns.org] has joined #bzr [07:01] strangely enough, python -c 'from bzrlib.osutils import get_user_encoding; print get_user_encoding()' prints "UTF-8" with no warning === asak [n=alexis@201-13-110-44.dsl.telesp.net.br] has joined #bzr [07:03] was it a bzr push over bzr+ssh? then what matters is if the target system supports en_US.UTF-8, afaik [07:04] ah, interesting, yes [07:05] thanks a lot dato :) [07:05] no problem === g4bor [n=g4bor@chello089173070091.chello.sk] has left #bzr [] === herzel [i=herzel@gateway/tor/x-cb6ccf5dc363308e] has joined #bzr === Odd_Bloke [i=oddbloke@compsoc.sunion.warwick.ac.uk] has joined #bzr === p4tux [n=p4tux@189.169.92.184] has joined #bzr === bwinton_ is now known as bwinton === bwinton [n=bwinton@mail.phantomfiber.com] has left #bzr [] === bwinton [n=bwinton@mail.phantomfiber.com] has joined #bzr === bwinton [n=bwinton@mail.phantomfiber.com] has joined #bzr [07:44] LarstiQ: ping === pete__c [n=pete@015-823-542.area5.spcsdns.net] has joined #bzr === synic [n=squish@pdpc/supporter/student/synic] has joined #bzr [08:09] after a 'bzr up', how can I see what files were changed? [08:12] synic: do you remember what revision you were on previously? Do the command tell you how many you just got? [08:12] if you know then bzr status -r-6.. should tell you [08:12] another way is bzr log -v and then just read the log messages and see which files were changed. [08:16] k === Zindar [n=erik@h188n1fls12o803.telia.com] has joined #bzr === ignas [n=ignas@ctv-213-164-108-111.vinita.lt] has joined #bzr === asabil [n=asabil@62.70.2.252] has joined #bzr === michelp [n=michelp@70.103.91.130] has joined #bzr === quatauta [n=quatauta@pD9E27AA8.dip.t-dialin.net] has joined #bzr [08:28] synic: we also plan to let it output the changes in the future, unless -q is specified === thekorn [n=thekorn@a89-182-15-50.net-htp.de] has joined #bzr === bigdog [n=scmikes@79-67-14-216-arpa.cust.cinci.current.net] has joined #bzr [08:47] jelmer: is there any way to output the changes during update with a flag? -v maybe? [08:50] New bug: #136445 in bzr "Please provide an easy way to ask "What did you just do?"" [Wishlist,New] https://launchpad.net/bugs/136445 [08:52] Now that's an awesome bug... [08:52] bzr wtf-just-happened-there [08:53] synic: Not yet [08:56] jelmer: ok [09:10] That bug is a good idea. Before I fully got into the habit of using 'bzr pull -v', I wouldn't be able to find out what all was pulled. [09:10] Maybe just printing the old revision during those command would be good enough. [09:10] Like, where it says "Now on", it could say "Started at" too. === Janzert [n=Janzert@75-134-223-54.dhcp.trcy.mi.charter.com] has joined #bzr === tca [n=tom@ti541110a080-4322.bb.online.no] has joined #bzr === patux [n=p4tux@189.169.92.184] has joined #bzr [09:40] can you checkout a specific directory in a branch? === orospakr [n=orospakr@132.213.238.4] has joined #bzr [09:42] synic: No. === mtaylor [n=mtaylor@dsl231-061-195.sea1.dsl.speakeasy.net] has joined #bzr [09:46] anybody know what the status of the visual studio plugin - https://launchpad.net/bzr-visualstudio - is? [09:50] mtaylor: yep [09:50] I'm the developer [09:51] nx: cool. is it ready for people to use/poke at? [09:52] go ahead. it's still lacking some features, but those that are implemented should work well [09:52] nx: sweet. I'll give it a spin then [09:52] nx: should I branch trunk ? [09:53] banquet.status is the latest code [09:53] I haven't managed to create an installer yet; you'll need to have the VSSDK installed to run from the branch [09:54] ok. I think I've got that installed on this box [10:00] nx: when I try to open the .sln file, I get errors about not being able to open the Project files... [10:02] what's the exact error message? do you have the SP1 installed? === Janzert semi, sorta remembers running into issues with hardcoded absolute paths [10:03] nx: Unable to read the project file 'Banquet.csproj' [10:03] nx: but I might not have sp1 installed. let me check [10:04] right, i forgot you need to set a environment variable named VisualStudioIntegration that points to the VisualStudioIntegration directory in the VSSDk directory [10:04] sorry [10:05] or just open the csproj file and replace $(VisualStudioIntegration) with that path [10:05] ah, ok [10:11] Has anyone here run bzr on Python 3.0 yet? [10:12] aggggggggggh [10:12] it's already started [10:12] hahaha [10:13] Hey, give me some credit. I've had the 3.0a1 announcement page sitting in my browser since 9:00 this morning! [10:13] we are doomed, Guido has killed us all [10:13] Heh. I think you're thinking of Python 4000, with sys.kill_us_all()... [10:13] bwinton: it is impossible to run most existing Python code on python 3 [10:14] Sure, but the 2to3 tool gets you part (most?) of the way there. I was wondering how far it got bzr... [10:14] ah. ok. so really you wanted to ask if anybody has ported bzr to python 3 yet :-) [10:15] radix: If you want to be technical about it... ;) [10:15] Actually, I think I was even further behind than that. I really wanted to ask if anyone had looked into porting bzr to python 3 yet. === mthaddon [n=mthaddon@canonical/launchpad/mthaddon] has joined #bzr === cprov [n=cprov@canonical/launchpad/cprov] has joined #bzr === gldnspud_ is now known as gldnspud === bwinton [n=bwinton@mail.phantomfiber.com] has left #bzr [] === jamesh [n=james@canonical/launchpad/jamesh] has joined #bzr === cprov is now known as cprov-out [11:44] LarstiQ: ping === gldnspud_ [n=gldnspud@72.171.93.139] has joined #bzr === gldnspud__ [n=gldnspud@72.171.93.139] has joined #bzr === z1pp1ty [n=pete@c-67-164-183-147.hsd1.co.comcast.net] has left #bzr []