| lifeless | ok, this makes performance tolerable, just fixing this depth-of-query bug | 00:00 |
|---|---|---|
| lifeless | abentley: a thought, isn't 'is_ancestor()' just 'return self.heads([ancestor, descendant]) == set([descendant])' | 00:14 |
| abentley | Could be. Haven't thought of it that way. | 00:14 |
| lifeless | AFAICT it should be equally efficient | 00:15 |
| abentley | That seems right to me. | 00:16 |
| lifeless | yah it is | 00:19 |
| lifeless | and it exposes the bug in heads, because making it the same errors on the test that is_ancestor does not access all history | 00:19 |
| lifeless | :) | 00:19 |
| jauricchio | hi all! i have a couple very very basic questions about bzr. | 01:18 |
| jauricchio | (trying to decide between bzr, darcs, and mercurial) | 01:18 |
| jauricchio | First of all... does bzr have any support for forests like Mercurial's Forest Extension? | 01:18 |
| jelmer | work is in progress to add support for nested trees (equivalent of forests as I understand it) | 01:21 |
| lifeless | superset of forests, because nested trees recurse indefinately, forests are a single construct | 01:21 |
| lifeless | where is LarstiQ anyhow ? :) | 01:22 |
| jauricchio | Second question... how well does bzr handle binary files? | 01:22 |
| jauricchio | (pdfs, icky-word-processor documents, images... up to about 5mb) | 01:23 |
| jelmer | lifeless: he had problems with his internet connection after his holidays | 01:23 |
| jelmer | lifeless: haven't spoken to him in a couple of weeks | 01:24 |
| igc | bbiab | 01:26 |
| lifeless | jauricchio: binaries are fine | 01:26 |
| lifeless | jauricchio: they can be a bit slow to diff; but other than that we just preserve them as-is. | 01:26 |
| jauricchio | lifeless: Does bzr diff magically avoid unchanged files? | 01:28 |
| jelmer | lifeless, did you see my discussion with aaron on dirstate-with-subtree? do you think now be a good moment to encourage packs-with-subtree over packs-without-subtree? | 01:28 |
| lifeless | jelmer: no, I didn't. | 01:28 |
| lifeless | jauricchio: what do you mean? If you mean, do unchanged binaries make 'bzr st' and 'bzr diff' slow - no they don't | 01:29 |
| jauricchio | Yeah that was the question. | 01:29 |
| jauricchio | So slowness is only incurred when the file is actually changed | 01:30 |
| jauricchio | that's good :) | 01:30 |
| lifeless | if you touch the file we sha it | 01:30 |
| lifeless | if the sha is different we will diff it | 01:30 |
| lifeless | (roughly). There are some tweaks in different circumstances. | 01:30 |
| jauricchio | makes sense. | 01:30 |
| Vantage13 | Workflow question. Let's say I'm a developer working on multiple features for a release of a projects. So I make a branch of our most recent version to record my changes that will go into the next release. Now let's say I've got 5 features I'm adding. I get them done, commit them all locally, but then let's say a feature gets pulled. Is there a way to identify code belonging to a feature so that it can be easily added/removed without creating a b | 01:31 |
| lifeless | Vantage13: your sentence is being truncated | 01:32 |
| lifeless | Vantage13: 'without creating a b | 01:32 |
| lifeless | 10:32 < l | 01:33 |
| lifeless | ' | 01:33 |
| Vantage13 | without creating a branch for every feature? | 01:33 |
| Vantage13 | or how do people usually handle this scenario? | 01:35 |
| jauricchio | I think you wanted to create a branch for every feature. Branches are cheap. :) | 01:35 |
| Vantage13 | jauricchio: branches are, but working trees are not. Currently our code base is about 2GB, so 5 working trees would be 10GB of space per developer... | 01:36 |
| jauricchio | Hm... fair enough. (That's a *lot* of code, man...) | 01:36 |
| jauricchio | Darcs would call this a "spontaneous branch". Prefix your commit messages with something, and you can work with 'all patches prefixed with (matching) some text' | 01:37 |
| lifeless | Vantage13: there is a 'switch' command in bzrtools | 01:38 |
| Vantage13 | the one thing I thought might deal with this would be using a shared repo and doing a bzr switch for each feature. So switch to main version, branch feature1, commit, switch back to main version, branch feature2, commit, switch back, etc. Then merge them all later... | 01:38 |
| lifeless | Vantage13: this lets you transform a working tree from branch A to branch B quite cheaply | 01:39 |
| Vantage13 | lifeless: exactly what I was thinking | 01:39 |
| Vantage13 | lifeless: does what I described sound right? | 01:39 |
| lifeless | yup | 01:41 |
| Vantage13 | lifeless: Is there a way to 'switch' and create a branch at the same time? e.g. switch back to main after feature1, then create a branch for feature2 in the same working tree, then switch to it? (to avoid having to create a second working tree at all) | 01:42 |
| lifeless | Vantage13: why would you create a second working tree? | 01:47 |
| Vantage13 | lifeless: I wouldn't want to. I'd just want to create a branch and switch to it from my current working tree (which would be on the main branch) | 01:48 |
| Vantage13 | lifeless: I'm wondering if I can do that without creating another working tree | 01:48 |
| lifeless | Vantage13: 'bzr branch main new-branch && bzr switch new-branch' | 01:48 |
| lifeless | won't create a working tree unless your repository is configured to make a working tree | 01:48 |
| lifeless | so just disable creating working trees | 01:49 |
| Vantage13 | lifeless: ah... | 01:49 |
| jauricchio | So, another question. Suppose I have a directory within a repo. I'd like to pull it out of the repo with all changes applicable to it, and make a new repo containing only it. With leading pathnames removed. | 01:51 |
| jauricchio | That is, projects is my repo. I want to take projects/foo/baz and make a new repo containing the contents of baz with all history. | 01:52 |
| jauricchio | With baz as the top level of the new repo | 01:52 |
| Peng | jauricchio: I think "hg transplant" could do that (or at least do the reverse, moving baz into project/foo), but I'm not sure if it preserves cset IDs. | 02:00 |
| Peng | jauricchio: I don't know of a way for bzr. | 02:00 |
| jauricchio | It's okay if cset IDs are lost | 02:01 |
| jauricchio | My use case is, I've been working on this little baby project that didn't deserve its own repo. Then I decide it does and I want to share it with the world. | 02:01 |
| lifeless | Peng: answering questions here with 'hg can do X' isn't exactly helpful. | 02:04 |
| lifeless | jauricchio: 'bzr split' can do that | 02:04 |
| jauricchio | lifeless: /me checks docs | 02:05 |
| Peng | lifeless: Heh, sorry. :P | 02:05 |
| lifeless | Peng: You're more than welcome to say things like 'packs at 10% faster for me, but you're still 40% slower'. Thats extremely useful to know. | 02:05 |
| jauricchio | lifeless: 'split' not found in the user reference at doc.bazaar-vcs.org | 02:06 |
| lifeless | jauricchio: 'bzr help split'. | 02:06 |
| jauricchio | not installed currently :\ | 02:06 |
| lifeless | ah. Well then. We have the feature. | 02:06 |
| jauricchio | :) cool | 02:06 |
| lifeless | and naturally we're expanding on it and improving it as time goes by. | 02:07 |
| jauricchio | of course | 02:07 |
| jauricchio | ok, thanks for your help lifeless, Peng, and jelmer. bzr looks to be what i need! | 02:09 |
| jauricchio | bye | 02:09 |
| Peng | Cool. | 02:09 |
| lifeless | Peng: speaking of which, are you still dogfooding packs from time to time ? | 02:10 |
| lifeless | jelmer: so do you mean bug 131667 ? | 02:12 |
| ubotu | Launchpad bug 131667 in bzr "--dirstate-with-subtree is documented in the man page" [Medium,Fix committed] https://launchpad.net/bugs/131667 | 02:12 |
| jelmer | yes | 02:12 |
| lifeless | I would love someone to sit down and take on the patch | 02:13 |
| lifeless | larstiq was working on it but hes disappeared | 02:13 |
| lifeless | the patch to make nested-by-reference trees robust | 02:13 |
| poolie | lifeless, hi, so to check that plan: | 02:13 |
| lifeless | this is what is needed to make -subtrees a default format and trigger the format bump | 02:13 |
| poolie | - make new knit repo containing bzr.dev | 02:13 |
| poolie | - reconcile that. | 02:13 |
| poolie | - make a new pack repo | 02:13 |
| poolie | - pull bzr.dev from the first repo | 02:14 |
| poolie | - pull packs branch | 02:14 |
| lifeless | (or bzr upgrade --experimental in the reconciled repo) | 02:14 |
| lifeless | but yes, thats the right list | 02:14 |
| Peng | lifeless: I keep a copy of bzr.dev and repository in pack format and pull and diff frequently, but that's the extent of my dogfooding. | 02:19 |
| lifeless | ok | 02:20 |
| Peng | FWIW, I never reconciled it. | 02:20 |
| lifeless | did you try the C sequence matcher thing ? | 02:20 |
| lifeless | which speeds up diff, and would AIUI make your home dir versioning tolerable or even pleasant | 02:20 |
| Peng | lifeless: I switched it over to hg before I found out about that, and I've never gotten around to trying it. | 02:22 |
| Peng | Hmm. I could right now, but Firefox is hogging so much RAM it wouldn't be remotely accurate. | 02:22 |
| lifeless | thats fine, don't worry about it | 02:22 |
| Peng | Mozilla should pay me for all the RAM upgrades I have to do for Firefox. | 02:25 |
| lifeless | less tabs++ :) | 02:25 |
| Peng | Yeah. | 02:25 |
| Peng | Less Flash++ too. | 02:25 |
| Peng | That's what's really killing it. | 02:25 |
| lifeless | poolie: how is it going ? | 02:37 |
| poolie | reconciling again | 02:37 |
| poolie | i may skip that as i'm pretty sure i did that in the same repo on friday | 02:37 |
| * Peng sighs. | 02:42 | |
| poolie | switching terminals | 02:42 |
| Peng | Firefox froze right before I was going to shut it down. | 02:43 |
| lifeless | :( | 02:45 |
| Peng | Hmm. I should probably just cp instead of using "bzr branch". | 02:51 |
| lifeless | abentley: you're bouncing | 03:00 |
| abentley | Yes. Sorry. | 03:08 |
| abentley | Updated to gutsy, and it's giving me probs. | 03:08 |
| lifeless | :( | 03:10 |
| Peng | Uh-ohs. | 03:12 |
| Peng | Branching the pack version of my homedir crashed with a KnitCorrupt error. | 03:12 |
| Peng | But I think that branch might be older than the most recent pack format. | 03:12 |
| lifeless | yes, you probably have annotated knit data in it | 03:13 |
| Peng | Yeah. | 03:13 |
| Peng | Yeah, I think it might be like the very first revision it's saying is corrupt. | 03:13 |
| Peng | Or, the first file. | 03:14 |
| * Peng watches the progress bar. | 03:20 | |
| === kiko-fud is now known as kiko-zzz | ||
| Peng | A 700 MB .pack file. That scares me. | 03:24 |
| Peng | It was 743 MB with annotations, now it's 712. | 03:25 |
| lifeless | thats cause you have a lot of data with lots of changes | 03:29 |
| Peng | Well yeah. But I'm afraid of it. | 03:30 |
| ubotu | New bug: #155629 in bzr "newly-created dirstate file appears blank on curlftpfs filesystem" [Undecided,New] https://launchpad.net/bugs/155629 | 03:30 |
| Peng | One little bit out of 6 billion could be wrong. | 03:31 |
| lifeless | no different to have many 10M files | 03:32 |
| Peng | lifeless: With 0.91 with Pyrex and dirstate, real time is 3m9.784s, user is 2m56.132s, sys is 0m10.781s. That might be like a 20 or 30 second improvement. | 03:32 |
| lifeless | Peng: how many files are there there ? | 03:33 |
| Peng | lifeless: Uhh. A lot. | 03:33 |
| lifeless | Peng: and are you committing a merge, or just a regular commit ? | 03:33 |
| lifeless | Peng: and finally, had you just added new files before the commit ? | 03:34 |
| Peng | lifeless: What command tells me the total number of files? | 03:35 |
| lifeless | bzr inventory | wc -l | 03:35 |
| Peng | lifeless: 4695. | 03:36 |
| Peng | lifeless: In that commit, 39 files changed. Not a merge, and no new files. | 03:36 |
| lifeless | had you run bzr add? | 03:36 |
| lifeless | (bzr add in 0.91 destroys the stat cache) | 03:37 |
| Peng | lifeless: Nope. | 03:37 |
| Peng | lifeless: uncommit, maybe a status or two, then commit. | 03:37 |
| lifeless | thanks | 03:37 |
| lifeless | thats very slow compared to my current results with packs, which is encouraging | 03:38 |
| Peng | I'm testing packs right now. | 03:38 |
| Peng | BTW, hg is like 30 seconds. ;P | 03:39 |
| lifeless | yah | 03:39 |
| Peng | Also, I caught it at up to ~355 MB of RAM, and I bet it was bigger at other times. | 03:40 |
| Peng | Wow. | 03:40 |
| Peng | real 1m44.768s | 03:41 |
| Peng | user 1m37.652s | 03:41 |
| Peng | sys 0m5.437s | 03:41 |
| Peng | Packs *are* faster. | 03:41 |
| Peng | The new .pack file is 726 KB. | 03:41 |
| lifeless | hmmm, not that much faster | 03:42 |
| lifeless | I'd love it if you could repeat that | 03:42 |
| Peng | Just run it again? | 03:42 |
| lifeless | with --lsprof-file foo.callgrind | 03:42 |
| lifeless | then gzip the callgrind file and mail it to me | 03:42 |
| Peng | Gack. | 03:42 |
| lifeless | this won't give me anything private | 03:43 |
| lifeless | just the callgraph and timings | 03:43 |
| lifeless | so I can see where the slowness is coming from | 03:43 |
| Peng | I know. | 03:43 |
| Peng | I said "Gack." because I had just started running it again. | 03:43 |
| lifeless | ;) | 03:43 |
| lifeless | just ctrl-C it | 03:44 |
| Peng | I did. | 03:44 |
| Peng | It'll be done shortly. | 03:44 |
| lifeless | thanks! | 03:45 |
| Peng | real 2m0.958s | 03:45 |
| Peng | user 1m38.290s | 03:45 |
| Peng | sys 0m22.328s | 03:45 |
| Peng | Huh. | 03:45 |
| Peng | I would've expected user time to be higher due to lsprof. | 03:45 |
| * Peng sighs. | 03:47 | |
| ubotu | New bug: #155632 in bzr "KeyError: 77 in pycurl_errors.errorcode" [Undecided,New] https://launchpad.net/bugs/155632 | 03:51 |
| lifeless | poolie: how goes it ? | 03:53 |
| Peng | lifeless: What's your email address? | 03:53 |
| lifeless | robert at ubuntu | 03:59 |
| Peng | Blaah, you have more email addresses than I do. | 04:01 |
| Peng | ubuntu.com? | 04:01 |
| lifeless | yah | 04:01 |
| poolie | lifeless, i think that's the same error i saw on friday | 04:01 |
| poolie | so | 04:02 |
| Peng | Wasn't it @canonical.com two months ago? | 04:02 |
| lifeless | yes | 04:03 |
| lifeless | its there too | 04:03 |
| lifeless | you coulda use the prior address :) | 04:03 |
| Peng | I'll send it in a second. | 04:06 |
| Peng | Sent. | 04:09 |
| lifeless | Peng: thanks | 04:15 |
| lifeless | Peng: 67% is in get_content_maps | 04:17 |
| lifeless | Peng: which is building up the copy of the the text to diff against | 04:17 |
| lifeless | 10% in IO | 04:17 |
| lifeless | we can't reduce that much | 04:17 |
| lifeless | actually, 5% | 04:17 |
| lifeless | 5% parsing the deltas from disk | 04:18 |
| lifeless | ohfuckme | 04:19 |
| lifeless | Peng: I can see an easy 17% win | 04:19 |
| lifeless | we're memory copying stuff we don't need to, because of a general 'get many versions' function | 04:19 |
| lifeless | Peng: if you look at bzrlib/knit.py | 04:20 |
| lifeless | Peng: the function get_content_maps | 04:20 |
| ubotu | New bug: #155637 in bzr "patch confict should be an internal error" [Low,Confirmed] https://launchpad.net/bugs/155637 | 04:20 |
| lifeless | see the coyp() calls in there - there are two I think. Guard them with e.g. 'if multiple_versions:' | 04:20 |
| lifeless | and at the top of the function do | 04:21 |
| lifeless | multiple_versions = 1 != len(version_ids) | 04:21 |
| lifeless | this should save 17% trivially. | 04:21 |
| Peng | lifeless: Cool. | 04:24 |
| Peng | Hold on. | 04:24 |
| Peng | lifeless: _get_content_maps? | 04:25 |
| lifeless | yah | 04:26 |
| lifeless | line 1000 in my knit.py | 04:26 |
| Peng | Exactly 1000? | 04:27 |
| Peng | Anyway, done. | 04:27 |
| Peng | lifeless: Want a new callgrind file? | 04:28 |
| lifeless | nah, just run it without callgrind and see if it helps | 04:30 |
| Peng | Well, I ran it with callgrind and it helped. | 04:30 |
| Peng | Uhm. | 04:30 |
| Peng | 56 seconds vs. 1m38s. | 04:30 |
| lifeless | great | 04:31 |
| Peng | Yeah. | 04:31 |
| lifeless | theres another win of the same size in _apply_delta | 04:31 |
| lifeless | in the same file | 04:31 |
| lifeless | will be a little more tricky to fix that without leading to bugs | 04:31 |
| lifeless | I'll do both today though | 04:31 |
| Peng | I helped make Bazaar faster. Cool. | 04:32 |
| lifeless | yup | 04:33 |
| Peng | Well, I'd be happy to re-run it in the future if you ever want me to. | 04:36 |
| lifeless | tomorrow probably ;) | 04:36 |
| lifeless | and thanks | 04:36 |
| Peng | Heh, okay. | 04:37 |
| * ig1 food | 05:15 | |
| poolie | lifeless, ping? | 05:52 |
| lifeless | hi | 05:53 |
| ig1 | so lifeless, 3 patches today (so far) - what order do you want them reviewed in if any? | 05:54 |
| lifeless | don't care about order | 05:55 |
| lifeless | just about completeness | 05:55 |
| lifeless | FIFO is fine | 05:55 |
| lifeless | and probably best | 05:55 |
| ig1 | ok - I'll start with the tests one now | 05:55 |
| lifeless | oh that one can be ignored | 05:55 |
| lifeless | leave it till later | 05:55 |
| ig1 | that's why I asked :-) | 05:56 |
| ig1 | graph.heads then | 05:56 |
| === AnMaster_ is now known as AnMaster | ||
| poolie | i've turned my check-knits branch into a plugin | 06:36 |
| poolie | it's faster than a full check (because it does less) | 06:37 |
| poolie | it may be useful | 06:37 |
| lifeless | ig1: how is the review going ? | 06:40 |
| ig1 | getting there ... | 06:41 |
| ig1 | haven't looked at the graph code before | 06:41 |
| ig1 | you have an import pdb but onothing else stands out so far | 06:41 |
| ig1 | s/onothing/nothing/ | 06:42 |
| lifeless | do I? oh foo | 06:42 |
| ig1 | in test_graph.py | 06:42 |
| ig1 | also 2 lines immediately before run_heads_break_deeper ... | 06:43 |
| ig1 | otherwise tests look good | 06:43 |
| lifeless | is that 'merge it' | 07:01 |
| lifeless | or 'I'm still thinking' ? :) | 07:01 |
| ig1 | I'm still thinking - need another 20-30 minutes I think | 07:02 |
| lifeless | ig1: well, next patch is up | 07:13 |
| ig1 | ok - not thru yet to me - will check again soon | 07:14 |
| lifeless | there it goes | 07:18 |
| lifeless | Peng: 2851 | 07:20 |
| lifeless | Peng: thats the revno in repository with a bugfix to remove all three list-copies. | 07:20 |
| lifeless | Peng: it will also, incidentally, reduce memory pressure, but probably not much | 07:22 |
| poolie_ | bug 154283 | 07:58 |
| ubotu | Launchpad bug 154283 in bzr "indexerror in Knit._get_components_positions pulling in pack repo" [Undecided,New] https://launchpad.net/bugs/154283 | 07:58 |
| poolie_ | join-branches.txt-20050309044946-f635037a889c0388^@robertc@robertcollins.net-20050919060519-f582f62146b0b458^@^@1747020^M1746789^I1747020^@ 42658896 124$ | 08:12 |
| fullermd | Took the words right outta my mouth. | 08:12 |
| Lo-lan-do | You have strange things in your mouth. | 08:15 |
| fullermd | It's like that thing with the old lady who swallowed a fly. | 08:18 |
| ig1 | lifeless: that review finally mailed - few tweaks only as best I can see | 08:19 |
| Peng | lifeless: Holy crap. With callgrind, user time went from 56 seconds last time to 19. Real time was still at 56 seconds, but Firefox is open now so everything is probably laggier. Sys time went from 23s to 21s. | 08:27 |
| Peng | lifeless: Trying again, real time is down 10s and the others are down 1 or 2. | 08:28 |
| lifeless | ig1: yup, copacetic | 08:36 |
| lifeless | ig1: will do tomorrow. | 08:36 |
| lifeless | Peng: so is this good ? | 08:36 |
| ig1 | lifeless:quikc Q | 08:37 |
| ig1 | what's the idea behind the version_id param in the apply_delta API? | 08:37 |
| lifeless | Peng: what is real time sitting at without callgrind ? | 08:37 |
| lifeless | ig1: KnitContent objects have a version | 08:37 |
| === pcapriotti_ is now known as pcapriotti | ||
| lifeless | ig1: Plain ones use this for all lines; Annotated ones carry it per-line | 08:38 |
| lifeless | so the parameter is to totally transform the content object from state to state | 08:38 |
| Peng | Hold on. I'm brushing my teeth. | 08:38 |
| ig1 | and self_version_id only gets set for one, not the other, is therefore by design? | 08:39 |
| lifeless | yes | 08:39 |
| ig1 | s/self_/self._/ | 08:39 |
| ig1 | ok - thanks | 08:39 |
| mdke | I'm still playing with svn-import. Does anyone know why I'd get a "server certificate verification failed" on one gutsy computer and not on another, connecting to https://docteam.ubuntu.com/repos? | 08:40 |
| lifeless | check for /etc/ssl/ca-certificates.crt | 08:41 |
| lifeless | if its missing run update-ca-certificates | 08:41 |
| Peng | real 0m22.511s | 08:41 |
| Peng | user 0m17.378s | 08:41 |
| Peng | sys 0m2.758s | 08:41 |
| Peng | lifeless: ^ | 08:41 |
| lifeless | Peng: how does this compare to hg ? | 08:41 |
| Peng | Umm. | 08:41 |
| Peng | Very good. | 08:42 |
| Peng | well? | 08:42 |
| lifeless | thanks :) | 08:42 |
| mdke | lifeless: it was present in /etc/ssl/certs/ | 08:42 |
| mdke | I ran the update anyway, no change | 08:42 |
| Peng | Last hg one I did was: | 08:42 |
| Peng | real 0m45.080s | 08:42 |
| Peng | user 0m13.716s | 08:42 |
| Peng | sys 0m2.316s | 08:42 |
| lifeless | mdke: sorry yes thats the right place. Other than that I have no suggestions. | 08:42 |
| mdke | ok, thanks anyway | 08:42 |
| lifeless | Peng: hmm, still need to shave off lots of user time. But I knew that | 08:43 |
| mdke | lifeless: one was executed over ssh, could that make a difference? | 08:43 |
| Peng | Bzr and hg aren't committing exactly the same data. | 08:43 |
| Peng | So it's not an entirely fair comparison. | 08:43 |
| lifeless | Peng: bzr's committing less? | 08:43 |
| Peng | I don't know. | 08:43 |
| lifeless | ah | 08:43 |
| lifeless | so its roughly the same but not identical ? | 08:43 |
| Peng | Bzr is using two-month-old data. Since then, my IRC logs have grown larger, but I've also switched from Opera to Firefox. | 08:43 |
| Peng | Hm. | 08:44 |
| Peng | I think hg is about the same as it was two months ago. It used to take about 30 seconds, but I'm not sure if that was real or user time. | 08:44 |
| Peng | If it was real time, the extra time is just due to Firefox hogging RAM. | 08:44 |
| lifeless | gnight all. | 08:47 |
| Peng | Good night. | 08:47 |
| Peng | lifeless: BTW, bzr is probably committing more changes. Bzr is doing 12 hours of changes while hg is doing 1. | 09:02 |
| === Mez is now known as Mez|Away | ||
| GaryvdM | Is it possible to pull the bzr.dev branch over the bzr protocal | 09:10 |
| GaryvdM | All the docs point to http urls | 09:10 |
| poolie_ | GaryvdM, you should be able to get it from | 09:18 |
| poolie_ | bzr+ssh://bazaar.launchpad.net/~bzr/bzr/trunk | 09:18 |
| poolie_ | you need to have a launchpad account | 09:18 |
| poolie_ | we'll offer public bzr:// soon | 09:18 |
| Peng | Not to be a troll, but is bzr any less slow than http? | 09:20 |
| Lo-lan-do | I think there are fewer round-trips, so probably. | 09:21 |
| Peng | It takes a very long time to pull changes to bzr.dev. | 09:22 |
| Peng | Of course, the one time I time it, there aren't any new changes, and it takes 3 seconds. | 09:22 |
| * Peng wanders off. | 09:23 | |
| poolie_ | ok so it's | 09:29 |
| poolie_ | KnitVersionedFile(file:///home/mbp/newbzr/dest2/.bzr/repository/text%3ATestUtil.py-20050824080200-5f70140a2d938694) | 09:29 |
| poolie_ | bzr: ERROR: Revision {robertc@robertcollins.net-20050919044328-0205c679f3051340} not present in "<bzrlib.knit.KnitGraphIndex object at 0x8ef5e4c>". | 09:30 |
| indraveni | hi all | 09:34 |
| indraveni | i would like to know, whether there are any tools for viewing the bazaar content | 09:34 |
| indraveni | like for subversion we have, trac, websvn etc | 09:34 |
| Kinnison | Morning | 09:36 |
| indraveni | i would like to know, whether there are any tools for viewing the bazaar content | 09:42 |
| indraveni | like for subversion we have, trac, websvn etc | 09:42 |
| poolie_ | indraveni, yes, look at loggerhead | 09:47 |
| Peng | indraveni: There's also a bzr plugin for Trac. | 09:53 |
| GaryvdM | Peng: acording to http://weblogs.mozillazine.org/jst/archives/2007/02/bzr_and_different_network_prot.html bzr is faster than http | 09:55 |
| GaryvdM | I'm going to test it now | 09:55 |
| GaryvdM | I live in South Africa - We have slow internet connections. | 09:55 |
| GaryvdM | bzr+ssh = 12 sec | 10:00 |
| ig1 | night all | 10:00 |
| GaryvdM | http = 8.9 | 10:00 |
| GaryvdM | no changes in the tree on either | 10:00 |
| lifeless | Peng: bzr can be faster than http; packs help with this, on knits latency sucks arse. | 10:02 |
| Peng | What I wonder is how efficient bzr's smart server is, espcially compared to hg. Hg only uses a smart server, so it must have had a lot of tweaking. With bzr, the smart server is only starting to catch on. | 10:03 |
| Peng | There is that hpss stuff. | 10:04 |
| === Mez|Away is now known as Mez | ||
| ubotu | New bug: #155730 in bzr "reconcile doesn't adjust knit index references to otherwise-unreferenced file revisions" [Critical,Confirmed] https://launchpad.net/bugs/155730 | 11:06 |
| GaryvdM | On http://bazaar-vcs.org/BzrDevelopment , the Release revids have not been updated for a while | 11:45 |
| GaryvdM | How can I find out what they are for newer releases? | 11:45 |
| === Mez is now known as Mez|Away | ||
| AfC | GaryvdM: I was going to guess `bzr tags`, but somewhat astonishingly there aren't tags for releases in their 'bzr.dev' branch | 12:00 |
| fullermd | Sorry, those revids are only available to Members of the Brotherhood. | 12:00 |
| === Mez|Away is now known as Mez | ||
| GaryvdM | Who does the releases? | 12:01 |
| === kiko-zzz is now known as kiko | ||
| fullermd | Well, the releases don't come from bzr.dev. They have their own branches. | 12:01 |
| fullermd | (and bzr.dev can't have tags anyway, in its current form) | 12:01 |
| jsk | hi all: does anyone know a good method for doing "bzr pull" over an unreliable connection? | 12:02 |
| jsk | all: my connection only lasts a maximum of 12 minutes at a time, but the pull operation takes longer (because it's a big tree). | 12:02 |
| jsk | all: I'm using bzr+ssh://....... | 12:03 |
| jsk | all: I'm open to using a workaround, such as downloading the tree via HTTP, in multiple chunks. | 12:03 |
| fullermd | Well, pull saves what it gets, in some granularity. So as long as it takes you less'n 12 minutes to get a single "hunk" (probably the changes or a subset of the changes to one file, with knits), each pull should move forward. | 12:04 |
| fullermd | I tend to think "kill your network admin in his sleep" is a more satisfying solution, though. | 12:04 |
| jsk | fullermd: I'd like to do that to my ISP. | 12:05 |
| mwhudson | i think jsk would quite like to take that approach | 12:05 |
| jsk | :) | 12:05 |
| * jsk has been plotting revenge for some days now | 12:05 | |
| fullermd | Oh, ISP's even easier. You know they're all in one office ;) | 12:05 |
| fullermd | Take off and nuke the site from orbit. It's the only way to be sure. | 12:05 |
| jsk | fullermd: :) | 12:05 |
| AfC | fullermd: (bzr.dev is not tags compatible? You guys are weird) | 12:05 |
| fullermd | AfC: bzr.dev is still branch5. I think some Linux distros are still shipping 0.11, so if we updated it they couldn't access it. | 12:06 |
| AfC | Oh | 12:07 |
| fullermd | It's probably about time that it would be "OK" to make that switch these days. | 12:07 |
| Peng | Well, the default format has changed to dirstate-tags. | 12:07 |
| * AfC refrains from commenting on distros that have such lame upgrade policies, although he notes down a reminder to rant about it again when giving his next conference keynote. | 12:07 | |
| fullermd | Hasn't been any big pressure to, though. I wouldn't be too surprised if it stayed as-is until there's been a couple releases with packs, then it gets moved there. | 12:07 |
| mwhudson | like, uh, dapper ? | 12:08 |
| jsk | fullermd: So you suggest the following steps: | 12:08 |
| jsk | 1. run "bzr pull --remember bzr+ssh://..." | 12:08 |
| jsk | 2. <connection drops> | 12:08 |
| jsk | 3. <connection returns> | 12:08 |
| jsk | 4. do a ^C to kill the "bzr pull" | 12:08 |
| jsk | 5. rerun "bzr pull --remember bzr+ssh://..." | 12:08 |
| jsk | 6. repeat 2 onwards... | 12:08 |
| jsk | where "..." represents the full path | 12:08 |
| fullermd | Well, you'd only need the --remember once. But yeah, that's the best I've got. | 12:08 |
| AfC | The subsequent commands won't need --remember | 12:08 |
| jsk | fullermd: cool. I'll give it a try. thanks :) | 12:08 |
| * jsk resumes his plotting... | 12:08 | |
| AfC | fullermd: you know, that's not the sort of environment that I would have thought about, but I am curious how the packs modality will work in the face of partial transfers. | 12:10 |
| fullermd | Well, with a buttload fewer round trips, there's a good chance packs will get done sufficiently quicker that you wouldn't have to many mid-flight disconnects. | 12:11 |
| fullermd | The individual hunks to download and save would probably be bigger, so I s'pose that with a sufficiently high disconnect rate and low bandwidth, you might get stuck never making any progress with packs, where knits would inch along. But that's pretty pathological. | 12:11 |
| jsk | (about to be disconnected) | 12:12 |
| fullermd | In that case, the answer is probably "keep trying to pull until the smart server gets sufficiently smart and the server upgrades" ;) | 12:13 |
| fullermd | 'course, with sufficiently pathological conditions, that solution probably won't work either. | 12:14 |
| fullermd | Your hunks would just be too large to move in the bandwidth/time available. | 12:14 |
| VSpike | Hi guys ... just about to try and migrate from Perforce to bzr, and wanted to double check I'm doing the right thing, so may run some things by you all in the next few minutes | 12:20 |
| VSpike | At the moment, I just need to share development between two of my machines, but eventually I may need to open this up to some of the company's clients, so the "Decentralized with human gatekeeper" model will come into play | 12:23 |
| VSpike | To start, I'm going to pull my last stable version out of perforce and check it in as a head revision, and then the latest code in my two development branches, and check those in as branches to the head revision. I don't need to pull across all the perforce history (which is good, because I probably can't) | 12:25 |
| VSpike | I was just trying to figure out if I should have a shared repository with trees or without | 12:28 |
| VSpike | I guess because the desktop machine is both my fileserver and workstation, with trees makes sense... does that seem reasonable? | 12:28 |
| GaryvdM | Yes | 12:28 |
| fullermd | Well, on the one hand, it doesn't matter. You can change it around trivially later. | 12:28 |
| VSpike | fullermd: thanks, that's useful to know | 12:29 |
| fullermd | But yah, going with trees now would be the easy thing to do (unless the trees are so big it'll cause issues), since you can blow them away and disable them by default later. | 12:29 |
| Peng | VSpike: You might be able to convert from p4 to bzr without losing history... | 12:29 |
| VSpike | Peng: I quite like the idea of a clean start - then I can lay out the repository in a more logical way than the rather haphazard one I have in perforce | 12:30 |
| === AfC is now known as AfC|dinner | ||
| GaryvdM | If I have a branch object, how do get the bzrdir object? | 12:31 |
| GaryvdM | Ah - branch.base | 12:33 |
| === jsk__ is now known as jsk | ||
| mwhudson | branch.bzrdir, isn't it? | 12:35 |
| GaryvdM | mwhudson: yes | 12:39 |
| GaryvdM | thanks | 12:40 |
| jsk_ | fullermd: thanks for your help earlier. I think I'll have to try a different method. My connection windows are 12 minutes long, and this doesn't seem sufficient for a "bzr pull" to get to the stage where it has committed anything to disk (the contents of .bzr do not change during this time, despite the network traffic and RAM usage increasing). | 12:53 |
| jsk_ | fullermd: after a full 11 minutes, the "bzr pull" is still at Pull Phase 0/2 | 12:54 |
| fullermd | Bleh. | 12:54 |
| fullermd | Well, that part doesn't mean too much by itself. I think 90% of pull's time is in phase 0 (that 0-based numbering still bugs me) | 12:55 |
| jsk_ | computer scientists... | 12:55 |
| jsk_ | :) | 12:55 |
| fullermd | Well, it's inconsistent too, I think. The /2 means there are 2 phases, and they're called 0 and 1. So when it's doing its last byte, it's on phase 1/2. | 12:57 |
| jsk_ | fullermd: I do have ssh access to the server hosting the branch (at the other end of my connection). Perhaps I could create a tar of the branch, and download it in chunks. | 12:57 |
| jsk_ | fullermd: however, I'm not sure if this method will create a working local branch. | 12:58 |
| jsk_ | fullermd: +1 on your suggestion to revise the numbering... | 12:59 |
| GaryvdM | After you have download the branch, you can do bzr checkout to create a working tree. | 12:59 |
| jsk_ | GaryvdM: that sounds like a good idea. However, I'm hoping to run a "bzr pull --remember" on the local branch, to tie it up with the remote one. | 13:01 |
| jsk_ | GaryvdM: I'm hoping that this operation will complete quickly. | 13:01 |
| jsk_ | GaryvdM: and not take as long as it would with an newly "bzr init"-ed directory. | 13:01 |
| jsk_ | GaryvdM: thanks for your help :) | 13:02 |
| Edulix | hi | 13:02 |
| Edulix | I get this | 13:02 |
| Edulix | edulix@edulix-laptop:~/descargas/dark-extermination$ bzr push sftp://edulix@bazaar.launchpad.net/~edulix/dark-extermination/trunk | 13:02 |
| Edulix | Permission denied (publickey). | 13:02 |
| Edulix | bzr: ERROR: Unable to connect to SSH host bazaar.launchpad.net; EOF during negotiation | 13:02 |
| fullermd | jsk_: Well, you could rsync too (as long as you're sure your destination doesn't have stuff that needs to be not be overwritten) | 13:03 |
| AfC|dinner | fullermd: he's pulling | 13:04 |
| AfC|dinner | jsk_: rsync would be ideal for this situation | 13:04 |
| AfC|dinner | [I used to use rsync to *push* until the bzr server came along] | 13:04 |
| vila | jsk_: have you tried bzr pull http+urllib:// ? It may be longer but urllib implementation should reconnect automatically on transient errors | 13:07 |
| === mrevell is now known as mrevell-lunch | ||
| matkor | In checkouted tree I can see parent branch: /home/users/arekdydo/src/abbon/abbon2 which is wrong, how can I change it to proper value ? | 13:14 |
| fullermd | AfC|dinner: ? I know, but what's that matter? | 13:15 |
| AfC|dinner | fullermd: yeah, sorry, you're right. | 13:16 |
| vila | Edulix: check that you published your ssh key on launchpad | 13:19 |
| matkor | unbind / bind does not set parent branch it keeps on bugus value ... | 13:24 |
| fullermd | Parent branch is set/used by pull/merge/missing... maybe others I forget? | 13:25 |
| fullermd | If you don't need those to default to anything in particular though, it doesn't really matter (except cosmetically) if the given value is nutty, though. | 13:26 |
| matkor | fullermd: Ah ! I can set it by bzr pull --remember | 13:32 |
| matkor | Thanks | 13:32 |
| VSpike | I know this is a bit OT, but how tightly wedded is Visual Studio to its \Projects, \Websites layout? I'm wondering if I can make it play nicely with a head/project1, head/project2, etc.. layout... does anyone have experience? | 13:34 |
| === mrevell-lunch is now known as mrevell | ||
| === RichardL__ is now known as rml | ||
| sabdfl | hey guys | 14:07 |
| === AfC|dinner is now known as AfC | ||
| vila | jsk_: you're bouncing :) Did you succeed with your push-inside-a-network-shutting-down-every-12-minutes ? | 14:37 |
| vila | pull even | 14:37 |
| vila | sabdfl: hi, just passing around or heard about lifeless wonders ? :) | 14:39 |
| sabdfl | vila: i hear there are wonders in the works, what's the latest news? | 14:39 |
| vila | Peng: can you summarize your last experiments with the pack format to sabdfl ? | 14:40 |
| sabdfl | oh, i saw that bit :-) | 14:41 |
| vila | sabdfl: :) | 14:41 |
| sabdfl | very cool indeed! | 14:41 |
| vila | yup, very encouraging | 14:43 |
| jsk_ | vila: thanks! I did succeed in the end - but only by zipping up the remote branch and downloading it in small chunks. After reconstituting the branch locally, I was able to do a "bzr pull --remember..." followed by two successive "bzr pull" operations to get the branch synced with its parent. | 15:07 |
| jsk_ | vila: (two successive operations were necessary as the first "bzr pull --remember" got cut off by the network going AWOL). | 15:07 |
| vila | jsk_: just for completeness, I'd be interested if you an try a bzr pull http+urllib:// in a temp directory to test the transient error handling | 15:10 |
| vila | s/an/can/ | 15:10 |
| vila | jsk_: and you should write a nice letter to your isp too :) | 15:11 |
| === kiko is now known as kiko-fud | ||
| === cprov is now known as cprov-lunch | ||
| jelmer | mdke: any luck with svn-import? | 16:06 |
| === beuno_ is now known as beuno | ||
| === kiko-fud is now known as kiko | ||
| === bac_afk is now known as bac | ||
| === cprov-lunch is now known as cprov | ||
| Vantage | hi, quick question. How do I configure bzr to create a branch without a working tree (or create a remote branch in a shared repo w/o making a working tree) | 18:40 |
| Peng | Well, you could use 'bzr init-repo --no-trees'. | 18:45 |
| james_w | Vantage: there is also 'bzr remove-tree' to do it after the fact. | 18:46 |
| james_w | and doing a push to a remote location will not create a working tree there. | 18:46 |
| Peng | If you already have a shared repo and want new branches to stop creating working trees, touching .bzr/repository/no-working-trees should do it. | 18:47 |
| === mrevell is now known as mrevell-dinner | ||
| Vantage | Peng: thanks. Is that in a document somewhere? I tried hunting for it on the site, but couldn't find it | 19:01 |
| * Peng shrugs. | 19:01 | |
| Peng | Vantage: It's in 'bzr help' if you know where to look. | 19:02 |
| lifeless | moin | 20:01 |
| jam-laptop | morning lifeless, is my clock right in saying it is 5 am there? | 20:01 |
| lifeless | yes | 20:02 |
| fullermd | He's got pack repos. They let him sleep faster. | 20:02 |
| * lifeless flips the bird | 20:02 | |
| lifeless | ok, its cooked now ;) | 20:06 |
| lifeless | jam-laptop: so, what do you have on your plate? | 20:09 |
| jam-laptop | lifeless: right now I'm just going through the review queue and trying to squash all of the Critical bugs | 20:09 |
| jam-laptop | At least the ones with relatively simple fixes | 20:09 |
| lifeless | yah | 20:09 |
| lifeless | the revisionspec one would be lovely if you could do | 20:10 |
| jam-laptop | there is a surprising amount of stuff in: http://bundlebuggy.aaronbentley.com/?selected=pending&unreviewed=n | 20:10 |
| jam-laptop | Which has been approved but not merged | 20:10 |
| lifeless | I'm back stripping commit down to do only what it needs to do | 20:11 |
| lifeless | dirstate lookup is problematic | 20:12 |
| jam-laptop | sounds good | 20:12 |
| lifeless | I'm considering a basic datatype to factor out - 'sorted dict' | 20:12 |
| jam-laptop | Any way you can completely stream rather than doing the per-file lookup? | 20:12 |
| lifeless | well, I wrote a patch that layers on iter changes | 20:13 |
| jam-laptop | even if it was only for the non-merge case | 20:13 |
| jam-laptop | that would be a pretty big win | 20:13 |
| lifeless | but it still has to probe back in because iter changes hides too much | 20:13 |
| lifeless | the core problem is that commit diffs against an arbitrary parent, not parent 0 | 20:13 |
| jam-laptop | well, that is why I said the "non-merge" case | 20:14 |
| lifeless | well, I say 'problem'. The reason that iter_changes is not a good fit is that .. | 20:14 |
| jam-laptop | Certainly I'm aware of the api divergence between multiple parents and _iter_changes | 20:14 |
| lifeless | I really don't want two code paths here | 20:15 |
| lifeless | I just feel it would be a recipe for bugs; and this is not a code area we want bugs in. | 20:15 |
| jam-laptop | lifeless: I'd like to have 1 code path eventually, it is just an issue of crawling before we walk | 20:15 |
| jam-laptop | I know we've gone around a few times of _iter_changes_for_commit | 20:15 |
| lifeless | right, a native version of that may well help | 20:16 |
| lifeless | but OTOH I think lsprof is lying | 20:16 |
| jam-laptop | :) | 20:16 |
| jam-laptop | lsprof does skew results a little bit | 20:16 |
| lifeless | the cache I added shaves 1/2 second off | 20:17 |
| lifeless | but if lookups really were what it though, it should be more, and it gets a solid hit rate | 20:17 |
| lifeless | s/though/*t/ | 20:19 |
| lifeless | &t dammit :) | 20:19 |
| jam-laptop | have you measured its hit rate? | 20:20 |
| jam-laptop | I wonder if it is less than you think | 20:20 |
| jam-laptop | (I don't see why it really would be, but it is something to consider) | 20:21 |
| jam-laptop | For example, if you have an average of 4 files per directory | 20:21 |
| jam-laptop | you can only have a 4/5 hit rate | 20:21 |
| jam-laptop | Though that is still 80% | 20:21 |
| lifeless | I'm testing on good ole moz | 20:21 |
| jam-laptop | IIRC moz has < 10 files per dir average | 20:21 |
| lifeless | interesting | 20:22 |
| jam-laptop | At least, we have 5761 directories | 20:22 |
| jam-laptop | and 49001 files | 20:22 |
| Lo-lan-do | Is Moz still using CVS, by the way? | 20:23 |
| jam-laptop | (49001 + 5761) / 5761 = 9.5 | 20:23 |
| jam-laptop | Lo-lan-do: primary development on Moz is still in CVS | 20:23 |
| Lo-lan-do | Ouch | 20:23 |
| jam-laptop | I think one of the "advanced branches" are trying hg | 20:23 |
| jam-laptop | Either FF 3 or Seamonkey .next | 20:23 |
| lifeless | jam-laptop: right | 20:23 |
| jam-laptop | something like that | 20:23 |
| Peng | Lo-lan-do: There's an hg mirror of the main CVS repo. I think a couple smaller Mozilla projects are primarily using hg. | 20:24 |
| lifeless | so we could set last_entry_index to 0 when the last_block_index changes | 20:24 |
| Peng | (Tamarin.) | 20:24 |
| jam-laptop | lifeless: but don't you "last_entry_index + 1" ? | 20:24 |
| jam-laptop | So really you want it -1 | 20:24 |
| jam-laptop | Though the code I saw fails | 20:24 |
| jam-laptop | if you are the first entry | 20:24 |
| jam-laptop | or the last entry | 20:24 |
| jam-laptop | because of IndexError | 20:24 |
| jam-laptop | Which could actually hurt performance | 20:25 |
| jam-laptop | because you have an exception stack | 20:25 |
| jam-laptop | that gets created | 20:25 |
| lifeless | it only fails on first | 20:25 |
| lifeless | not on last | 20:25 |
| lifeless | because I didn't plan on seeding it this way | 20:25 |
| jam-laptop | I thought I saw | 20:25 |
| jam-laptop | entry_index = last_index + 1 | 20:25 |
| jam-laptop | ... | 20:25 |
| lifeless | it is | 20:25 |
| jam-laptop | And then later it does | 20:26 |
| jam-laptop | if (key > block[entry-1] and key <= block[entry]) | 20:26 |
| jam-laptop | which should fail on the last | 20:26 |
| jam-laptop | well, at least when it goes past the end of the block | 20:26 |
| lifeless | which is the first entry on the next block | 20:26 |
| lifeless | which is a miss anyway | 20:26 |
| jam-laptop | sure | 20:27 |
| jam-laptop | you might consider just adding a simple counter | 20:27 |
| jam-laptop | to see how many queries hit there | 20:27 |
| jam-laptop | rather than going to the next | 20:27 |
| lifeless | I did in testing it | 20:28 |
| lifeless | it was something I felt the cost of an if() to keep it there was not worth | 20:28 |
| jam-laptop | sure, I wouldn't leave it in for production | 20:28 |
| jam-laptop | just to get a feeling for what the hit rate was | 20:28 |
| jam-laptop | lifeless: but I fully agree that lsprof is not perfect | 20:30 |
| lifeless | I've cover the start case | 20:31 |
| lifeless | covered | 20:31 |
| jam-laptop | Specifically: http://dpaste.com/23102/ | 20:31 |
| lifeless | I'll send a new patch if you would like to review | 20:31 |
| jam-laptop | just doing "bzr test-prof" | 20:31 |
| jam-laptop | shows the "two_functions" case taking 2x as long as the one function | 20:31 |
| jam-laptop | under lsprof | 20:32 |
| jam-laptop | I get 38ms versus 161ms | 20:32 |
| jam-laptop | or 4x | 20:32 |
| jam-laptop | though the wall clock time stays about 2x | 20:32 |
| lifeless | new patch sent | 20:33 |
| lifeless | yes, 50K function calls with 1 param is about 15ms | 20:33 |
| lifeless | I find timeit is very good at this ;) | 20:34 |
| jam-laptop | http://dpaste.com/23105/ | 20:34 |
| lifeless | hang on while I swtich to a machine with a browser | 20:34 |
| jam-laptop | first paste is a plugin | 20:36 |
| jam-laptop | second paste is the timing | 20:36 |
| fullermd | jam-laptop: If you're looking at critical, 114615 isn't marked critical, but I kinda think it should be... | 20:37 |
| jam-laptop | bug 114615 | 20:37 |
| ubotu | Launchpad bug 114615 in bzr "Commit can fail and corrupt tree state after encountering some merge/conflicts" [High,Confirmed] https://launchpad.net/bugs/114615 | 20:37 |
| dato | lifeless: (you can wget -qO- dpaste.com/123/text) | 20:37 |
| jam-laptop | yeah, I wanted to follow up with that one and see if it should be critical | 20:38 |
| lifeless | dato: yah | 20:38 |
| dato | lifeless: (sorry, s/text/plain/) | 20:38 |
| lifeless | dato: but its easier to move for a bit | 20:38 |
| dato | what fits you best :) | 20:38 |
| jam-laptop | fullermd: does your test case do something significantly different from mine? | 20:39 |
| jam-laptop | (I can see that mine is still reproducible in bzr.dev, though, which might be enough to go on) | 20:39 |
| fullermd | Not sure. Back when you posted yours, the bug was just (or at least, seemed to just) weird out commit once, then work fine. | 20:40 |
| fullermd | My later one was where it started marking files as deleted :( | 20:40 |
| fullermd | I dunno if that's just that we didn't hit that particular case before, or something in the code changed since we first looked at it. | 20:40 |
| jam-laptop | fullermd: yeah, mine doesn't break "bzr status" like yours does | 20:42 |
| fullermd | Yah. Nobody else would be nutso enough to setup situations like that one :p | 20:43 |
| vila | hi all | 20:43 |
| fullermd | (well, 'stat' isn't broken; it's showing exactly what it thinks is happening. I found the bug by finding a couple revs later that the file had been deleted by commit) | 20:44 |
| jam-laptop | fullermd: true | 20:47 |
| fullermd | In a sense, it's not really data _loss_, since you can just revert the file and get it back. But it's pretty freakin' scary to see happen to your tree... | 20:49 |
| lifeless | jam-laptop: so, what do you think of my updated cache ? Good to go ? | 20:53 |
| jam-laptop | I don't see how it is going to hit the first entry on the next pass | 20:55 |
| jam-laptop | considering that you will have | 20:55 |
| jam-laptop | entry = -1 + 1 | 20:55 |
| jam-laptop | block[entry -1] | 20:55 |
| lifeless | which is 0 | 20:55 |
| jam-laptop | which will be an index error | 20:55 |
| jam-laptop | or it will give you block[-1] | 20:55 |
| jam-laptop | which is *really* not what you want | 20:55 |
| lifeless | if (entry > 0 and block[entry - 1]) | 20:55 |
| lifeless | more precisely, this is the line | 20:56 |
| lifeless | + if ((entry_index > 0 and block[entry_index - 1][0] < key) and | 20:56 |
| lifeless | which only looks at entry_index - 1 if entry_index is 1 or more | 20:56 |
| jam-laptop | ok, I missed the nesting | 20:57 |
| jam-laptop | lifeless: I would prefer: present = (block[entry_index][0] == key) | 20:57 |
| jam-laptop | Though otherwise I think I approved the previous implementation | 20:58 |
| jam-laptop | and you only changed 1 think | 20:58 |
| jam-laptop | thing | 20:58 |
| lifeless | yes you did | 20:58 |
| lifeless | so I'm asking about the delta | 20:58 |
| jam-laptop | well if the delta is just using -1 instead of none | 20:58 |
| lifeless | but I'll add a () around present for you | 20:58 |
| jam-laptop | bb:approve | 20:58 |
| lifeless | its assign last_entry_index to -1 when we assign last_block_index | 20:58 |
| lifeless | and change that one if block line | 20:58 |
| jam-laptop | lifeless: maybe add a comment about why you are using -1? | 20:59 |
| jam-laptop | Just a simple | 20:59 |
| jam-laptop | # setting to -1 since we are likely to ask for the first record next | 20:59 |
| jam-laptop | or something along those lines | 20:59 |
| jam-laptop | since we just had the conversation | 21:00 |
| jam-laptop | I understand what is going on | 21:00 |
| jam-laptop | but I realize I'll probably forget in a couple months | 21:00 |
| lifeless | # Reset the entry index cache to the beginning of the block. | 21:00 |
| lifeless | ok ? | 21:01 |
| jam-laptop | sounds good | 21:01 |
| jam-laptop | I don't know if we want a comment where they are defined | 21:01 |
| jam-laptop | discussing the basic use case | 21:01 |
| lifeless | I'll do that while we're here. | 21:01 |
| jam-laptop | (going linearly through the data) | 21:01 |
| jam-laptop | and that this is meant to speed up searching for the *next* entry | 21:01 |
| lifeless | # These two attributes provide a simple cache for lookups into the | 21:03 |
| lifeless | # dirstate in-memory vectors. By probing respectively for the last | 21:03 |
| lifeless | # block, and for the next entry, we save nearly 2 bisections per path | 21:03 |
| lifeless | # during commit. | 21:03 |
| === mrevell-dinner is now known as mrevell | ||
| jam-laptop | lifeless: good enough | 21:04 |
| jam-laptop | go for it | 21:04 |
| lifeless | thanks | 21:05 |
| vila | bzr revert --no-backup | 21:26 |
| vila | wrong window :) err right keyboard but not redirected to the right PC to be exact :) | 21:27 |
| fullermd | Could be worse. You could be meaning to type that _here_, and do it in the wrong window... | 21:28 |
| lifeless | heh | 21:28 |
| jam-laptop | vila: I thought you were just trying to cover up a post you didn't mean to make | 21:29 |
| vila | jam-laptop: check your mail :) I was just reverting the part I talk about :) | 21:29 |
| jam-laptop | ah | 21:30 |
| jam-laptop | yeah, I responded to you | 21:30 |
| jam-laptop | Would it be possible to put a check like that in permanently? | 21:30 |
| jam-laptop | vila: ^^ | 21:30 |
| vila | host empty ? I just have to diagnose the smart smoke test part, I fixed the other cases | 21:31 |
| vila | but I didn't touch anything else | 21:31 |
| lifeless | we really need to fix urlparse | 21:32 |
| vila | lifeless: agree | 21:32 |
| lifeless | nfs+trace+http+urlib:// | 21:32 |
| vila | a simple foo://user@host is enough to make it go nuts | 21:32 |
| vila | for any foo that is not a known scheme :) | 21:33 |
| jam-laptop | vila: for some reason urlparse feels that most protocols are not netloc style | 21:36 |
| jam-laptop | while *we* feel that most *are* | 21:36 |
| jam-laptop | and it would be more reasonable to register non-netloc protocols | 21:36 |
| jam-laptop | I suppose it would be different | 21:36 |
| jam-laptop | if we wanted to support | 21:36 |
| jam-laptop | file:foo | 21:36 |
| jam-laptop | or | 21:36 |
| jam-laptop | file:/path | 21:36 |
| jam-laptop | rather than file:///path | 21:36 |
| jam-laptop | we are fairly strict on what type of url we support | 21:37 |
| vila | jam-laptop: yes | 21:38 |
| lifeless | jam-laptop: file:foo is not valid. phone: is :) | 21:39 |
| jam-laptop | well, I *think* that FF and IE will let you type file:foo in the URL and do something with it | 21:40 |
| jam-laptop | at the minimum | 21:40 |
| jam-laptop | file:/foo | 21:40 |
| jam-laptop | should work | 21:40 |
| jam-laptop | which *we* do not support | 21:40 |
| lifeless | file:/foo should not work according to std66 | 21:41 |
| vila | lifeless: what is std66, that the second time I run across that reference today ? | 21:43 |
| vila | yeah, ok, google told me :) | 21:44 |
| jam-laptop | lifeless: try typing file:/tmp into a browser | 21:46 |
| jam-laptop | I'm pretty sure it will work just fine | 21:46 |
| jam-laptop | (I just tested it. and it just renamed it to file:///tmp, but still worked) | 21:47 |
| vila | I think you both agree :) | 21:47 |
| lifeless | jam-laptop: crackheadedheuristicsforthewin | 21:47 |
| jam-laptop | well, browser's have a long culture of DWIM | 21:48 |
| jam-laptop | considering page reflows | 21:48 |
| jam-laptop | and "gracefully" handling bad html | 21:48 |
| vila | jam-laptop: your browser is telling you in a very subliminal way: "Thou Should Fix #123363" | 21:49 |
| jam-laptop | bug #123363 | 21:49 |
| ubotu | Launchpad bug 123363 in bzr "selftest pollutes /tmp" [Medium,Confirmed] https://launchpad.net/bugs/123363 | 21:49 |
| vila | ubotu, you obviously miss the joke... | 21:50 |
| lifeless | anyhow | 21:56 |
| lifeless | brb | 21:56 |
| lifeless | back | 22:03 |
| === thumper_laptop is now known as thumper | ||
| jam-laptop | vila: your last commit was "hhtp" again | 22:24 |
| jam-laptop | "Make hhtp proxy aware of ..." | 22:24 |
| vila | LOL | 22:25 |
| vila | time to go to sleep then :P | 22:25 |
| jam-laptop | vila: sleep well | 22:25 |
| jam-laptop | need me to sing a lullaby? | 22:25 |
| lifeless | nice vila | 22:25 |
| jam-laptop | I'm getting pretty good at them | 22:25 |
| lifeless | gnight | 22:25 |
| lifeless | jam-laptop: :) | 22:25 |
| vila | thanks for the heads up, I was about to resolve conflicts in smtp_connection, better to that with a fresh mind :) | 22:25 |
| lifeless | jam-laptop: so, do you have time perhaps, to do the revspec bug I filed ? | 22:25 |
| lifeless | its not inside the 'make commit fast' envelope, but its really annoying ;) | 22:26 |
| jam-laptop | lifeless: well, not tonight :) I'm working hard against bug #114615 | 22:27 |
| ubotu | Launchpad bug 114615 in bzr "Commit can fail and corrupt tree state after encountering some merge/conflicts" [High,Confirmed] https://launchpad.net/bugs/114615 | 22:27 |
| lifeless | jam-laptop: ok | 22:27 |
| jam-laptop | but I can look at bug #154204 tomorrow | 22:27 |
| ubotu | Launchpad bug 154204 in bzr "revision specs do not lock branches appropriately." [Critical,Triaged] https://launchpad.net/bugs/154204 | 22:27 |
| lifeless | bah corruption | 22:28 |
| jam-laptop | (that is the one you are talking about, right?) | 22:28 |
| lifeless | yes, it | 22:28 |
| lifeless | ... | 22:28 |
| lifeless | is | 22:28 |
| mdke | jelmer: thanks for asking. I didn't have any more opportunity to try it; I tried it on a faster machine but it gave me ca-cert errors... weird because the machine has the same configuration as this one | 22:28 |
| jam-laptop | This is an odd case, where because of a conflict you can get some weird tree states | 22:28 |
| jam-laptop | Like I just renamed a file back to its original location | 22:28 |
| jam-laptop | and I get: | 22:28 |
| jam-laptop | ('a', 'n.OTHER', ...), ('r', 'a/n', ...), ('a', ...), ('r', 'a/n', ...) | 22:29 |
| jam-laptop | Or if your dirstate parser is rusty | 22:29 |
| jam-laptop | it says that the file a/n.OTHER | 22:29 |
| jam-laptop | is renamed to 'a/n' in THIS | 22:29 |
| jam-laptop | and absent in the base | 22:29 |
| jam-laptop | and renamed to 'a/n' in the other parent | 22:30 |
| jam-laptop | (aka, it doesn't exist anywhere, but still has an entry.) | 22:30 |
| lifeless | hmm | 22:34 |
| lifeless | so rename is failing to change the 'a' back to 'f' | 22:34 |
| jam-laptop | well, this is the "temporary" file that the merge conflict generates | 22:35 |
| jam-laptop | (n.OTHER) | 22:35 |
| lifeless | yah | 22:35 |
| lifeless | so this suggests to me a general rename bug | 22:36 |
| jam-laptop | so what it *should* do is just recognize it as an absent row | 22:36 |
| jam-laptop | and nuke it | 22:36 |
| lifeless | that renaming, when it is the last reference to a path, is remove it | 22:36 |
| lifeless | right, we're agreed. | 22:36 |
| jam-laptop | I don't know that it is the bug under question | 22:36 |
| jam-laptop | but it is a weird one | 22:36 |
| fullermd | Well, in Internet Years, dirstate is approaching the age where it starts "experimenting" with recreational chemicals, so... | 22:39 |
| jam-laptop | lifeless: are you trying to get to the point that we don't need to build inventories during commit? | 22:45 |
| jam-laptop | (or is that quite a way off?) | 22:45 |
| lifeless | I'm going to see about getting rid of the wt inventory during commit | 22:47 |
| lifeless | basis inventory removal is a tad further off | 22:47 |
| nDuff | lifeless: bzr-packs has some impressive performance characteristics. | 22:50 |
| nDuff | lifeless: considerably faster than mercurial in some scenarios, and only slightly slower in others. | 22:50 |
| lifeless | nDuff: Thats excellent news. | 22:50 |
| jam-laptop | lifeless: any idea how to detect the record_entry_contents API breakage? | 22:50 |
| jam-laptop | (You now have an extra parameter) | 22:51 |
| lifeless | nDuff: We found a serious performance bug in extracting texts yesterday, 30% win for large binaries, may help you there too. | 22:51 |
| jam-laptop | I'm trying to update cvsps | 22:51 |
| jam-laptop | cvsps-import | 22:51 |
| jam-laptop | and I would like it to work with both pre 0.92 | 22:51 |
| jam-laptop | and 0.92 | 22:51 |
| lifeless | jam-laptop: Uhm, look at bzrlib.version_info is probably best. | 22:51 |
| lifeless | commit is going to be in flux for at least one more release though | 22:51 |
| jam-laptop | well, I would technically like to work with bzr.dev pre and post fix, too | 22:52 |
| lifeless | nDuff: (the fix for that is in my repository branch) | 22:52 |
| jam-laptop | oh, and that api break isn't mentioned in NEWS | 22:52 |
| jam-laptop | you talk about a *different* api break | 22:52 |
| jam-laptop | (requiring the root node) | 22:52 |
| jam-laptop | but not that the number of parameters changed | 22:52 |
| jam-laptop | lifeless: for the large files, didn't you get that merged? | 22:52 |
| lifeless | heh, sorry | 22:52 |
| lifeless | jam-laptop: it is merged, nDuff is testing packs though | 22:52 |
| jam-laptop | ah, ok | 22:52 |
| nDuff | lifeless: http://people.ubuntu.com/~robertc/baz2.0/repository/ ? | 22:53 |
| lifeless | yup | 22:53 |
| lifeless | it shows up when applying long delta chains | 22:54 |
| lifeless | basically we did 3 list clones - newlist = oldlist[:] | 22:54 |
| lifeless | which on files with many \n's leads to thousands of object reference-dereference pairs per delta in the delta chain | 22:54 |
| lifeless | so a file that has been altered hundreds of times does millions of unneeded object reference pairs | 22:55 |
| mdke | jelmer: ok, so now svn-import gives me "Invalid revision id {None} in SvnRepository" | 22:57 |
| jelmer | mdke: what version of bzr-svn? afaik that was a bug fixed in 0.4.2 or 0.4.3 | 22:59 |
| mdke | jelmer: 0.4.1-1 (gutsy) | 23:00 |
| lifeless | nDuff: I'd be interested in knowing where we were slow, so we can fix that too. | 23:00 |
| jelmer | mdke: .debs of newer versions are available in debian, http://packages.debian.org/sid/bzr-svn | 23:01 |
| mdke | jelmer: should I install a later version? is your repository the most reliable one? | 23:01 |
| mdke | ah, ok | 23:02 |
| mdke | jelmer: no idea about the ca-cert error I had on the other computer, I guess? | 23:02 |
| jelmer | mdke: depends on the error | 23:03 |
| jelmer | mdke: prefixing the url with "svn+" may help | 23:03 |
| mdke | "server certificate verification failed" | 23:03 |
| jelmer | does "svn ls <url>" work? | 23:03 |
| lifeless | jelmer: do you have some debugging notes? | 23:04 |
| jelmer | lifeless: for what specifically? | 23:04 |
| mdke | yeah, svn ls works | 23:04 |
| lifeless | for e.g. me to point e.g. mdke at | 23:04 |
| lifeless | currently you're really the only person able to help users. | 23:04 |
| jelmer | there's the FAQ that is going to be part of 0.4.4 | 23:06 |
| nDuff | lifeless: let me get all my results together. there are a few places where I was less rigorous about recording them than I should have been. | 23:07 |
| jelmer | lifeless: that, and the list of known bugs | 23:08 |
| lifeless | nDuff: sure, not meaning to put you on the spot in any way. Knowing the envelope you're working on and where it was slow is all. If you find particular ops slow please also feel free to mail me a callgrind for that run | 23:09 |
| nDuff | lifeless: just threw an exception checking out your branch; see http://pastebin.com/m41646d13 | 23:09 |
| lifeless | nDuff: e.g. 'bzr --lsprof-file foo.callgrind command thing thing' | 23:09 |
| jelmer | mdke: so, prefixing the url with "svn+" should fix the error then | 23:09 |
| lifeless | nDuff: ok, thats the bad index in that repo; known issue - I have a fixed copy, one sec. | 23:09 |
| lifeless | nDuff: http://people.ubuntu.com/~robertc/pack-repository.knits | 23:10 |
| lifeless | nDuff: ^ that has all the code too, and is probably the one you pulled initially. | 23:10 |
| jelmer | lifeless: btw, any news on pqm for bzr-gtk/my pqm merge requests? | 23:11 |
| lifeless | sorry no | 23:11 |
| lifeless | haven't forgotten, just had no cycles | 23:12 |
| mdke | jelmer: right. I'm going to put another one on, leave it overnight and see what happens in the morning | 23:12 |
| jelmer | lifeless: no hurries, just making sure it doesn't drop off your todo list :-) | 23:13 |
| lifeless | kk | 23:13 |
| jelmer | mdke: with a newer version ? | 23:13 |
| mdke | yes | 23:13 |
| mdke | jelmer: incidentally, since you're here, I'll just ask - if it all goes well, do I get separate bzr branches for trunk and each svn branch? or a single bzr branch? I don't understand the explanation in bzr help svn-import about what --all and --standalone do | 23:13 |
| jelmer | mdke: yes, you will | 23:14 |
| mdke | great | 23:14 |
| mdke | ok, it seems to be getting on with the first branch already, splendid | 23:14 |
| jelmer | mdke: --all is about importing revisions that were part of historic branches that have since been removed | 23:14 |
| jelmer | mdke: --standalone is basically about not using a shared bzr repository | 23:14 |
| mdke | ah, perhaps I wanted that | 23:14 |
| jelmer | --standalone will blow up the amount of disk space required | 23:15 |
| mdke | LP doesn't support shared bzr repositories, does it? | 23:15 |
| jelmer | it doesn't, but you can push from a shared bzr repository to launchpad without problems | 23:15 |
| mdke | so I can do the import now without --standalone and then create separate branches by pushing them to launchpad? | 23:16 |
| jelmer | when using a shared repository you'll also have separate branches | 23:16 |
| jelmer | but yes | 23:16 |
| mdke | ok. sorry if I don't understand the concepts very well | 23:16 |
| mdke | the aim is to have LP host branches centrally that the team can access, as long as I can achieve that, I'm happy | 23:17 |
| lifeless | mdke: so branch is a line of development | 23:17 |
| lifeless | mdke: repository is physical storage for historical data | 23:17 |
| lifeless | mdke: every branch has to have a repository available to store its data; either one per branch, which we call standalone branches, or one shared across many branches, which we call a shared repository | 23:18 |
| mdke | very clear | 23:18 |
| mdke | and I can use my shared repository to push standalone branches to Launchpad? | 23:18 |
| mdke | or not? | 23:18 |
| lifeless | yes, because branch and repository are orthogonal cocepts | 23:19 |
| lifeless | *concepts* | 23:19 |
| lifeless | a branch is a branch | 23:19 |
| lifeless | so you can push a branch from your shared repo to launchpad, and vice verca | 23:19 |
| mdke | so when I upload a branch from the shared repo to LP, it will take the historical data relevant to it and store it in a standalone branch? | 23:19 |
| lifeless | yes | 23:19 |
| mdke | great. | 23:20 |
| mdke | so essentially the history doesn't get lost either way, whether I import it with --standalone or not | 23:20 |
| lifeless | right | 23:20 |
| lifeless | its just much more efficient in terms of disk storage without --standalone | 23:21 |
| mdke | thanks, and sorry for being a bit slow, but I wanted to make absolutely sure | 23:21 |
| mdke | ok, we'll see where it gets to overnight. possibly I'll have to leave it to work for some time :D | 23:21 |
| mdke | thanks for all the help, both | 23:22 |
| nDuff | interesting. | 23:27 |
| lifeless | jam-laptop: looks like we need a tree.iter_entries_by_dir | 23:27 |
| lifeless | that supports file id filtering | 23:27 |
| nDuff | lifeless: why would an uncommit+recommit take considerably less CPU time than the initial commit? | 23:27 |
| lifeless | nDuff: the recommit step ? | 23:29 |
| lifeless | or the two combined ?. Anyhow, no matter - it shouldn't. Unless the hash cache was empty on the first commit | 23:29 |
| nDuff | lifeless: hmm. initial commit was ~15min of CPU time; the recommit was ~2m wall-clock. wrt the cache in question -- would it be populated by a "bzr status"? | 23:30 |
| lifeless | yes | 23:30 |
| lifeless | 15 mins of CPU to 2 is quite remarkable | 23:31 |
| nDuff | hrm; even when it's needing to repopulate the cache, a bzr status isn't taking nearly 13 minutes. | 23:31 |
| lifeless | thats really quite bizarre, no pun intended. If you find yourself able to reproduce, a callgraph of it would be wonderful | 23:32 |
| igc | morning all | 23:39 |
| lifeless | moin | 23:41 |
| lifeless | I replied to your graph patch review | 23:41 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!