| abentley | lifeless: So you're saying lines are evil? | 12:06 |
|---|---|---|
| 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:09 |
| === abentley was kidding | ||
| lifeless | oh right ;) | 12:10 |
| 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:11 |
| lifeless | hg seem to delta on bytes | 12:12 |
| abentley | I suppose binary delta compression could work. | 12:12 |
| 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:13 |
| 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:15 |
| === james_w_ [i=jw2328@jameswestby.net] has joined #bzr | ||
| 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:16 |
| 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:17 |
| lifeless | get_matching_blocks is whitespace-ignoring specific right ? | 12:18 |
| abentley | No, it's generic. It's what we use for everything. | 12:18 |
| 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:19 |
| 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:21 |
| abentley | Or annotate, for that matter. | 12:22 |
| lifeless | presumably via composition of these regions | 12:22 |
| abentley | Yes. | 12:22 |
| lifeless | I'll think about this some | 12:23 |
| 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:24 |
| abentley | While it's nice to be fast, it doesn't have to be as fast as fulltext access. | 12:25 |
| 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:26 |
| abentley | So possibly storing get_matching_blocks regions is better than caching annotations. | 12:28 |
| lifeless | it would be less data for sure | 12:30 |
| 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:31 |
| 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:33 |
| abentley | There is the reannotate code, though. | 12:34 |
| abentley | That should do the trick. | 12:34 |
| abentley | It annotates from parents to children, not from children to parents. | 12:35 |
| === jml [n=jml@ppp121-44-221-92.lns1.hba1.internode.on.net] has joined #bzr | ||
| 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:37 |
| abentley | And for merge purposes, you could start at a common ancestor. | 12:38 |
| abentley | But if you want the full annotation with no cache, you have to go through history anyway. | 12:39 |
| lifeless | yes full history all sides | 12:41 |
| lifeless | with the potential to stop early if we go from child -> parent | 12:42 |
| === james_w [i=jw2328@jameswestby.net] has joined #bzr | ||
| === BryceLeo [n=bryce@nj-71-48-102-108.dhcp.embarqhsd.net] has joined #bzr | ||
| BryceLeo | anyone had a problem installing the new bzr via synaptic in ubuntu? | 12:57 |
| BryceLeo | feisty fawn if it matters | 12:58 |
| abentley | Well, there was a problem reported this morning, but I'm unclear whether it applies to Feisty. | 12:59 |
| abentley | Does it say "error in control file: `Files' value not specified"? | 01:00 |
| BryceLeo | yup | 01:02 |
| BryceLeo | i think i've got a fix | 01:02 |
| BryceLeo | yup it's super simple | 01:02 |
| BryceLeo | let me pasebin it right quick | 01:03 |
| lifeless | BryceLeo: fixed packages are already building | 01:04 |
| BryceLeo | awesome | 01:10 |
| BryceLeo | well i've got a patch if anyone wants it now | 01:10 |
| BryceLeo | haha now if only you guys could fix why the python binding for gtkmozembed crashes with https | 01:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| Peng | Oh, GzipFile does say it defaults to 9. | 01:15 |
| === Peng wanders off. | ||
| abentley | That doesn't explain why it's so slow for decompression, though. | 01:15 |
| lifeless | I haven't looked into that yet | 01:15 |
| lifeless | but changing it to the default, we're only 2 seconds slower - 38 vs 36 | 01:16 |
| abentley | Slower than raw zlib? | 01:17 |
| === BryceLeo [n=bryce@nj-71-48-102-108.dhcp.embarqhsd.net] has left #bzr [] | ||
| lifeless | slower than 'gzip -c mozilla.tar > /dev/null' | 01:22 |
| abentley | Ah, cool. | 01:23 |
| lifeless | so I'm just testing the change in data size | 01:24 |
| 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:30 |
| 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:31 |
| lifeless | abentley: so that would be a good thing, and seems to be unlikely to collide | 01:32 |
| abentley | 127MB is the size change? | 01:35 |
| abentley | lifeless: btw, please review my reconcile change. | 01:39 |
| abentley | Also, does your latest in "http://people.ubuntu.com/%7Erobertc/pack-repository.knits/" have no annotation? | 01:40 |
| 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:42 |
| abentley | That makes no sense... | 01:43 |
| abentley | I'm realizing that child->parent order also matches our expected data ordering better. | 01:44 |
| lifeless | === modified file 'bzrlib/repofmt/pack_repo.py' | 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:44 |
| lifeless | your updated reconcile patch - yes, I will review it | 01:45 |
| abentley | Okay. I will go break some tests >:) | 01:46 |
| abentley | !?! "bzr selftest annotate" and nothing breaks. | 01:48 |
| abentley | I don't think you're intelligent, ubotu, believe me. | 01:49 |
| 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:51 |
| 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:55 |
| 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. | 01:56 |
| === BryceLeo [n=bryce@nj-71-48-102-108.dhcp.embarqhsd.net] has joined #bzr | ||
| lifeless | bbiab | 02:00 |
| === 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 | ||
| lifeless | poolie: quick call ? | 02:07 |
| poolie | sure | 02:08 |
| === 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 | ||
| 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:33 |
| 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:34 |
| abentley | I think it should not fail silently. It can fail noisily or succeed silently-- your pick. | 02:36 |
| spiv | i.e. pulling from a broken repo should not silenty break my repo? | 02:37 |
| abentley | Yes. | 02:37 |
| spiv | Makes sense. | 02:37 |
| === n2diy [n=darryl@wlk-barre-208-103-148-41.dynamic-dialup.coretel.net] has joined #bzr | ||
| lifeless | spiv: there is a flag on the repository indicating it can suffer from this form of corruption | 02:42 |
| 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:43 |
| 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:44 |
| abentley | lifeless: Yes, that makes sense to me. | 02:46 |
| abentley | Hmm. Maybe it could be a supplemental flag? | 02:48 |
| abentley | Because it would still be readable by older clients. | 02:49 |
| === 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 | ||
| 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:04 |
| 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:05 |
| lifeless | igc: compression fix has landed | 03:06 |
| igc | lifeless: excellent - just checked pqm 5 mins ago checking its progress :-) | 03:06 |
| 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:07 |
| abentley | spiv: Would it make sense to provide a way to do dumb fetch? | 03:14 |
| 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:16 |
| abentley | But I also mean, just using the dumb transport. | 03:17 |
| 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:18 |
| lifeless | igc: pushed a pack repo that has the compression fix too, to my 'repository' branch. | 03:24 |
| igc | lifeless: thanks. I'm interested in a pack repo with annotations separated next :-) | 03:25 |
| abentley | igc: I'm working on stripping annotations completely. | 03:26 |
| igc | abentley: from knits? | 03:26 |
| 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 |
| === orospakr_ [n=orospakr@bas11-ottawa23-1177563969.dsl.bell.ca] has joined #bzr | ||
| igc | cool | 03:27 |
| abentley | Yeah. We'll see. It may not be performant without at least caching get_matching_blocks. | 03:28 |
| abentley | But since we can extract that from our delta formats, who knows? | 03:31 |
| 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:32 |
| igc | lifeless: ok, I'll grab it later - just trying to get an options patch out right now | 03:33 |
| 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:34 |
| === NamNguyen [n=namnt@148.177.217.131] has joined #bzr | ||
| === bac [n=bac@canonical/launchpad/bac] has joined #bzr | ||
| 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:45 |
| 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:46 |
| lifeless | why do you say it'll be worse than hg ? | 03:47 |
| === Janzert [n=Janzert@75-134-223-54.dhcp.trcy.mi.charter.com] has joined #bzr | ||
| Peng | I don't know. | 03:47 |
| Peng | I compared it some time. | 03:47 |
| Peng | Hold on. | 03:48 |
| === orospakr_ [n=orospakr@bas11-ottawa23-1177651987.dsl.bell.ca] has joined #bzr | ||
| === p4tux [n=p4tux@189.169.92.184] has joined #bzr | ||
| Peng | .... | 03:55 |
| Peng | Hey, where can I get a copy of the repository branch new enough to access the repository branch? | 03:57 |
| abentley | http://people.ubuntu.com/%7Erobertc/pack-repository.knits/ ? | 03:59 |
| lifeless | yup | 03:59 |
| lifeless | Peng: see my dogfooding mails to the list | 03:59 |
| Peng | I didn't think that branch was up-to-date enough. | 04:00 |
| NamNguyen | abentley: what does auto_merge.py do? | 04:00 |
| === kiko-afk is now known as kiko-zzz | ||
| lifeless | Peng: I've explicitly stated that I keep it up to date enough to read the other branch | 04:00 |
| lifeless | Peng: its the bootstrap | 04:01 |
| Peng | Oh. | 04:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| Peng | Blaaah. | 04:08 |
| 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:09 |
| 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:10 |
| NamNguyen | different change | 04:11 |
| abentley | Where they branched from doesn't matter. | 04:11 |
| 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:12 |
| NamNguyen | and when this bundle is merged, is the revision id kept unchanged? | 04:13 |
| NamNguyen | its revision ids | 04:14 |
| abentley | Yes, revision ids are never altered. | 04:16 |
| 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:18 |
| abentley | Right. | 04:19 |
| 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:22 |
| lifeless | Peng: gmane has it | 04:23 |
| 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:25 |
| 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:29 |
| 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:30 |
| Peng | Bzr 0.90 was a few msec faster than the pack version in a knit branch. :P | 04:31 |
| 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:32 |
| igc | poolie: the doc usually gets updated as part of the release rollout | 04:34 |
| 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:35 |
| 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:36 |
| 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 |
| === igc lunch - bbiab | ||
| lifeless | only some get annotated | 04:37 |
| 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:38 |
| lifeless | but removing 20% overhead during commit that is only sometimes used seems like a pretty good idea | 04:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| Peng | Anyway, I'll shut up. | 04:43 |
| Peng | The change is a good idea. | 04:43 |
| === michelp [n=michelp@70.103.91.130] has joined #bzr | ||
| Peng | I just hope that you'll be able to keep annotating as fast as possible! :) | 04:43 |
| 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:46 |
| lifeless | abentley: bzr.dev :) | 04:47 |
| lifeless | abentley: I want to keep the branch as small as possible at all times | 04:48 |
| abentley | Aw, drat. I'll hafta cherrypick. | 04:48 |
| === 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 | ||
| abentley | igc: It seems as though the path must start with 'callgrind.out', not just the basename. | 05:59 |
| igc | in my code you mean? If so, I'll fix that | 06:00 |
| poolie | i'm looking into why the docs aren't visible | 06:03 |
| igc | thanks poolie | 06:03 |
| poolie | they are being built; they might not be copied to the right directory, or something like that | 06:04 |
| === orospakr [n=orospakr@bas11-ottawa23-1177651987.dsl.bell.ca] has joined #bzr | ||
| poolie | ok i think that's ok now | 06:11 |
| abentley | Awesome. Now we have a copy of NEWS to point people at. | 06:25 |
| === Chuckie_Ice [n=chuckie_@c-76-28-232-61.hsd1.wa.comcast.net] has joined #bzr | ||
| 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:27 |
| abentley | But without matching blocks for the righthand parent of merges, there are still 279 calls. And that's 40% of runtime. | 06:28 |
| lifeless | whats your test file, NEWS? | 06:29 |
| abentley | Yep. | 06:29 |
| abentley | revision 2000 | 06:29 |
| abentley | That still takes 13 seconds. | 06:29 |
| abentley | So I don't want to go higher. | 06:30 |
| 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:31 |
| 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:33 |
| lifeless | .130 to do del s[-1] , .480 to do s.pop() | 06:34 |
| 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:35 |
| 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:36 |
| poolie | lifeless, thanks for making a sid/gutsy repo | 06:39 |
| abentley | lifeless, poolie: I've started work on a NEWS-specific text merge, but no ETA on completion yet. | 06:41 |
| abentley | Annotating the latest version of NEWS takes 1m25.767. Eeps. | 06:45 |
| abentley | g'night. | 06:45 |
| 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 | 06:50 |
| === 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 | ||
| 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:02 |
| igc | poolie: yes, assuming latest means 'current release', not 'development' | 07:03 |
| 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:04 |
| 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:05 |
| poolie | can someone glance at http://bundlebuggy.aaronbentley.com/request/%3C2422be180708301335x3103b2c9mbaf318e287b4cf3b@mail.gmail.com%3E | 07:10 |
| poolie | please | 07:10 |
| beuno | please :D | 07:11 |
| beuno | btw, is bundlebuggy a custom thing? it's marvelous :D | 07:14 |
| Peng | beuno: Yes, but it's open source. | 07:17 |
| beuno | Peng, aaah, well, it's a great idea/implementation | 07:18 |
| Peng | Totally. :) | 07:18 |
| igc | poolie: that looks fine to me. I'll approve it in BB | 07:26 |
| poolie | igc, thanks | 07:30 |
| beuno | yay! does the bug close my itself in LP? | 07:30 |
| === beuno guesses "no" | ||
| poolie | which bug? | 07:30 |
| 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:31 |
| fullermd | 'bout the same ratio here. | 07:32 |
| lifeless | just the inner tuple there is tuple is 0.177 | 07:33 |
| 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:39 |
| poolie | beuno, i've just sent it off | 07:40 |
| beuno | poolie, great, thanks a bunch, I'll close the bug then | 07:41 |
| poolie | spiv, quick call? | 07:41 |
| 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:42 |
| igc | thanks | 07:43 |
| === duckx [n=Duck@tox.dyndns.org] has joined #bzr | ||
| igc | spiv: is http://bundlebuggy.aaronbentley.com/request/%3C20070826091222.GC11127@steerpike.home.puzzling.org%3E merged into the bzr.dev yet? | 08:08 |
| poolie | igc, would you like a catchup call? when were you going to finish today? | 08:09 |
| === asak| [n=alexis@lnx00.cecm.usp.br] has joined #bzr | ||
| spiv | igc: not yet, thanks for the reminder. | 08:09 |
| 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:10 |
| igc | poolie: before you go ... | 08:11 |
| igc | I'm about to do some reviews | 08:11 |
| igc | any preferences for which ones? | 08:11 |
| === aadis [n=aaditya@122.167.216.213] has joined #bzr | ||
| poolie | not in particular, though i do think doing some is a good idea | 08:16 |
| poolie | i'm just doing yours | 08:16 |
| igc | ok - I'll do the --change one from Lucas and the pre-commit hook one | 08:17 |
| === 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 | ||
| NamNguyen | igc, thanks for reviewing the patch for pre_commit hook | 09:32 |
| NamNguyen | does a commit to CommitBuilder actually commits anything? | 09:32 |
| NamNguyen | or does it only flag that a commit is done, ready to be flushed out to disk | 09:33 |
| === sverrej_ [n=sverrej@tul-1x-dhcp018.studby.uio.no] has joined #bzr | ||
| igc | few minutes - on phone | 09:36 |
| siretart | is there a spec or bug or something for the 'bzr cp' feature? | 09:44 |
| 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:45 |
| 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:46 |
| poolie | no | 09:47 |
| siretart | I imagine that it is tough, though ;) | 09:47 |
| 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:50 |
| 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:52 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| NamNguyen | alright, i'll ask him | 09:59 |
| igc | that's great - well done on your first bzr patch! | 09:59 |
| 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:00 |
| igc | Well, time to go after another good week in the wonderful world of Bazaar ... | 10:04 |
| 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:05 |
| === mrevell [n=matthew@canonical/launchpad/mrevell] has joined #bzr | ||
| poolie | night all | 10:18 |
| === 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 | ||
| mwhudson | so | 12:14 |
| === jelmer [n=jelmer@a62-251-123-16.adsl.xs4all.nl] has joined #bzr | ||
| mwhudson | is there a way to tell bzr/bzrlib to set a timeout on the sockets it creates? | 12:14 |
| === herzel [i=herzel@gateway/tor/x-e3fecb92af2d44ae] has joined #bzr | ||
| 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:15 |
| === jrydberg [n=johan@213.115.45.46] has joined #bzr | ||
| === ollie [n=orutherf@dsl092-164-022.wdc2.dsl.speakeasy.net] has joined #bzr | ||
| NamNguyen | mwhudson, with python 2.5, yes | 12:31 |
| 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:32 |
| 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:33 |
| === 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 | ||
| 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 | 12:51 |
| === 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 | ||
| ignas | hi | 02:42 |
| === 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 | ||
| hacklberry | hi, where could i get more details about bzr "smart merging"? | 04:30 |
| === z1pp1ty [n=pete@c-67-164-183-147.hsd1.co.comcast.net] has joined #bzr | ||
| 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:40 |
| === mthaddon [n=mthaddon@canonical/launchpad/mthaddon] has joined #bzr | ||
| === bwinton [n=bwinton@mail.phantomfiber.com] has joined #bzr | ||
| hacklberry | where could one get more details about bzr "smart merging"? | 04:55 |
| bwinton | Hacklberry: Google? | 05:05 |
| 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:06 |
| 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 |
| === cpro1 [n=cprov@200-171-140-32.dsl.telesp.net.br] has joined #bzr | ||
| bwinton | Sweet! Do you have a test case? | 05:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| hacklberry | on second branch (both forked from main branch) | 05:17 |
| hacklberry | and then i merged into main from branch A | 05:17 |
| 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:18 |
| 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:19 |
| hacklberry | that's how i understood ' Merge is not tricked by identical changes' | 05:20 |
| hacklberry | "You may say I'm a dreamer, but I'm not the only one." :-) | 05:23 |
| luks | hm, I see | 05:23 |
| luks | weave merge marks only the function definitions, merge3 marks whole functions | 05:24 |
| luks | but isn't --merge3 the default? | 05:24 |
| hacklberry | i tried all 3 algorithms | 05:25 |
| hacklberry | but kdiff3 displayed the same | 05:25 |
| hacklberry | i thought that bzr uses some unique ids for every change | 05:27 |
| 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:28 |
| luks | (and it does here) | 05:29 |
| hacklberry | ok i m going to try again then | 05:29 |
| hacklberry | i mean in the morning :-) it is 1:30am here, i live in Canberra | 05:30 |
| === 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 | ||
| radix | whoah | 06:47 |
| 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) | 06:48 |
| === cprov is now known as cprov-lunch | ||
| === duckx [n=Duck@tox.dyndns.org] has joined #bzr | ||
| radix | strangely enough, python -c 'from bzrlib.osutils import get_user_encoding; print get_user_encoding()' prints "UTF-8" with no warning | 07:01 |
| === asak [n=alexis@201-13-110-44.dsl.telesp.net.br] has joined #bzr | ||
| dato | was it a bzr push over bzr+ssh? then what matters is if the target system supports en_US.UTF-8, afaik | 07:03 |
| radix | ah, interesting, yes | 07:04 |
| radix | thanks a lot dato :) | 07:05 |
| dato | no problem | 07:05 |
| === 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 | ||
| nx | LarstiQ: ping | 07:44 |
| === pete__c [n=pete@015-823-542.area5.spcsdns.net] has joined #bzr | ||
| === synic [n=squish@pdpc/supporter/student/synic] has joined #bzr | ||
| synic | after a 'bzr up', how can I see what files were changed? | 08:09 |
| 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:12 |
| synic | k | 08:16 |
| === 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 | ||
| jelmer | synic: we also plan to let it output the changes in the future, unless -q is specified | 08:28 |
| === 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 | ||
| synic | jelmer: is there any way to output the changes during update with a flag? -v maybe? | 08:47 |
| 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:50 |
| bwinton | Now that's an awesome bug... | 08:52 |
| bwinton | bzr wtf-just-happened-there | 08:52 |
| jelmer | synic: Not yet | 08:53 |
| synic | jelmer: ok | 08:56 |
| 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:10 |
| === 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 | ||
| synic | can you checkout a specific directory in a branch? | 09:40 |
| === orospakr [n=orospakr@132.213.238.4] has joined #bzr | ||
| Peng | synic: No. | 09:42 |
| === mtaylor [n=mtaylor@dsl231-061-195.sea1.dsl.speakeasy.net] has joined #bzr | ||
| mtaylor | anybody know what the status of the visual studio plugin - https://launchpad.net/bzr-visualstudio - is? | 09:46 |
| nx | mtaylor: yep | 09:50 |
| nx | I'm the developer | 09:50 |
| mtaylor | nx: cool. is it ready for people to use/poke at? | 09:51 |
| 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:52 |
| 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:53 |
| mtaylor | ok. I think I've got that installed on this box | 09:54 |
| mtaylor | nx: when I try to open the .sln file, I get errors about not being able to open the Project files... | 10:00 |
| nx | what's the exact error message? do you have the SP1 installed? | 10:02 |
| === Janzert semi, sorta remembers running into issues with hardcoded absolute paths | ||
| 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:03 |
| 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:04 |
| nx | or just open the csproj file and replace $(VisualStudioIntegration) with that path | 10:05 |
| mtaylor | ah, ok | 10:05 |
| bwinton | Has anyone here run bzr on Python 3.0 yet? | 10:11 |
| radix | aggggggggggh | 10:12 |
| radix | it's already started | 10:12 |
| dato | hahaha | 10:12 |
| 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:13 |
| 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:14 |
| 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. | 10:15 |
| === 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 | ||
| lifeless | LarstiQ: ping | 11:44 |
| === 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 [] | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!