[12:06] <abentley> lifeless: So you're saying lines are evil?
[12:09] <lifeless> 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
[12:10] <lifeless> oh right ;)
[12:11] <abentley> 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] <lifeless> hg seem to delta on bytes
[12:12] <abentley> I suppose binary delta compression could work.
[12:13] <lifeless> the C library they wrote does a line split without copying
[12:13] <lifeless> or something
[12:13] <lifeless> certainly they don't seem to do splitlines() during commit
[12:13] <lifeless> I have pack commit at 3.5x hg commit, I'm trying to pull it down to < 2x
[12:15] <ddaa> is the "atexit.register(_rmtree_temp_dir, root)" in TestCaseWithMemoryTransport still present in current bzr?
[12:15] <ddaa> it's causing pain with the launchpad test suite
[12:16] <ddaa> generally, please do not use atexit for test suite cleanup... it's gross
[12:16] <lifeless> I don't recall a patch removing that anytime recently
[12:16] <lifeless> mind you I don't recall putting that in ;)
[12:16] <ddaa> lifeless: I know you have better taste that that, I was broadcasting
[12:17] <abentley> 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] <lifeless> get_matching_blocks is whitespace-ignoring specific right ?
[12:18] <abentley> No, it's generic.  It's what we use for everything.
[12:19] <abentley> knit deltas, annotation, diff.
[12:19] <lifeless> if we implement diff -w
[12:19] <lifeless> or annotate -w
[12:19] <lifeless> -w ignores whitespace so "    foo = 'bar' "   and "    foo = 'bar'" are considered to match
[12:21] <abentley> 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] <abentley> Or annotate, for that matter.
[12:22] <lifeless> presumably via composition of these regions
[12:22] <abentley> Yes.
[12:23] <lifeless> I'll think about this some
[12:24] <abentley> It seems like we may have over-optimized "annotate".
[12:24] <lifeless> 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] <lifeless> annotate - possibly yes
[12:25] <abentley> While it's nice to be fast, it doesn't have to be as fast as fulltext access.
[12:26] <abentley> 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] <lifeless> yup
[12:28] <abentley> So possibly storing get_matching_blocks regions is better than caching annotations.
[12:30] <lifeless> it would be less data for sure
[12:31] <lifeless> do we have an uncached annotate facility still ?
[12:31] <lifeless> or do I have to recreate it to disable the annotation cache in packs?
[12:33] <abentley> I thought only bzrtools did that, until we got weaves.
[12:33] <abentley> Anyhow, I do have the bzrtools code, but I bet it's pretty dated.
[12:34] <abentley> There is the reannotate code, though.
[12:34] <abentley> That should do the trick.
[12:35] <abentley> It annotates from parents to children, not from children to parents.
[12:37] <lifeless> so full history ?
[12:37] <lifeless> anyhow, we're going to need a cacheless annotate routine somewhere
[12:37] <abentley> Well, if you had an annotated fulltext of an ancestor, it could work from that.
[12:38] <abentley> And for merge purposes, you could start at a common ancestor.
[12:39] <abentley> But if you want the full annotation with no cache, you have to go through history anyway.
[12:41] <lifeless> yes full history all sides
[12:42] <lifeless> with the potential to stop early if we go from child -> parent
[12:57] <BryceLeo> anyone had a problem installing the new bzr via synaptic in ubuntu?
[12:58] <BryceLeo> feisty fawn if it matters
[12:59] <abentley> Well, there was a problem reported this morning, but I'm unclear whether it applies to Feisty.
[01:00] <abentley> Does it say "error in control file: `Files' value not specified"?
[01:02] <BryceLeo> yup
[01:02] <BryceLeo> i think i've got a fix
[01:02] <BryceLeo> yup it's super simple
[01:03] <BryceLeo> let me pasebin it right quick
[01:04] <lifeless> BryceLeo: fixed packages are already building
[01:10] <BryceLeo> awesome
[01:10] <BryceLeo> well i've got a patch if anyone wants it now
[01:11] <BryceLeo> haha now if only you guys could fix why the python binding for gtkmozembed crashes with https
[01:12] <lifeless> hahah
[01:12] <lifeless> just figured out why GzipFile is _so_ slow
[01:12] <lifeless> it overrides the default compression level for zlib
[01:12] <lifeless> GzipFile('foo', 'wb') == gzip -9
[01:12] <BryceLeo> whoops
[01:13] <lifeless> q: why is bzr slow
[01:13] <lifeless> a: stdlib fuckage
[01:13] <Peng> Don't the docs say it uses the zlib default?
[01:14] <lifeless> it does; but if you aren't the one choosing to use a tool, do you read the docstring?
[01:14] <lifeless> its surprising for library bindings to differ between languages
[01:15] <Peng> Oh, GzipFile does say it defaults to 9.
[01:15] <abentley> That doesn't explain why it's so slow for decompression, though.
[01:15] <lifeless> I haven't looked into that yet
[01:16] <lifeless> but changing it to the default, we're only 2 seconds slower - 38 vs 36
[01:17] <abentley> Slower than raw zlib?
[01:22] <lifeless> slower than 'gzip -c mozilla.tar > /dev/null'
[01:23] <abentley> Ah, cool.
[01:24] <lifeless> so I'm just testing the change in data size
[01:30] <abentley> 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] <lifeless> ahha 127MB
[01:31] <lifeless> this patch going up for review :)
[01:31] <lifeless> abentley: getting the ability to annotate without cached annotations seems to save nearly 1/5 of our current commit time
[01:32] <lifeless> abentley: so that would be a good thing, and seems to be unlikely to collide
[01:35] <abentley> 127MB is the size change?
[01:39] <abentley> lifeless: btw, please review my reconcile change.
[01:40] <abentley> Also, does your latest in "http://people.ubuntu.com/%7Erobertc/pack-repository.knits/" have no annotation?
[01:42] <lifeless> no, I only played with that locally
[01:42] <lifeless> 127M is the new repo size
[01:42] <lifeless> the old repo size was 140M
[01:42] <lifeless> so its actually smaller ;)
[01:43] <abentley> That makes no sense...
[01:44] <abentley> I'm realizing that child->parent order also matches our expected data ordering better.
[01:44] <lifeless> [01:44] <lifeless> --- bzrlib/repofmt/pack_repo.py 2007-08-28 02:18:13 +0000
[01:44] <lifeless> +++ bzrlib/repofmt/pack_repo.py 2007-08-30 03:44:59 +0000
[01:44] <lifeless> @@ -1035,7 +1035,7 @@
[01:44] <lifeless>              self.weavestore._file_mode,
[01:44] <lifeless>              index=knit_index,
[01:44] <lifeless>              access_method=knit_access,
[01:44] <lifeless> -            **self.weavestore._versionedfile_kwargs)
[01:44] <lifeless> +            factory=knit.KnitPlainFactory())
[01:44] <lifeless> thats the patch to drop annotations - I haven't committed because I expect it to break tests left, right and centre
[01:45] <lifeless> your updated reconcile patch - yes, I will review it
[01:46] <abentley> Okay.  I will go break some tests >:)
[01:48] <abentley> !?! "bzr selftest annotate" and nothing breaks.
[01:49] <abentley> I don't think you're intelligent, ubotu, believe me.
[01:51] <fullermd> Man, this channel is never satisfied.  Tests don't pass, people complain.  Tests pass, people complain...
[01:51] <abentley> 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] <lifeless> abentley: the annotate tests are probably not strict enough then; at the repo level the API call to the knit will work
[01:55] <lifeless> abentley: but it will annotate the entire file as changed in the last commit :(
[01:56] <abentley> Sounds pretty nuts.
[01:56] <lifeless> abentley: so that when we hit that case, we don't end up e.g. sha1summing an entire iso twice
[01:56] <lifeless> abentley: yeah, supporting annotate() on knits that don't have annotation data in them *is* nuts IMO but its what the original interface offered.
[02:00] <lifeless> bbiab
[02:07] <lifeless> poolie: quick call ?
[02:08] <poolie> sure
[02:33] <spiv> 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] <abentley> spiv: robert's said he'll review my new patch.
[02:34] <spiv> Ah good.  Are you still of the opinion that smart server fetching should compensate for this?
[02:36] <abentley> I think it should not fail silently.  It can fail noisily or succeed silently-- your pick.
[02:37] <spiv> i.e. pulling from a broken repo should not silenty break my repo?
[02:37] <abentley> Yes.
[02:37] <spiv> Makes sense.
[02:42] <lifeless> spiv: there is a flag on the repository indicating it can suffer from this form of corruption
[02:43] <lifeless> 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] <lifeless> 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] <lifeless> abentley: ^ does this make sense to you ?
[02:44] <lifeless> spiv: wanna quick chat ?
[02:44] <spiv> lifeless: yeah, that'd be good
[02:44] <lifeless> k, I'll ring
[02:44] <spiv> ta
[02:46] <abentley> lifeless: Yes, that makes sense to me.
[02:48] <abentley> Hmm.  Maybe it could be a supplemental flag?
[02:49] <abentley> Because it would still be readable by older clients.
[03:04] <lifeless> abentley: I meant a flag on the object, not on disk
[03:04] <lifeless> 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] <abentley> I meant the format bump you were talking about.
[03:05] <lifeless> abentley: no, I don't think it can be a supplemental flag or older clients will write to the repo too
[03:05] <lifeless> abentley: and could then introduce this defect
[03:05] <abentley> Oh, drat.
[03:06] <lifeless> igc: compression fix has landed
[03:06] <igc> lifeless: excellent - just checked pqm 5 mins ago checking its progress :-)
[03:07] <abentley> 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] <abentley> spiv: Would it make sense to provide a way to do dumb fetch?
[03:16] <lifeless> abentley: by dumb you mean the current knit join approach ?
[03:16] <abentley> Yeah.
[03:16] <abentley> For people who can't reconcile the source repo.
[03:17] <abentley> But I also mean, just using the dumb transport.
[03:18] <abentley> But this is only likely to affect initial branches anyhow.
[03:18] <lifeless> I think that might be reasonable but given that few people run bzr+ssh-only repo's anyhow
[03:24] <lifeless> igc: pushed a pack repo that has the compression fix too, to my 'repository' branch.
[03:25] <igc> lifeless: thanks. I'm interested in a pack repo with annotations separated next :-)
[03:26] <abentley> igc: I'm working on stripping annotations completely.
[03:26] <igc> abentley: from knits?
[03:27] <abentley> From packs.
[03:27] <igc> I guess I was assuming that would be a format bump and it may as well come with the pack stuff?
[03:27] <igc> cool
[03:28] <abentley> Yeah.  We'll see.  It may not be performant without at least caching get_matching_blocks.
[03:31] <abentley> But since we can extract that from our delta formats, who knows?
[03:32] <Peng> Stripping annotations from packs? As in 'bzr annotate'?
[03:32] <lifeless> igc: I pasted the patch for that here
[03:32] <igc> code,code,code ... measure,measure,measure ... code,code,code ...
[03:33] <igc> lifeless: ok, I'll grab it later - just trying to get an options patch out right now
[03:34] <abentley> Peng: yes.  It's a significant cost when committing large trees.  We promise not to break anything.
[03:34] <fullermd> It doesn't break anything; all the tests still pass   ;)
[03:45] <Peng> abentley: But will it make bzr annotate slow?
[03:45] <lifeless> Peng: s/?/er?/
[03:45] <lifeless> yes
[03:45] <Peng> Even slower?
[03:46] <Peng> Yuck.
[03:46] <Peng> One thing I liked about bzr was speedy annotations, and now it'll be worse than hg.
[03:46] <Peng> I know I know, I'd be whining about slow commits if you didn't do this. :P
[03:46] <abentley> Why do you think it will be slower than hg?
[03:47] <lifeless> why do you say it'll be worse than hg ?
[03:47] <Peng> I don't know.
[03:47] <Peng> I compared it some time.
[03:48] <Peng> Hold on.
[03:55] <Peng> ....
[03:57] <Peng> Hey, where can I get a copy of the repository branch new enough to access the repository branch?
[03:59] <abentley> http://people.ubuntu.com/%7Erobertc/pack-repository.knits/ ?
[03:59] <lifeless> yup
[03:59] <lifeless> Peng: see my dogfooding mails to the list
[04:00] <Peng> I didn't think that branch was up-to-date enough.
[04:00] <NamNguyen> abentley: what does auto_merge.py do?
[04:00] <lifeless> Peng: I've explicitly stated that I keep it up to date enough to read the other branch
[04:01] <lifeless> Peng: its the bootstrap
[04:01] <Peng> Oh.
[04:02] <abentley> NamNguyen: It marks merge requests merged if they have been merged into the mainline.
[04:02] <NamNguyen> abentley: how is that done? i looked at the code but didn't understand it much
[04:03] <Peng> Okay, I get it.
[04:03] <NamNguyen> something to do with merge_id, is it supposed to be unique?
[04:03] <Peng> I need to throw out my old branch of repository, and get it again?
[04:03] <abentley> No, not merge_id.
[04:04] <abentley> First it downloads the latest version of the mainline.
[04:04] <abentley> Then it finds which revisions are newly part of the mainline's ancestry.
[04:05] <poolie> lifeless, are you going to upload a new 0.90 deb?
[04:05] <abentley> Actually, it just finds which revisions are part of the mainline's ancestry.
[04:05] <lifeless> poolie: yes when I don't get md5 errors from the deb archive during build
[04:05] <abentley> Then it looks at the merge requests, and sees whether their head revision is in the mainline's ancestry.
[04:06] <lifeless> Peng: Please read the mails with [PACKS]  in the them on the list.
[04:06] <lifeless> Peng: they contain all the relevant info
[04:08] <Peng> Blaaah.
[04:09] <NamNguyen> abentley: suppose that two merge requests branched from a same revision
[04:09] <abentley> I don't know what you mean by "branched".
[04:10] <NamNguyen> they come from a same revision
[04:10] <abentley> The only thing that matters is the head revision-- the newest revision in the merge request.
[04:10] <abentley> So you have two merge requests trying to submit exactly the same change?
[04:11] <NamNguyen> different change
[04:11] <abentley> Where they branched from doesn't matter.
[04:12] <NamNguyen> isn't the head revision the parent revision?
[04:12] <abentley> No.
[04:12] <abentley> The head revision is the youngest revision.
[04:12] <abentley> If the merge request has a bundle, all the other revisions in it will be ancestors of the head revision.
[04:13] <NamNguyen> and when this bundle is merged, is the revision id kept unchanged?
[04:14] <NamNguyen> its revision ids
[04:16] <abentley> Yes, revision ids are never altered.
[04:18] <NamNguyen> 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] <abentley> Right.
[04:22] <lifeless> Peng: if you've read the mail and are lost I'll happily help you
[04:22] <lifeless> Peng: but I don't have time to simply be repeating myself sorry
[04:22] <Peng> lifeless: Yeah, I get it. I need to get a mail client up and running and start reading the list. :P
[04:23] <lifeless> Peng: gmane has it
[04:25] <Peng> I can't get Gmane to load at the moment.
[04:25] <Peng> I'm reading the list on lists.ubuntu.com.
[04:25] <lifeless> ok
[04:29] <Peng> Okay!
[04:29] <poolie> are the generated html files going to be called .htm or .html?
[04:29] <poolie> i thought we agreed to change it to .html?
[04:30] <sri> sup
[04:30] <poolie> hi
[04:30] <Peng> Annotating a 1000-line file with 1600 revisions, user time:
[04:30] <Peng> bzr knits: 1.1 seconds
[04:30] <Peng> bzr packs: 3.6
[04:30] <Peng> hg: 4.0
[04:31] <Peng> Bzr 0.90 was a few msec faster than the pack version in a knit branch. :P
[04:32] <abentley> poolie: They're html, but no one has updated the online documentation.
[04:32] <abentley> igc was looking into it last I heard.
[04:32] <poolie> the cron job is running, but maybe it's not copying them across
[04:34] <igc> poolie: the doc usually gets updated as part of the release rollout
[04:35] <lifeless> Peng: ms differences are sampling noise
[04:35] <igc> I've been meaning to ask you about where James got up to
[04:35] <lifeless> Peng: the 3.6 seconds is due to the single text index not doing partial loads
[04:36] <Peng> lifeless: Will that be improved in the future?
[04:36] <lifeless> yes
[04:36] <Peng> Yeah, you're right, it was just noise.
[04:37] <Peng> lifeless: Okies.
[04:37] <Peng> lifeless: But removing annotation data will make it slower ..
[04:37] <lifeless> thats right.
[04:37] <lifeless> but every file version has to get committed by definition
[04:37] <lifeless> only some get annotated
[04:38] <lifeless> so we could for instance have a background task to generate an annotation cache
[04:38] <lifeless> fire off a thread as a commit hook
[04:38] <Peng> Huh.
[04:38] <lifeless> or cache different data that helps annotations as abentley mentions
[04:38] <lifeless> lots of options
[04:39] <lifeless> but removing 20% overhead during commit that is only sometimes used seems like a pretty good idea
[04:40] <Peng> Yeah, it does.
[04:40] <Peng> I just liked having fast annotations. :P
[04:40] <lifeless> e.g.
[04:40] <lifeless> if you ask for an annotation of file X, we cacn cache the results
[04:40] <ubotu> New bug: #135770 in bzr (main) "bzr faild ti install (dup-of: 135891)" [Undecided,New]  https://launchpad.net/bugs/135770
[04:41] <Peng> 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] <Peng> Anyway, I don't want to stop you or anything.
[04:41] <Peng> Just sayin'.
[04:41] <lifeless> the way you get from slow to fast commits is by stripping overhead thats not needed
[04:42] <Peng> 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] <Peng> But annotating going from 1 second to 4 is "fast" to "slow".
[04:43] <Peng> Anyway, I'll shut up.
[04:43] <Peng> The change is a good idea.
[04:43] <Peng> I just hope that you'll be able to keep annotating as fast as possible! :)
[04:46] <abentley> 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] <lifeless> abentley: bzr.dev :)
[04:48] <lifeless> abentley: I want to keep the branch as small as possible at all times
[04:48] <abentley> Aw, drat.  I'll hafta cherrypick.
[05:59] <abentley> igc: It seems as though the path must start with 'callgrind.out', not just the basename.
[06:00] <igc> in my code you mean? If so, I'll fix that
[06:03] <poolie> i'm looking into why the docs aren't visible
[06:03] <igc> thanks poolie
[06:04] <poolie> they are being built; they might not be copied to the right directory, or something like that
[06:11] <poolie> ok i think that's ok now
[06:25] <abentley> Awesome.  Now we have a copy of NEWS to point people at.
[06:27] <abentley> lifeless: I've got the new annotation code using precalculated get_matching blocks everywhere possible.
[06:27] <lifeless> abentley: you're on fire
[06:27] <abentley> That too.
[06:27] <igc> abentley: +1 to that
[06:28] <abentley> But without matching blocks for the righthand parent of merges, there are still 279 calls.  And that's 40% of runtime.
[06:29] <lifeless> whats your test file, NEWS?
[06:29] <abentley> Yep.
[06:29] <abentley> revision 2000
[06:29] <abentley> That still takes 13 seconds.
[06:30] <abentley> So I don't want to go higher.
[06:31] <abentley> 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] <abentley> Because knit deltas only tell us about the left parent.
[06:33] <lifeless> man python you suck
[06:33] <lifeless> a$ python -m timeit 's = [] ; s.append((200, 300)); s.pop()'
[06:33] <lifeless> 1000000 loops, best of 3: 0.874 usec per loop
[06:33] <lifeless> $ python -m timeit 's = [] ; s.append((200, 300)); del s[-1] '
[06:33] <lifeless> 1000000 loops, best of 3: 0.528 usec per loop
[06:33] <abentley> Sheesh
[06:33] <lifeless> $ python -m timeit 's = [] ; s.append((200, 300))'
[06:33] <lifeless> 1000000 loops, best of 3: 0.398 usec per loop
[06:34] <lifeless> .130 to do del s[-1] , .480 to do s.pop()
[06:35] <fullermd> If it helps, it takes my system longer to do the pops than it takes yours to do the whole bunch   :p
[06:35] <lifeless> fullermd: do you see the same relative costs?
[06:35] <fullermd> ~1 -> ~2.3.
[06:35] <fullermd> Well, ~1 - ~1.25 - ~2.3.
[06:36] <fullermd> Eyeballs similarish, yah.
[06:36] <lifeless> copy n paste is easier :)
[06:36] <fullermd> Little over double cost for pop, 'bout 25% more for del.  Close enough.
[06:39] <poolie> lifeless, thanks for making a sid/gutsy repo
[06:41] <abentley> lifeless, poolie: I've started work on a NEWS-specific text merge, but no ETA on completion yet.
[06:45] <abentley> Annotating the latest version of NEWS takes 1m25.767.  Eeps.
[06:45] <abentley> g'night.
[06:50] <poolie> lifeless, i think splitting the news might make it easier for people developing across releases
[06:50] <poolie> because their changes would not accidentally end up in a different release
[07:02] <igc> poolie: thanks for the doc stuff. It looks good except that the 'latest' link is still pointing to some older doc?
[07:02] <poolie> thanks, fixed ?
[07:03] <igc> poolie: yes, assuming latest means 'current release', not 'development'
[07:04] <lifeless> latest is not clear
[07:04] <igc> we do have bzr.dev for that
[07:04] <igc> I'd prefer 'current' to 'latest' my self
[07:04] <poolie> maybe we should just get rid of that link and let people who want the latest look at bzr.dev?
[07:04] <igc> that would do
[07:04] <igc> 2nd thoughts ...
[07:04] <igc> I'd like a 'current' link
[07:05] <lifeless> latest was meant to mean current release
[07:05] <lifeless> I didn't think about clarity enoug at the tome I think
[07:05] <igc> it's need IMO, I just don't like the name
[07:10] <poolie> can someone glance at http://bundlebuggy.aaronbentley.com/request/%3C2422be180708301335x3103b2c9mbaf318e287b4cf3b@mail.gmail.com%3E
[07:10] <poolie> please
[07:11] <beuno> please :D
[07:14] <beuno> btw, is bundlebuggy a custom thing?  it's marvelous  :D
[07:17] <Peng> beuno: Yes, but it's open source.
[07:18] <beuno> Peng, aaah, well, it's a great idea/implementation
[07:18] <Peng> Totally. :)
[07:26] <igc> poolie: that looks fine to me. I'll approve it in BB
[07:30] <poolie> igc, thanks
[07:30] <beuno> yay!  does the bug close my itself in LP?
[07:30] <poolie> which bug?
[07:31] <beuno> the one that the patch is for, #107155
[07:31] <lifeless>  python -m timeit '{1:2, 2:3, 3:4}'
[07:31] <lifeless> 1000000 loops, best of 3: 0.584 usec per loop
[07:31] <lifeless>  python -m timeit 'dict(((1,2), (2,3), (3,4)))'
[07:31] <lifeless> 100000 loops, best of 3: 2.15 usec per loop
[07:32] <fullermd> 'bout the same ratio here.
[07:33] <lifeless> just the inner tuple there is tuple is 0.177
[07:39] <lifeless> ok, bye. I need to pack
[07:39] <beuno> aaaaanyway, time I get some sleep, ping me if you need anything else with the patch, night all  :D
[07:40] <poolie> beuno, i've just sent it off
[07:41] <beuno> poolie, great, thanks a bunch, I'll close the bug then
[07:41] <poolie> spiv, quick call?
[07:42] <spiv> poolie: sounds good.  Two minutes?
[07:42] <poolie> sure, call me when you're ready
[07:42] <poolie> igc, i like custom_help()
[07:43] <igc> thanks
[08:08] <igc> spiv: is http://bundlebuggy.aaronbentley.com/request/%3C20070826091222.GC11127@steerpike.home.puzzling.org%3E merged into the bzr.dev yet?
[08:09] <poolie> igc, would you like a catchup call? when were you going to finish today?
[08:09] <spiv> igc: not yet, thanks for the reminder.
[08:10] <igc> poolie: don't mind either way. Need to wrap up around 6 tonight
[08:10] <poolie> ok, can we talk about 5:30?
[08:10] <igc> sure
[08:10] <poolie> cool
[08:10] <poolie> i'm stepping out for a bit
[08:11] <igc> poolie: before you go ...
[08:11] <igc> I'm about to do some reviews
[08:11] <igc> any preferences for which ones?
[08:16] <poolie> not in particular, though i do think doing some is a good idea
[08:16] <poolie> i'm just doing yours
[08:17] <igc> ok - I'll do the --change one from Lucas and the pre-commit hook one
[09:32] <NamNguyen> igc, thanks for reviewing the patch for pre_commit hook
[09:32] <NamNguyen> does a commit to CommitBuilder actually commits anything?
[09:33] <NamNguyen> or does it only flag that a commit is done, ready to be flushed out to disk
[09:36] <igc> few minutes - on phone
[09:44] <siretart> is there a spec or bug or something for the 'bzr cp' feature?
[09:45] <siretart> 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] <poolie> siretart, i believe there is a spec discussing how it could work, but it is not implemented atm
[09:46] <poolie> one of the issues is how to determine what changes should propagate or not
[09:46] <siretart> I'd like to subscribe to the spec. do you remember how it was called?
[09:47] <poolie> no
[09:47] <siretart> I imagine that it is tough, though ;)
[09:50] <igc> NamNguyen: CommitBuilder.commit does the actual commit to disk
[09:50] <igc> See bzrlib/repository.py
[09:50] <fullermd> Well, it's probably not especially easy to do, but working out (and agreeing onn) what it should do is even harder   :)
[09:52] <NamNguyen> igc: but if there's an exception in a precommit hook, the whole commit seems to be discarded
[09:52] <NamNguyen> i can be wrong here, but isn't there some kind of rolling back mechanism?
[09:54] <igc> NamNguyen: looking closer, it looks like self.branch.set_last_revision_info is the final piece of the puzzle ...
[09:54] <igc> until that final bit is written, the data is on disk by not linked in it seems
[09:54] <igc> s/by/but/
[09:55] <NamNguyen> igc: i'm trying to find out if the file is truncated after all
[09:55] <igc> NamNguyen: so apologies - you could be fine after all ...
[09:56] <NamNguyen> igc: but that might increase the size of the repo if it's not undone
[09:56] <igc> Maybe - we do have a gc command though
[09:56] <NamNguyen> but then, the next time you commit, it will be written over the same place as the discarded commit
[09:57] <NamNguyen> so i think it all works out
[09:57] <igc> NamNguyen: my suggestion is to ping abentley in a few hours and get his opinion on precise location ...
[09:57] <NamNguyen> okay
[09:57] <igc> he did approve your code *and* he knows the commit code really well
[09:57] <NamNguyen> he reviewed it twice, but no harm pester him to do it again
[09:58] <igc> don't ask him to review the code - just double check on that bit and the consequences of ...
[09:58] <igc> an exception in the pre-commit hook
[09:58] <igc> I guess he'll say "all ok" in which case ...
[09:59] <NamNguyen> alright, i'll ask him
[09:59] <igc> that's great - well done on your first bzr patch!
[10:00] <igc> I'll be happy to merge it Monday.
[10:00] <NamNguyen> i look forward to handing in more patches :D
[10:00] <igc> If you want to update the hook doc though before then, even better still
[10:00] <igc> I look forward to receiving them :-)
[10:04] <igc> Well, time to go after another good week in the wonderful world of Bazaar ...
[10:05] <igc> great to see 0.90 ship and lots of neat stuff coming in 0.91 and 0.92
[10:05] <igc> Have a good weekend all
[10:18] <poolie> night all
[12:14] <mwhudson> so
[12:14] <mwhudson> is there a way to tell bzr/bzrlib to set a timeout on the sockets it creates?
[12:15] <mwhudson> 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?
[12:31] <NamNguyen> mwhudson, with python 2.5, yes
[12:32] <mwhudson> NamNguyen: ?
[12:32] <NamNguyen> socket.setdefaulttimeout(60)
[12:32] <mwhudson> that's possible in 2.4 already
[12:32] <NamNguyen> maybe you can put it in your sitecustomize.py
[12:32] <mwhudson> i suppose we could do that
[12:32] <NamNguyen> oh? hah, my bad
[12:33] <mwhudson> this is code that calls bzrlib apis, so it could just do that during start up
[12:33] <mwhudson> this branch: https://code.launchpad.net/~ypodim/teleporter/teleporter keeps tripping launchpad up
[12:51] <matkor> 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] <jelmer> matkor: sure
[02:42] <ignas> hi
[04:30] <hacklberry> hi, where could i get more details about bzr "smart merging"?
[04:40] <z1pp1ty> i'm looking to use bazaar to do something like this...
[04:40] <z1pp1ty> working copy -- bzr --> local svn repo -- svn --> remote svn repo
[04:40] <z1pp1ty> I assume it can be done, but are there docs anywhere on how to do something like this?
[04:55] <hacklberry>  where could one get more details about bzr "smart merging"?
[05:05] <bwinton> Hacklberry: Google?
[05:06] <bwinton> From http://bazaar-vcs.org/BazaarBook#features:
[05:06] <bwinton> Smart Merging
[05:06] <bwinton>     * Merge knows and merges only whats missing.
[05:06] <bwinton>     * Merge minimizes spurious conflicts.
[05:06] <bwinton>     * Merge is not tricked by identical changes.
[05:10] <hacklberry> 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'
[05:10] <bwinton> Sweet!  Do you have a test case?
[05:11] <hacklberry> what i tried is quite simple - i really think i misunderstood something
[05:11] <hacklberry> i merge from branch A where i added 3 lines:
[05:11] <hacklberry> xxx
[05:12] <hacklberry> yyy
[05:12] <hacklberry> zzz
[05:12] <hacklberry> now on branch B i added 3 lines as well:
[05:12] <hacklberry> qqq
[05:12] <hacklberry> yyy
[05:12] <hacklberry> zzz
[05:12] <hacklberry> and when i tried to merge branch B
[05:13] <bwinton> Ahhh...  Well, those aren't exactly identical changes...
[05:13] <hacklberry> he - as i said i misunderstood it then
[05:13] <bwinton> 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] <bwinton> i.e. branch A gets yyy + zzz, then gets xxx.  Branch B gets yyy + zzz, then gets qqq...
[05:14] <luks> just wondering, what would you expect to be the correct merge here?
[05:14] <bwinton> (Now, I haven't tried that myself, but my intuition is that that should work.)
[05:15] <hacklberry> well i was expecting merge to see that those changes are coming from diff sources
[05:15] <hacklberry> i was trying to add:
[05:15] <luks> I mean the result
[05:15] <luks> I personally can see three possible merges: xxxyyyzzzqqqyyyzz or qqqyyyzzxxxyyyzzz or xxxqqqyyyzzz or qqqxxxyyyzzz
[05:15] <luks> and all of them seem wrong to me
[05:15] <bwinton> (Psst, luks, that's four merges...)
[05:16] <luks> er, four :)
[05:16] <luks> I had only three initially
[05:16] <hacklberry> int foo() {
[05:16] <bwinton> Nasty off-by-one error you got there...  :)
[05:16] <hacklberry> return 0;
[05:16] <hacklberry> }
[05:16] <hacklberry> on one branch
[05:16] <hacklberry> int bar() {
[05:16] <hacklberry> return 0;
[05:16] <hacklberry> }
[05:17] <hacklberry> on second branch (both forked from main branch)
[05:17] <hacklberry> and then i merged into main from branch A
[05:18] <luks> so let's say some algorithm would merge them, in what other?
[05:18] <luks> foo and then bar, or the other way around?
[05:18] <hacklberry> so when merging from B i was expecting merge to pickup that the changes are different, and mark the whole
[05:18] <hacklberry> int bar() {
[05:18] <hacklberry> return 0;
[05:18] <hacklberry> }
[05:19] <hacklberry> as a block
[05:19] <luks> and it marked only the function definition, right?
[05:19] <hacklberry> so i can then manually merge in some tool like kdiff3
[05:19] <hacklberry> yes exactly
[05:19] <luks> hm
[05:20] <hacklberry> that's how i understood ' Merge is not tricked by identical changes'
[05:23] <hacklberry> "You may say I'm a dreamer, but I'm not the only one." :-)
[05:23] <luks> hm, I see
[05:24] <luks> weave merge marks only the function definitions, merge3 marks whole functions
[05:24] <luks> but isn't --merge3 the default?
[05:25] <hacklberry> i tried all 3 algorithms
[05:25] <hacklberry> but kdiff3 displayed the same
[05:27] <hacklberry> i thought that bzr uses some unique ids for every change
[05:28] <hacklberry> 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] <luks> I think the 3-way merge should do exactly that
[05:29] <luks> (and it does here)
[05:29] <hacklberry> ok i m going to try again then
[05:30] <hacklberry> i mean in the morning :-) it is 1:30am here, i live in Canberra
[06:47] <radix> whoah
[06:48] <radix> I just got a warning saying that my Python interpreter doesn't support en_US.UTF-8
[06:48] <radix> (during a bzr push)
[07:01] <radix> strangely enough, python -c 'from bzrlib.osutils import get_user_encoding; print get_user_encoding()' prints "UTF-8" with no warning
[07:03] <dato> was it a bzr push over bzr+ssh? then what matters is if the target system supports en_US.UTF-8, afaik
[07:04] <radix> ah, interesting, yes
[07:05] <radix> thanks a lot dato :)
[07:05] <dato> no problem
[07:44] <nx> LarstiQ: ping
[08:09] <synic> after a 'bzr up', how can I see what files were changed?
[08:12] <james_w> synic: do you remember what revision you were on previously? Do the command tell you how many you just got?
[08:12] <james_w> if you know then bzr status -r-6.. should tell you
[08:12] <james_w> another way is bzr log -v and then just read the log messages and see which files were changed.
[08:16] <synic> k
[08:28] <jelmer> synic: we also plan to let it output the changes in the future, unless -q is specified
[08:47] <synic> jelmer: is there any way to output the changes during update with a flag?  -v maybe?
[08:50] <ubotu> 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] <bwinton> Now that's an awesome bug...
[08:52] <bwinton> bzr wtf-just-happened-there
[08:53] <jelmer> synic: Not yet
[08:56] <synic> jelmer: ok
[09:10] <Peng> 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] <Peng> Maybe just printing the old revision during those command would be good enough.
[09:10] <Peng> Like, where it says "Now on", it could say "Started at" too.
[09:40] <synic> can you checkout a specific directory in a branch?
[09:42] <Peng> synic: No.
[09:46] <mtaylor> anybody know what the status of the visual studio plugin - https://launchpad.net/bzr-visualstudio - is?
[09:50] <nx> mtaylor: yep
[09:50] <nx> I'm the developer
[09:51] <mtaylor> nx: cool. is it ready for people to use/poke at?
[09:52] <nx> go ahead. it's still lacking some features, but those that are implemented should work well
[09:52] <mtaylor> nx: sweet. I'll give it a spin then
[09:52] <mtaylor> nx: should I branch trunk ?
[09:53] <nx> banquet.status is the latest code
[09:53] <nx> I haven't managed to create an installer yet; you'll need to have the VSSDK installed to run from the branch
[09:54] <mtaylor> ok. I think I've got that installed on this box
[10:00] <mtaylor> nx:  when I try to open the .sln file, I get errors about not being able to open the Project files...
[10:02] <nx> what's the exact error message? do you have the SP1 installed?
[10:03] <mtaylor> nx: Unable to read the project file 'Banquet.csproj'
[10:03] <mtaylor> nx: but I might not have sp1 installed. let me check
[10:04] <nx> right, i forgot you need to set a environment variable named VisualStudioIntegration that points to the VisualStudioIntegration directory in the VSSDk directory
[10:04] <nx> sorry
[10:05] <nx> or just open the csproj file and replace $(VisualStudioIntegration) with that path
[10:05] <mtaylor> ah, ok
[10:11] <bwinton> Has anyone here run bzr on Python 3.0 yet?
[10:12] <radix> aggggggggggh
[10:12] <radix> it's already started
[10:12] <dato> hahaha
[10:13] <bwinton> Hey, give me some credit.  I've had the 3.0a1 announcement page sitting in my browser since 9:00 this morning!
[10:13] <radix> we are doomed, Guido has killed us all
[10:13] <bwinton> Heh.  I think you're thinking of Python 4000, with sys.kill_us_all()...
[10:13] <radix> bwinton: it is impossible to run most existing Python code on python 3
[10:14] <bwinton> Sure, but the 2to3 tool gets you part (most?) of the way there.  I was wondering how far it got bzr...
[10:14] <radix> ah. ok. so really you wanted to ask if anybody has ported bzr to python 3 yet :-)
[10:15] <bwinton> radix: If you want to be technical about it...  ;)
[10:15] <bwinton> 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.
[11:44] <lifeless> LarstiQ: ping