| berto- | jelmer: sure, i'll give that a shot. | 00:02 |
|---|---|---|
| lifeless | jam: revno 8 has your patches with tests fixed | 00:05 |
| berto- | jelmer: not sure this is what you're after: http://paste.pocoo.org/show/78325/ | 00:06 |
| berto- | jelmer: i used this: gdb --args python /home/berto/local/opt/bzr.dev/bzr push /home/dev/repo.svn | 00:06 |
| awilkins | jelmer: yegods this is tedious ; I now have it compiling (yay!) but not linking yet (Boo!) | 00:08 |
| jelmer | awilkins: :-( What error? | 00:09 |
| awilkins | Oh, it's normal for windows - totally different library finding. Let me patch my bits back in | 00:10 |
| jelmer | berto-: interesting - no idea | 00:11 |
| jelmer | berto-: Does the bzr-svn testsuite pass on your machine? | 00:11 |
| awilkins | Bah, spoke too soon | 00:12 |
| * awilkins goes back to hand-unrolling struct initializers | 00:12 | |
| jelmer | berto-: (make check) | 00:13 |
| awilkins | jelmer: Yipes, it might have built | 00:15 |
| jelmer | awilkins: Any chance you can send a bundle with the C99-removal stuff? | 00:16 |
| awilkins | jelmer: Am I supposed to have a bunch of pyd files? | 00:16 |
| awilkins | Aha | 00:16 |
| awilkins | I have 4 pyd files | 00:16 |
| jelmer | awilkins: no, those were removed a long time ago | 00:16 |
| awilkins | client, ra, repos, and wc | 00:16 |
| Odd_Blok1 | Does abentley still host BB himself, or has it moved to a Canonical server? | 00:16 |
| berto- | jelmer: ooh, aobrted! | 00:17 |
| awilkins | jelmer: It's just built them | 00:17 |
| jelmer | awilkins: Which branch are you using then? | 00:17 |
| awilkins | jelmer: 0.4 | 00:17 |
| awilkins | pyd files are the intended output of a C extension, no? | 00:17 |
| jelmer | awilkins: I'm pretty sure that doesn't contain any .pyd files.. | 00:17 |
| jelmer | Ah, this is windows of course.. | 00:18 |
| jelmer | awilkins: maybe :-) | 00:18 |
| jelmer | they're also the extension pyrex uses for one of its file types, that's what confused me | 00:18 |
| awilkins | They're in the build folder and marked 0015, I think that's a success | 00:18 |
| jelmer | nice :-) | 00:18 |
| berto- | jelmer: http://paste.pocoo.org/show/78326/ i can't gather anything interesting from that. | 00:18 |
| jelmer | berto-: hmm, you may want to try "make valgrind-check" or "make gdb-check" | 00:18 |
| awilkins | jelmer: Right, problem one, MSVC has no stdbool.h, so I've pasted a simple one and changed the includes from path-includes to -local-includes | 00:19 |
| Odd_Blok1 | lifeless: What are your thoughts on moving PQM to a team-maintained branch on LP, and using BB and PQM itself to do the development? | 00:19 |
| jelmer | awilkins: Can you exclude those changes for now? | 00:19 |
| awilkins | jelmer: Sure, let me shove them on a shelf | 00:19 |
| berto- | jelmer: i'm thinking py2.5 might be the way to go and see if all this goes away. | 00:19 |
| lifeless | Odd_Blok1: uhm, pqm implies a non team maintained branch :) | 00:20 |
| lifeless | Odd_Blok1: I'm fine with the idea of BB, though we're using lp's review system at the momen | 00:20 |
| Odd_Blok1 | lifeless: Yeah, LP's review system is probably OK. I'd quite like for PQM to be self-hosting though, so that I'm forced to get to grips with it as a user. | 00:24 |
| awilkins | jelmer: Does vi put UTF-8 signatures at the front of files? | 00:25 |
| === Odd_Blok1 is now known as Odd_Bloke | ||
| jelmer | awilkins: nope, I do :-) | 00:25 |
| awilkins | jelmer: Ah, so these are meant to be here? | 00:26 |
| awilkins | jelmer: They're showing up as changes in shelve ; maybe that's a bug | 00:26 |
| awilkins | +´../* Copyright .® 2008 Jelmer V | 00:26 |
| awilkins | (the ".." are the unprintables for UTF-8 signature | 00:27 |
| jelmer | awilkins: Probably some sort of bug on Windows | 00:27 |
| awilkins | jelmer: Hmm. I'll test that in a bit | 00:27 |
| lifeless | Odd_Bloke: I think I'd rather have the dependencies on baz etc really wound back before trying for that | 00:27 |
| lifeless | Odd_Bloke: its not the friendliest thing to setup today | 00:27 |
| awilkins | jelmer: 'tis ok after I strip them off in an editor that is aware of them | 00:27 |
| Verterok | disconnect | 00:28 |
| Verterok | disconnect | 00:28 |
| Odd_Bloke | lifeless: Sure, that makes sense. Removing the VCS stuff is first on my list, to save me having to accommodate it when I do anything else. | 00:31 |
| awilkins | jelmer: That patch should be approaching your mailbox | 00:38 |
| awilkins | jelmer: Alas, "Unable to load bzr-svn extensions - did you build it?" | 00:40 |
| jelmer | awilkins: thanks | 00:49 |
| jelmer | awilkins: hmm | 00:49 |
| jelmer | awilkins: It build the extensions in the same directory as the .py files? | 00:49 |
| * igc breakfast | 00:50 | |
| jelmer | hi Ian | 00:50 |
| awilkins | jelmer: No, a subfolder, but I moved them into the same folder | 00:56 |
| awilkins | jelmer: I may be over-linking | 00:56 |
| awilkins | jelmer: I'm just cutting my linking to only required libs | 00:57 |
| * lamont bemoans the lack of a bzr git-import | 00:57 | |
| Peng | lamont: bzr-fastimport? | 00:57 |
| Peng | Maybe? | 00:58 |
| jelmer | awilkins: If they're in the same folder and still failing, you may want to look at .bzr.log | 00:58 |
| awilkins | jelmer: What's that thing where you filter a list with "for x in " ? | 00:58 |
| jelmer | list comprehension? | 00:58 |
| jelmer | lamont: yeah, bzr-fastimport or bzr-git (which I'll be working on over the summer) | 00:58 |
| jelmer | (not that helps you presently) | 00:59 |
| lamont | jelmer: and I can continue to freshen from the git repo | 00:59 |
| lamont | ? | 00:59 |
| jelmer | lamont: with bzr-fastimport, I think you can as long as you keep the files with the mappings around | 00:59 |
| lamont | being able to use the bzr UI with a git backend would be a big win for traction, I think | 01:00 |
| lamont | even if it means the occasional impoirt | 01:00 |
| lamont | more to the point, that would come in handy for creating a bzr branch of the git-core package.... | 01:01 |
| lamont | and can I push back to the git repo? | 01:02 |
| jelmer | lamont: with bzr-fast-import ? Yes, you can export back to a git repo afaik | 01:03 |
| lamont | nice | 01:04 |
| lamont | jelmer: does that mean export back to a new-and-virgin git repo, or to the one that I imported from (as a push) ? hopefully the latter | 01:05 |
| * lamont should really read up on bzr fast import | 01:05 | |
| jelmer | lamont: bzr fast-import/export use a custom file format that is also understood by git fast-import/export | 01:06 |
| jelmer | lamont: afaik you can continue exporting to an existing git repo | 01:06 |
| lamont | nice - I'll do some reading | 01:07 |
| lifeless | poolie: http://allmydata.com/ | 01:12 |
| lifeless | poolie: http://ceph.newdream.net/ | 01:14 |
| jelmer | berto-: more luck with 2.5? | 01:14 |
| igc | hi jelmer | 01:16 |
| igc | lamont: fastimport/export is designed for interchange | 01:18 |
| igc | it does provide some limited incremental mirroring but it's not overly smart yet | 01:18 |
| igc | lamont: Pieter has done some good work on improving it but I'm yet to incorporate all of his work into the trunk | 01:19 |
| igc | if the trunk isn't flexible enough for you yet, try Pieter's branch | 01:20 |
| jelmer | awilkins: still there? | 01:27 |
| awilkins | jelmer: yes | 01:37 |
| awilkins | jelmer: It seems to be loading them now, but I'm getting MSVCR80.dll errors | 01:38 |
| awilkins | jelmer: I thikn it should be linked against MSVCR71 for Python 2.5 | 01:38 |
| awilkins | jelmer: GAH they stopped working again | 01:44 |
| awilkins | http://pastebin.ca/1060099 | 01:47 |
| jml | how can I conveniently look at the log message for the last change to a file? | 01:49 |
| jelmer | awilkins: I've merged your .C fixes | 01:55 |
| jelmer | awilkins: hmm, no indication of what module couldn't be found? | 01:56 |
| berto- | jelmer: got sidetracked, haven't checked yet. | 01:57 |
| awilkins | jelmer: Looks like it can't find apr & co | 01:57 |
| jelmer | awilkins: co? | 01:57 |
| awilkins | jelmer: "and company" | 01:58 |
| jelmer | awilkins: Copying all required dlls into the bzr-svn folder may work :-P | 01:58 |
| awilkins | jelmer: Looks like it's not hunting through the path, I set a filesystem monitor on it | 01:58 |
| awilkins | jelmer: It's weird, it's looking through SOME folders on the PATH but not all of them | 01:59 |
| * awilkins copies the DLLs into the folder | 02:00 | |
| awilkins | MSVCR80.dll | 02:01 |
| awilkins | Bah, looks like the wrong version to use | 02:04 |
| awilkins | "The application has made an attempt to load the C runtime library incorrectly" | 02:05 |
| jelmer | hmm | 02:07 |
| awilkins | jelmer: I'm poring over the linker output to see if I am linking to bad versions of libraries | 02:08 |
| awilkins | jelmer: I'm using the MSVC7 linker as far as I'm aware | 02:09 |
| awilkins | jelmer: I think my LIB env needs a bit of a kick | 02:12 |
| awilkins | jelmer: Et voila... bingo | 02:14 |
| jelmer | awilkins: it works!? | 02:14 |
| awilkins | THis is what you get for installing the Windows SDK | 02:14 |
| awilkins | Let me try the selftest | 02:14 |
| awilkins | Bugger | 02:15 |
| awilkins | It got as far as "bzr plugins" withotu moaning this time though | 02:15 |
| jelmer | what did it moan about? | 02:16 |
| awilkins | jelmer: MSVCR80... I deleted it and I now have an ACTUAL STACK TRACE | 02:17 |
| awilkins | http://pastebin.ca/1060108 | 02:18 |
| jelmer | awilkins: looks like your version of bzr is not new enough | 02:20 |
| awilkins | jelmer: Could be, I'm on a self-build of 1.6b2 | 02:20 |
| * awilkins pulls his dev branch | 02:21 | |
| * awilkins snores | 02:23 | |
| * awilkins is running bzr.dev selftest svn | 02:25 | |
| awilkins | There are still far too many of these "unable to remove testing dir" errors on windows | 02:27 |
| jelmer | ok, but at least it appears to be somewhat running? | 02:28 |
| awilkins | jelmer: Yes, I so far have 101/925 14 err 2 fail | 02:28 |
| awilkins | jelmer: I'll post you the STDOUT when it's done | 02:29 |
| jelmer | awilkins: woot! | 02:30 |
| jelmer | awilkins: That's a big improvement from not working at all already :-) | 02:30 |
| jelmer | awilkins: How much local changes do you have? | 02:30 |
| awilkins | jelmer: Quite a nasty patch to setup.py, a local stdbool.h, and the c files use it | 02:31 |
| awilkins | jelmer: And by "nasty" I mean "totally hardcoded for adrian's filesystem" | 02:32 |
| awilkins | As well as "may cause Posix builds to break, dunno" | 02:32 |
| awilkins | The big stinker is the MS linker which insists on seeing every lib in the tree before it will link the ones at the top (I don't know if GNU link does this) | 02:33 |
| jelmer | awilkins: so just setup.py and stdbool.h ? | 02:33 |
| lifeless | ok | 02:33 |
| lifeless | these are definitely slower to write: | 02:33 |
| lifeless | GraphIndex: Wrote 92994 in 15.328 | 02:33 |
| lifeless | BTreeIndex: Wrote 92994 in 25.079 | 02:33 |
| jelmer | awilkins: I'd be interested in that patch | 02:34 |
| jelmer | awilkins: Is there some way to find those paths automatically on windows? | 02:34 |
| awilkins | jelmer: Unless they are in your LIB and INCLUDE env, probably not | 02:34 |
| awilkins | jelmer: distutils uses those on Windows (I presume as well as Posix) | 02:35 |
| awilkins | jelmer: It may be enough to insist they get put in LIB and INCLUDE | 02:36 |
| jelmer | awilkins: there's no apr-config or svn-config utilities? | 02:36 |
| awilkins | jelmer: They are bash scripts | 02:36 |
| awilkins | Well, apr-config is, afaik | 02:36 |
| jelmer | ah, right | 02:37 |
| awilkins | jelmer: I think we demonstrated that GCC doesn't work very well for building Python extensions for Win32 | 02:37 |
| jelmer | yeah, guess we should amend the apr detection to just look for that header then | 02:37 |
| awilkins | I put in a PosixBuildData and WindowsBuildData class | 02:37 |
| awilkins | But I'm not 100% sure I left the Posix end compatible with Posix | 02:38 |
| jelmer | ah, k | 02:38 |
| awilkins | Ok, you have 87 err, 16 fails | 02:38 |
| jelmer | Can you mail me the output? | 02:38 |
| jelmer | and perhaps those changes to setup.py as well so I can verify the posixy bit still works | 02:39 |
| jelmer | I'll see if I can trim that stuff down a bit tomorrow | 02:39 |
| jelmer | that stuff == the failures | 02:39 |
| jelmer | time for some sleep first :-) | 02:39 |
| awilkins | I concur, it's 0240 here | 02:40 |
| awilkins | jelmer: Ok, those files should be on their way, goodnight. | 02:42 |
| * Odd_Bloke --> lunch (of a sort, it's nearly 3am here but I got up at 10pm...) | 02:53 | |
| * igc lunch | 03:18 | |
| === bigdo2 is now known as bigdog | ||
| Odd_Bloke | Could someone pastebin a sample bzr PQM submission email for me? | 03:56 |
| lifeless | Odd_Bloke: install bzr-pqm-submit | 03:58 |
| lifeless | Odd_Bloke: then do 'bzr pqm-submit --dry-run' | 03:58 |
| mwhudson_ | i guess it's not too surprising that the c extensions make bzr annotate faster | 04:04 |
| mwhudson_ | is the amount they make things faster generally known? | 04:05 |
| lifeless | yes | 04:08 |
| lifeless | we highly recommend using them | 04:08 |
| mwhudson_ | the answer in this case seems to be "20 times faster" | 04:08 |
| lifeless | "we highly..." | 04:08 |
| Odd_Bloke | Top. Men. | 04:09 |
| pickscrape | Is this a new thing for 1.6? | 04:09 |
| lifeless | pickscrape: no | 04:09 |
| mwhudson_ | or... something else is going on | 04:11 |
| lifeless | woo | 04:20 |
| lifeless | GraphIndex: miss torture in 343.138 | 04:20 |
| lifeless | BTreeIndex: miss torture in 41.803 | 04:20 |
| mwhudson_ | so it seems doing revision_tree('..').annotate_iter() over http got waaaaaaaaaay slower somewhere between 1.6b2 and r3508 | 04:21 |
| mwhudson_ | which is strange, as (a) that's not very long afaict and (b) i didn't think much had changed with either annotation or http | 04:23 |
| mwhudson_ | (i think the c extensions comment above was a red herring) | 04:23 |
| lifeless | mwhudson_: I can't see anything indicating why | 04:24 |
| lifeless | mwhudson_: are you getting a RemoteRepository or a FooRepository object? | 04:25 |
| * mwhudson_ digs some more | 04:25 | |
| mwhudson_ | lifeless: foorepository i assume | 04:25 |
| mwhudson_ | yeah | 04:25 |
| mwhudson_ | what bzr.dev revision roughly corresponds with 1.6b2 ? | 04:26 |
| lifeless | not sure | 04:26 |
| lifeless | 3468 is 1.6b1 | 04:26 |
| mwhudson_ | ok, let me try that | 04:27 |
| mwhudson_ | bisect ftw | 04:27 |
| mwhudson_ | hmm | 04:28 |
| === mwhudson_ is now known as mwhudson | ||
| mwhudson | so maybe the difference is running it uninstalled vs installed | 04:29 |
| mwhudson | but that makes very little sense | 04:29 |
| lifeless | mwhudson: I think you have confounding factors | 04:31 |
| lifeless | mwhudson: how are you testing? via lh? | 04:31 |
| mwhudson | lifeless: no, locally | 04:31 |
| mwhudson | ah | 04:32 |
| mwhudson | i bet it's c extension related after all | 04:32 |
| mwhudson | 'make' uses 'python' to build the extensions | 04:32 |
| mwhudson | and i've been running my tests with python2.4 | 04:32 |
| lifeless | yes | 04:33 |
| mwhudson | ok, win | 04:33 |
| mwhudson | man that was really starting to confuse me | 04:34 |
| lifeless | igc: ping | 04:38 |
| igc | hi lifeless | 04:38 |
| lifeless | igc: I'm wondering if you want to usertest btree-plain repositories? | 04:41 |
| lifeless | igc: real-world scale applications >> artificial benchmarks | 04:42 |
| igc | lifeless: just looking over the email thread now | 04:42 |
| igc | wondering when the best time to run some benchmarks was | 04:42 |
| igc | :-) | 04:42 |
| lifeless | let me quote worf | 04:43 |
| lifeless | "Today is a good day to die" | 04:43 |
| abentley | Odd_Bloke: Still on my own server | 04:44 |
| igc | so lifeless, what baseline did you want to compare against? The latest bzr.dev? | 04:46 |
| ja1 | lifeless: moved | 04:52 |
| === ja1 is now known as jam | ||
| lifeless | :) | 04:52 |
| jam | I was here all along :) | 04:52 |
| jam | just hiding | 04:52 |
| lifeless | :) | 04:52 |
| jam | lifeless: I thought that quote was Flatliners | 04:52 |
| lifeless | so, adding first and last really depends on the ration of between-key misses | 04:52 |
| jam | well, it wasn't so much adding first and last as it was changing the < first > last logic | 04:53 |
| lifeless | and only gets that benefit for 2/child-nodes - basically every fencepost will get you one saving, but all the internal misses aren't saved | 04:53 |
| lifeless | jam: perhaps I'm missing something | 04:53 |
| jam | lifeless: sure, though it is easier to benchmark its value if we have it | 04:53 |
| jam | I was trying to work out what we *might* get | 04:53 |
| jam | but it is hard to instrument that | 04:54 |
| lifeless | jam: right, me too. All my gedanken were not encouraging though, which is why I skipped implementing | 04:54 |
| jam | lifeless: no, we only get 2/child-nodes, but it goes -infinity => start | 04:54 |
| jam | versus X => Y | 04:54 |
| jam | it sort of depends heavily on the "evenly distributed" | 04:54 |
| lifeless | right | 04:55 |
| jam | whether that is true or not | 04:55 |
| lifeless | but all it takes is a few adam's and zaphods | 04:55 |
| lifeless | :) | 04:55 |
| jam | A pack with only robertc@ will reject all of the john@ nodes very quickly | 04:55 |
| lifeless | jam: 1 IO vs three though | 04:55 |
| lifeless | jam: but the three with the smallest node in the cache will still be very quick | 04:56 |
| lifeless | jam: a more interesting one is to consider .tix | 04:56 |
| jam | lifeless: is that sorted (file_id, revision_id) or (revision_id, file_id) ? | 04:57 |
| jam | former, right? | 04:57 |
| lifeless | yes | 04:57 |
| lifeless | jam: heh, you didn't write a from_bin ? :P | 05:01 |
| jam | you mean bin_to_array ? | 05:02 |
| lifeless | yes | 05:02 |
| jam | yeah, it was mostly testing packing, not the other way around | 05:02 |
| lifeless | question | 05:02 |
| lifeless | why the power-of-2 constraint? | 05:02 |
| jam | lifeless: so I could do & instead of % | 05:03 |
| jam | I believe | 05:03 |
| lifeless | anyhow, 2048 is one :P | 05:03 |
| jam | as is 128, or 256 | 05:03 |
| jam | depending on where you want to go with that | 05:03 |
| lifeless | yeah | 05:03 |
| lifeless | I'll start with 256 | 05:04 |
| jam | lifeless: It is because I have to map from an integer into a bit | 05:04 |
| jam | so I go to offset "X >> 4" bit "X & 4" sort of thing | 05:04 |
| lifeless | jam: seems to me you could just work with any number of bytes | 05:04 |
| lifeless | jam: by taking that much of the sha and being tricky | 05:05 |
| jam | # This is used to take our 32-bit values, and mask off the high bits | 05:05 |
| jam | # so that the integer offsets, always point within the final bit-array | 05:05 |
| jam | # basically, 0 < (integer & self._bitmask) < self._num_bits for any | 05:05 |
| jam | # integer. Because _num_bytes is always a power of 2, _num_bits is | 05:05 |
| jam | # also a power of 2, and so a simple bit mask will do. | 05:05 |
| jam | self._bitmask = self._num_bits - 1 | 05:05 |
| lifeless | jam: mmm, thoughts for a different day | 05:05 |
| jam | lifeless: yes, you could do mod | 05:05 |
| jam | I did & _bitmask rather than % length | 05:05 |
| jam | lifeless: oh, for low bits / entry, MD5 is a bit better | 05:06 |
| jam | it only sets 4 bits in the output, which means it goes "white" slower | 05:07 |
| jam | The theoretical numbers are in the class docstrings | 05:07 |
| jam | (note that in practice, I got worse than theoretical, and always better with sha1. But I wasn't testing <4 bits / e either) | 05:08 |
| lifeless | jam: right. well ideally we won't be either :P | 05:08 |
| lifeless | I'm going to add | 05:09 |
| lifeless | :bloom:\nFILTER | 05:09 |
| jam | ?? | 05:12 |
| lifeless | jam: just how I'm going to encode it in the internal node | 05:12 |
| jam | ah, sure | 05:12 |
| lifeless | a key of :bloom: which is illegal to generate from bzrlib, then the binary bytes | 05:12 |
| jam | lifeless: interesting. at *each* internal node? | 05:13 |
| lifeless | jam: yes | 05:13 |
| lifeless | jam: higher internal nodes we may want to not have the filter | 05:14 |
| lifeless | jam: but its clearly of most use down adjacent to leaves | 05:14 |
| jam | other than giving you less work to do higher up :) | 05:14 |
| jam | but it goes white pretty quickly | 05:15 |
| lifeless | right | 05:15 |
| jam | (or black, if your terminal is white background :) | 05:15 |
| lifeless | the higher the layer the more bits needed for a useful filter | 05:15 |
| lifeless | but the less IO needed to encounter a filter | 05:15 |
| lifeless | so is array an array of bytes or bits | 05:18 |
| jam | lifeless: a = array.array('B') | 05:19 |
| jam | Bytes | 05:19 |
| jam | self._array[offset >> 3] & Bloom.bitmask[offset & 0x7] | 05:19 |
| lifeless | so, array(B, bytes) | 05:19 |
| lifeless | why didn't you use array.write() ? | 05:20 |
| jam | array(B, num_bytes) | 05:20 |
| lifeless | The constructor is: | 05:20 |
| lifeless | 05:20 | |
| lifeless | array(typecode [, initializer]) -- create a new array | 05:20 |
| lifeless | initialized from the optional initializer value, which must be a list, | 05:20 |
| lifeless | | string. or iterable over elements of the appropriate type. | 05:20 |
| jam | lifeless: # stupidly, there's no good way that I can see of resizing an array | 05:20 |
| jam | # without allocing a huge string to do so | 05:20 |
| jam | # thus I use this, slightly odd, method: | 05:20 |
| lifeless | jam: yes, I'm toing bin_to_array here though | 05:21 |
| jam | lifeless: if you already have it as a string, just shove that into array.array('B', mystring) | 05:21 |
| lifeless | jam: yes, thats what I said isn't it ? :) | 05:21 |
| jam | lifeless: oh, by the way, what constraints are on your key values? | 05:22 |
| jam | Isn't there something about being "no-whitespace , utf-8" ? | 05:22 |
| lifeless | yes | 05:22 |
| jam | this would be raw bits, so could take on any value | 05:22 |
| lifeless | same as bzrlib.index | 05:22 |
| jam | like \n | 05:22 |
| lifeless | jam: indeed, I handle that already: P | 05:22 |
| jam | The most efficient, "safe" encoding I've encounter is something like base85 | 05:23 |
| lifeless | jam: '\n'.join(content) - this is all encoded by zlib for us | 05:23 |
| jam | lifeless: but in "_InternalNode.__init__() you use _parse_lines(bytes.split('\n'))" | 05:24 |
| jam | or is this going in somewhere that isn't being compressed. | 05:24 |
| lifeless | jam: nope, its at the end of that list | 05:25 |
| lifeless | ok, array_to_bin is slightly broken | 05:26 |
| lifeless | in that its got somehow different output vs .tostring() | 05:26 |
| jam | lifeless: I think you miss what it is | 05:27 |
| jam | array_to_bin => 0101101101110 | 05:27 |
| jam | as in the numerals | 05:27 |
| lifeless | jam: oh! | 05:27 |
| jam | ascii text :) | 05:27 |
| lifeless | indeed, not what I thought | 05:27 |
| lifeless | where is more caffeine :) | 05:27 |
| jam | lifeless: I think you can just dump the array bytes as you asked earlier | 05:27 |
| lifeless | I've just committed a round trip bloom support for the parser | 05:28 |
| lifeless | now to hook up creating these for some nodes | 05:28 |
| jam | lifeless: real quick, to figure out the position of a leaf node, you need the offsets for all the internal nodes added together? | 05:30 |
| lifeless | no | 05:30 |
| jam | node_index = offset + node.offset + pos | 05:30 |
| jam | and | 05:30 |
| jam | offset = offset + self._row_lengths[row] | 05:30 |
| lifeless | sum (row_lengths before the row this internal node is in) + this_node.offset + pos | 05:30 |
| jam | both seem to be 'accumulating' | 05:31 |
| lifeless | you need the sum of the rows above | 05:31 |
| lifeless | you need this nodes offset | 05:31 |
| jam | oj | 05:31 |
| jam | ok | 05:31 |
| lifeless | and you need the offset (0 based) from the pointers in this node | 05:31 |
| lifeless | this is constant whether you are looking for a leaf or internal | 05:32 |
| jam | lifeless: so that is the row offset for the entry in the row you are looking up | 05:35 |
| jam | so if I'm on the root node, I have a row_offset of 1 for the first layer of internal nodes | 05:36 |
| lifeless | yes | 05:36 |
| lifeless | off by one in my description | 05:36 |
| lifeless | sum(row_lengths including this row) + internal_node.offset + pos_from_bisect_right(internal_node.keys) | 05:37 |
| lifeless | jam: one trivial optimisation would be to precalculate the sums | 05:38 |
| jam | meh... :) | 05:38 |
| lifeless | jam: :P | 05:38 |
| jam | lifeless: just to be clear, _InternalNode.keys is a sorted list, _LeafNode.keys is a dictionary, right? | 05:46 |
| lifeless | yes | 05:46 |
| lifeless | because bisect in the former and existence in the latter | 05:46 |
| jam | lifeless: sure, though you can bisect in the latter, too | 05:46 |
| jam | just bisect_left | 05:46 |
| lifeless | its slower usually | 05:46 |
| lifeless | but you could consider just plucking out the keys you want as it parses | 05:46 |
| jam | interesting thought | 05:47 |
| jam | anyway, I was confused by Node.attribute having a different signature | 05:47 |
| jam | fixing | 05:47 |
| jam | lifeless: I tend to get confused that you are ~lifeless on LP, but ~robertc on email and people.ubuntu.com | 05:52 |
| lifeless | sorry :) | 05:53 |
| poolie | actually i think he's robert@canonical, and neither of the other two work there | 05:56 |
| lifeless | robertc will | 05:56 |
| lifeless | as well as first.last | 05:56 |
| poolie | hm | 05:57 |
| poolie | two of your patches are approved with tweaks | 05:59 |
| jam | lifeless: was one of your "fixes" to the tests to bump up the number of nodes from 25k => 100k? Because that test seems to be excruciatingly slow right now | 06:00 |
| jam | I'm not sure if I broke something, or if it just refuses to finish | 06:00 |
| lifeless | 100K | 06:00 |
| lifeless | its due to the extra packing | 06:00 |
| lifeless | yes, it takes a lot of nodes to make a 3-level index. | 06:01 |
| jam | well, then I guess I have to poke at that before I can test my iter_entries fixes :) | 06:01 |
| jam | OK 215798ms | 06:01 |
| lifeless | jam: its writing performance :) | 06:01 |
| jam | Is a bit too long to wait | 06:01 |
| lifeless | erm | 06:02 |
| lifeless | it was 12 seconds for me | 06:02 |
| lifeless | I lie | 06:02 |
| lifeless | 90seconds | 06:02 |
| lifeless | and yes, I was cursing | 06:02 |
| lifeless | there are two of them | 06:02 |
| jam | well, that has a bit of pdb time in there | 06:07 |
| jam | ^| doesn't work on win32 | 06:08 |
| lifeless | :) | 06:08 |
| jam | lifeless: 34480ms with my performance tweaks back in | 06:13 |
| jam | but 3 test failures | 06:13 |
| jam | because now it doesn't pack *quite* as efficiently | 06:14 |
| jam | lifeless: is that just "pretend it is correct" ? | 06:15 |
| jam | (specifically, "test_2_leaves_1_0") | 06:15 |
| lifeless | jam: well, if you don't make them pass, I'll have to :) | 06:17 |
| lifeless | jam: or are you asking 'how do I decide the new results are ok' ? | 06:17 |
| jam | lifeless: right | 06:18 |
| jam | I think I just need to decrease the number of nodes for test_2_leaves_1_0 | 06:18 |
| jam | since it seems specific about testing 2 leaves | 06:18 |
| igc | poolie: thanks for the reviews. Please see my reply to the content filtering one. | 06:19 |
| Odd_Bloke | Hacking bits out of PQM is fun. :) | 06:19 |
| lifeless | jam: yes, I look and poke, and tweak | 06:19 |
| lifeless | Odd_Bloke: cool | 06:19 |
| Odd_Bloke | Seriously, I could do this all summer. | 06:19 |
| Odd_Bloke | Oh, wait. :p | 06:19 |
| lifeless | ok, in theory we have bloom filters now | 06:20 |
| jam | lifeless: ugh, one of the failing tests is iter_all_entries_reads... aka the slow one | 06:22 |
| lifeless | jam: I try to improve the resiliency each time I touch them, but fundamentally its a little hard to test some stuff without enough data to , well, test it | 06:22 |
| jam | it seems a bit odd to be subject to the whims of the compressor | 06:23 |
| jam | as it makes it a possible problem based on what zlib they have | 06:23 |
| lifeless | the compressor is part of the format | 06:23 |
| jam | lifeless: but you can be compatible with zlib and not give exactly the same output | 06:23 |
| lifeless | jam: zlib is seriously stable | 06:23 |
| lifeless | jam: this is true, and such folk can send patches :P | 06:24 |
| lifeless | dang | 06:24 |
| lifeless | File "/home/robertc/.bazaar/plugins/index2/btree_index.py", line 93, in finish_node | 06:24 |
| lifeless | raise AssertionError("Not enough space for bloom filter.") | 06:24 |
| lifeless | AssertionError: Not enough space for bloom filter. | 06:24 |
| lifeless | ah, found the bug | 06:26 |
| poolie | lifeless, can we talk briefly? | 06:26 |
| lifeless | sorry, I'm dressed now | 06:26 |
| jam | no talking while clothed.... hmm | 06:27 |
| jam | sounds like a morning after issue | 06:28 |
| fullermd | jam: You haven't done anything recently with FreeBSD trees, have you? | 06:32 |
| jam | fullermd: not in a long time, no | 06:33 |
| * fullermd nods. | 06:33 | |
| fullermd | Didn't think so. | 06:33 |
| jam | you sound aggressive with that :) | 06:33 |
| fullermd | Well, I've been paying very poor attention since April :) | 06:33 |
| fullermd | I just threw together that ShowStoppers page on it on a whim earlier today, and wondered if you had anything new to add to it. | 06:34 |
| fullermd | But I guess "It's too damn big and too damn slow" is still a good first hurdle. | 06:35 |
| jam | lifeless: unfortunately, your choice to pick the "middle" of the lexi-sorted nodes doesn't work well in my repo | 06:43 |
| jam | search_from_revid in 0.877 | 06:43 |
| jam | After spending a lot of time setting it up | 06:43 |
| jam | also unfortunately, the get_components_positions(2000) triggers the "unable to cache this many nodes" assertion | 06:45 |
| lifeless | jam: lol :P | 06:51 |
| lifeless | jam: that was written with your work in mind | 06:51 |
| jam | lifeless: what do you think about splitting an internal-node cache from a leaf-node cache? | 06:51 |
| lifeless | jam: neutral | 06:52 |
| jam | for the new "iter_entries" I'll only hit the internal nodes 1 time | 06:52 |
| jam | so they don't get priority over the leaf nodes | 06:52 |
| jam | even if there are 100 keys hitting the node | 06:52 |
| lifeless | jam: why not use _read_nodes then for the leaf nodes? | 06:55 |
| jam | lifeless: well, do we *never* want to cache leaf nodes? | 06:55 |
| jam | My idea with a 2 caches, is that both could be LRU's | 06:55 |
| lifeless | jam: sure, that works too | 06:56 |
| jam | lifeless: but for the "get it working" that is my plan atm | 06:56 |
| jam | also, at this point I wish you wrote them as 'selftest --benchmark' so I could run some of them without running all of them :) | 06:59 |
| lifeless | sorry :) | 06:59 |
| jam | ^VI# | 07:00 |
| jam | is my friend | 07:01 |
| jam | I guess that is ^v<scroll>I# <enter> | 07:01 |
| lifeless | hmm, how best to copy an in-progress bloom - copy.deep_copy ? | 07:01 |
| lifeless | will array.array deep copy correctly? | 07:01 |
| jam | lifeless: not sure, there are only 4 member variables aside from the array | 07:02 |
| jam | __deepcopy__(...) | 07:02 |
| jam | copy(array) | 07:02 |
| jam | Return a copy of the array. | 07:02 |
| jam | lifeless: ^^ it looks like array has a __deepcopy__ member | 07:02 |
| lifeless | thanks :) | 07:03 |
| jam | lifeless: anyway, sleepytime, its after 1am here | 07:03 |
| lifeless | ok, I have bloom creation happ | 07:03 |
| lifeless | jam: gnight | 07:03 |
| jam | I have some code, for multi-way bisect, but it won't help randomly iterating one key at a time | 07:04 |
| jam | so I'll look closer at that | 07:04 |
| lifeless | ok | 07:04 |
| lifeless | I'll have miss-avoidance in a few minutes, then go on to test annotate for that patch | 07:04 |
| igc | lifeless: I'm running indexbench.py now. The moz one finished quickly; the OOo one (1.15M keys) took a long while for the 1st part and is up to the 2nd part now | 07:41 |
| lifeless | igc: cool - latest version I presume ? | 07:41 |
| igc | the only weird thing is that the last metric is 0.00 | 07:41 |
| igc | I *think* so | 07:41 |
| lifeless | igc: note that a fully packed index is not ideal :) | 07:41 |
| lifeless | igc: because we want to find out realworld (autopacked only) behaviour | 07:42 |
| lifeless | igc: does it have miss_torture in the output ? | 07:43 |
| igc | lifeless: hmm - my benchmarking repos are usually fully packed | 07:43 |
| lifeless | igc: yes, I've pointed this out before :) | 07:43 |
| igc | miss_torture is the one coming out as 0.00 | 07:43 |
| lifeless | (not to you specifically, but on the list) | 07:43 |
| AfC | Looking for subjective opinions: how much should I worry about what `bzr gannotate` shows being correct? Is it a reflection of primary underlying relationships, or is it just a slash at the task of identifying things? | 07:43 |
| lifeless | AfC: what do you mean by correct? It should give you a pretty good idea of the last change occuring on a line | 07:44 |
| AfC | I have managed to contrive situations where the change is being attributed to a merge, not a source revision. This is a bit disturbing. | 07:45 |
| lifeless | AfC: that occurs when eiher A) the merge changed the line, or B) the same change was made on both sides | 07:46 |
| AfC | [resulting from the following: cherry pick something off of branch A onto B. No problem, although yes the new revision will claim to have invented these lines. Then merge B back into A, and suddenly gannotate shows not the original revision from A, *nor* the new revision on B, but the merge revision being the author of those lines] | 07:47 |
| lifeless | AfC: right; it would be better to show *both*, but we show the point at which we can't decide. | 07:47 |
| AfC | lifeless: well, having to choose one of the other, fine, but choosing the merge?!? | 07:47 |
| lifeless | AfC: if you click on it, you can annotate both sources and see where it comes from | 07:48 |
| lifeless | AfC: say it wasn't a cherrypick, but was some copyright claim or something | 07:48 |
| AfC | lifeless: ok. My real question was whether this was something I needed to worry about and avoid creating. | 07:48 |
| lifeless | AfC: no, its totally normal and we'll likely improve the UI further to give more helpful results | 07:48 |
| AfC | Ok | 07:49 |
| AfC | (it was quite worrying when I first saw it) | 07:49 |
| lifeless | igc: 0.00 is expected | 07:49 |
| lifeless | igc: there are no keys that are in the repository and not in a given index | 07:49 |
| AfC | (I tried merge -r X..Y; I tried rebase; various permutations of branch creation order and [re]merge sequencing) | 07:50 |
| lifeless | AfC: sounds like we need a page explaining what annotate *actually* does | 07:51 |
| AfC | lifeless: I don't use it much, but I came to appreciate that (until now) it should real revisions being the source of things, not merges. | 07:52 |
| AfC | showed* | 07:53 |
| AfC | Jeesh. Time for a break, apparently. | 07:53 |
| lifeless | AfC: right; and doing that implies handling origins(line) > 1 :) | 07:54 |
| berto- | is there some way for me to save BZR_REMOTE_PATH for a given repository? | 07:58 |
| gour | berto-: see bzr_remote_path config variable | 08:02 |
| gour | "..This value may only be specified in locations.conf"... | 08:02 |
| catsclaw | Oh, there we are | 08:02 |
| berto- | gour where am i looking for the variable? some documentation, the wiki? | 08:03 |
| gour | berto-: http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html | 08:03 |
| gour | berto-: and http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html | 08:03 |
| berto- | gour: thanks! | 08:03 |
| catsclaw | Quick question: loggerhead only works in two modes, server and proxy, right? Not as a cgi? | 08:03 |
| spiv | Also, "bzr help configuration", but you can read the same info in http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#configuration-settings | 08:05 |
| berto- | gour: locations.conf works great! | 08:07 |
| mwhudson | catsclaw: yes | 08:08 |
| catsclaw | Well, great. | 08:08 |
| mwhudson | catsclaw: you could probably make it work as a cgi well enough for small branches | 08:08 |
| mwhudson | but anything more than a couple of thousand revisions would be pretty darned slow | 08:08 |
| gour | berto-: that's not true! | 08:09 |
| gour | berto-: bzr works great ;) | 08:09 |
| berto- | haha | 08:09 |
| catsclaw | Maybe so. But I can't run servers or set the proxy path on my host | 08:09 |
| gour | berto-: however, many like complicated things, although i'm not the one of them :-) | 08:10 |
| catsclaw | So the lack of CGI support is extremely annoying | 08:10 |
| gour | hmm, cannot say much about it... | 08:10 |
| gour | catsclaw: what do you need? | 08:11 |
| gour | maybe there is 'the other way' | 08:11 |
| catsclaw | Ideally, I'd like a way to browse the repository from the web, and edit text files through a web browser | 08:11 |
| catsclaw | I was hoping to find the "browse the repository" piece separately, and just hack it for the "edit text files" piece. | 08:12 |
| mwhudson | catsclaw: it's just a wsgi thing these days | 08:12 |
| mwhudson | if there's a cgi wsgi container, it should be a snap to set up | 08:12 |
| luks | if you just want to browse the last revision of files (similar to svn's webdav listing), you can try http://bzr.oxygene.sk/bzrbrowse.cgi/bzrbrowse/trunk | 08:13 |
| catsclaw | There's a cgi and Fastcgi wrapper for wsgi | 08:14 |
| igc | lifeless: that's still running but some good news ... | 08:16 |
| igc | iter_all_entries: 1037s -> 13s | 08:16 |
| catsclaw | All right. It's too late to bother with this right now. | 08:19 |
| catsclaw | I'll have to figure out the FastCGI->WSGI stuff later | 08:20 |
| catsclaw | Later | 08:20 |
| berto- | is it possible to branch off a bzrsvn branch then merge between the two bzr branches? | 08:24 |
| berto- | nm, just tried it, looks to work nicely. :) | 08:24 |
| igc | night all | 08:30 |
| berto- | in order to push in local changes into bzrsvn i had to merge, then rebase, then use svn-push. that seemed to work. but, then i checked svn and all my changes were pushed in as one commit. is there some way to replay all my commits? | 08:33 |
| lifeless | igc: gnight | 08:33 |
| berto- | looks like that happened because i had all the changes in a bzr repo then i merged them into my bzrsvn repo. | 08:34 |
| berto- | jelmer: bzrsvn is working fine with py2.5. looks like it's not too happy on py2.4, at least not on debian etch. | 08:35 |
| jelmer | berto-: only mainline commits are pushed | 08:48 |
| jelmer | berto-: Thanks for the info - any chance you can file a bug saying 2.4 is broken? | 08:48 |
| jelmer | I'll see if I can fix that before the release, or at least warn people appropriately | 08:48 |
| berto- | i updated the Requirements list on the bzrsvn wiki page. | 08:49 |
| jelmer | I consider this a bug rather than a specific requirement | 08:53 |
| berto- | jelmer: https://bugs.launchpad.net/bzr-svn/+bug/244786 | 08:54 |
| ubottu | Launchpad bug 244786 in bzr-svn "BzrSvn does not work well on Python2.4" [Undecided,New] | 08:54 |
| berto- | heh, gotta love mr. ubottu :) | 08:54 |
| jelmer | berto-: thanks | 08:55 |
| Odd_Bloke | Does anyone know where I can find the source for AfC's "There's A Branch Here" pages? ISTR he posted on the list about it at some point, but I can't seem to find it from a (cursory) search. | 09:24 |
| james_w | hey Odd_Bloke | 09:25 |
| jelmer | Odd_Bloke: You mean this sort of thing: http://people.samba.org/bzr/jelmer/bzr-svn/0.4/ ? | 09:26 |
| james_w | http://article.gmane.org/gmane.comp.version-control.bazaar-ng.general/41665/match= | 09:27 |
| Odd_Bloke | james_w: o/ | 09:27 |
| jelmer | ah, wasn't aware of that one, only of Michael Ellerman's htmllog plugin | 09:28 |
| thekorn | 9hi, how can I resolve a conflict where a file was added? | 09:42 |
| thekorn | I mean, if there are string conflicts, I get this '>>>>' marks and so on, | 09:43 |
| thekorn | and edit this sections manually, then run bzr resolve | 09:43 |
| thekorn | but what can I do if a file with the same name was added in the two branches | 09:44 |
| james_w | thekorn: place the one you want at that path, with the content that you want, and then run "bzr resolve file" | 09:53 |
| james_w | I believe if you want the one that got moved to .moved you "bzr rm file; bzr mv file.moved file" | 09:53 |
| thekorn | james_w: ok, thanks, bzr is so easy :) | 09:56 |
| james_w | this is one of the places that I think it's not that intuitive. | 09:56 |
| james_w | if we get file joins then this case will be much better. | 09:57 |
| james_w | thekorn: have you seen "bzr help conflicts"? | 09:57 |
| thekorn | right, 'bzr resolve' without filename did not work | 09:57 |
| james_w | any advice on improving it would be appreciated. | 09:57 |
| thekorn | james_w: no, I've only looked for bzr help resolve | 09:58 |
| thekorn | so maybe a hint there to also check bzr help conflicts would be cool | 09:59 |
| thekorn | oh, nevermind, there is one | 10:00 |
| Odd_Bloke | Is there a release schedule for 1.6 yet, or is it just "when it's done"? | 10:07 |
| AfC | Odd_Bloke: I never published it. | 10:07 |
| AfC | Odd_Bloke: 'cause no one actually asked me | 10:07 |
| harobed | hi, in bazaar, can I modify one mistake in log message of last revision commit ? | 10:07 |
| Odd_Bloke | harobed: 'bzr uncommit', then commit again. | 10:07 |
| harobed | Odd_Bloke: I need to do one uncommit by revisions ? | 10:08 |
| AfC | Odd_Bloke: it is, as you would expect, embedded in a [very very thin] template that is used to generate all those pages, but the logic looks like it could be lifted out without too much trouble. | 10:08 |
| AfC | Odd_Bloke: bug me about it again in 3-4 hours and I'll send it your way | 10:08 |
| harobed | example, I'm on revisions number 100 and my mistake is in revisions number 85 ? I need to uncommit to revisions 85 ? | 10:08 |
| Odd_Bloke | AfC: I'll probably be in bed, but I'll bug you again at some point. :) | 10:09 |
| harobed | I can't modify log message in .bzr file ? | 10:09 |
| Odd_Bloke | harobed: Ah, sorry, I misunderstood your question. | 10:09 |
| harobed | Odd_Bloke: hmm, first, my current revisions is 100 | 10:09 |
| matkor | harobed: revert only bad commit like: bzr merge -r 85..84 | 10:10 |
| AfC | Odd_Bloke: (ie, having explained that, I'm happy to email it to you, but it's not really general consumption, y'digg?) | 10:10 |
| harobed | Odd_Bloke: I've mistake in log message of revisions 80 | 10:10 |
| Odd_Bloke | harobed: It is possible, but you'd be rewriting history which means that you wouldn't be able to collaborate with other people who've branched from you. | 10:10 |
| Odd_Bloke | AfC: Cool, my address is D.M.Watkins at warwick.ac.uk. :) | 10:10 |
| Odd_Bloke | AfC: Thanks! | 10:10 |
| === visik7 is now known as Guest77446 | ||
| Odd_Bloke | harobed: Is the mistake in the commit message or in the data committed? | 10:11 |
| === visi_ is now known as visik7 | ||
| harobed | Odd_Bloke: commit message only, not the code data | 10:11 |
| Odd_Bloke | harobed: OK, have you shared this branch with anyone? | 10:12 |
| harobed | Odd_Bloke: not | 10:12 |
| Odd_Bloke | harobed: Then it is possible to do, but I'm not sure of the best way to do it. | 10:13 |
| Odd_Bloke | Possibly rebase. | 10:14 |
| harobed | rebase ? | 10:16 |
| === thekorn_ is now known as thekorn | ||
| * mgedmin made bzr crash | 13:37 | |
| Odd_Bloke | mgedmin: How so? | 13:38 |
| * mgedmin tried to do a bzr pull in a bound branch | 13:39 | |
| mgedmin | hm, I have 1.3.1 here... let's upgrade and try again | 13:39 |
| Odd_Bloke | mgedmin: Could you pastebin the error somewhere? | 13:41 |
| Odd_Bloke | ubottu: paste | 13:41 |
| ubottu | pastebin is a service to post multiple-lined texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu.com (make sure you give us the URL for your paste - see also the channel topic) | 13:41 |
| nandersson | Where looks Mac OS X for the Bzr plugin-directory? | 13:42 |
| james_w | nandersson: bzr --version should tell you | 13:43 |
| mgedmin | Odd_Bloke: http://paste.ubuntu.com/24463/ | 13:44 |
| nandersson | james_w, Thanks! I'll that as fast as I found out how to get a command line :) | 13:46 |
| Odd_Bloke | mgedmin: OK, I don't know enough about that part of the code to understand the error, but you want to 'bzr update' in a bound branch. | 13:46 |
| mgedmin | I was trying to pull in changes from someone else's branch, not my bound branch's upstream | 13:47 |
| mgedmin | bzr merge works, btw | 13:47 |
| nandersson | james_w, there you go :) /Users/[username]/.bazaar/plugins - Thank you! | 13:48 |
| * mgedmin reads bzr help checkouts now | 13:48 | |
| nandersson | Now I'll try to see if I can get BzrEclipse to work on Mac OS X :) | 13:49 |
| lifeless | gnight everyone | 13:51 |
| pygi | hi hi | 13:53 |
| nandersson | Now got BzrEclipse running on Mac OS X 10.4 :) | 14:03 |
| Tsmith | how expensive is creating a bzr's branch on a 186 MB codebase (text only)? is it feasible to have hundreds/thousands of branches for each complex feature merge from one site to another? | 14:47 |
| weigon_ | Tsmith: are you using a shared repo ? | 14:50 |
| Tsmith | i have no idea | 14:50 |
| Tsmith | would a bzr info help? | 14:50 |
| weigon_ | yep | 14:50 |
| Tsmith | $ bzr info | 14:51 |
| Tsmith | Checkout (format: pack-0.92) | 14:51 |
| Tsmith | Location: | 14:51 |
| Tsmith | checkout root: . | 14:51 |
| Tsmith | checkout of branch: /var/bzr/blinds.ca | 14:51 |
| Tsmith | basically the same thing for /var/bzr/blinds.com, where the patch is coming from | 14:51 |
| Tsmith | yes | 14:52 |
| Tsmith | i believe it is a shared repo | 14:52 |
| Tsmith | i may be "doing it wrong", but my team uses bzr much like svn; like bzr co from a remote repository, bzr up and every thing | 14:52 |
| Tsmith | 100K /var/bzr/blinds.com/branches | 14:53 |
| Tsmith | 22M /var/bzr/blinds.com | 14:53 |
| Tsmith | hmm does it really only use 100 KB? | 14:53 |
| Tsmith | that has to be impossible | 14:54 |
| Tsmith | k i think i answered my question w/ your motivation | 14:54 |
| Tsmith | thanks | 14:54 |
| Tsmith | the answer is "Using a remote repo w/o trees, it is very inexpensive to branch." | 14:56 |
| robsta | hi | 14:58 |
| robsta | is there any way to hard reset a checkout? there is some stale lock and even "break-lock" can't fix it any more | 14:58 |
| * mgedmin upgrades to bzr 1.5 | 15:18 | |
| mgedmin | same error! | 15:20 |
| mgedmin | yay | 15:20 |
| mgedmin | my bug is https://bugs.launchpad.net/bzr/+bug/209689 | 15:28 |
| ubottu | Launchpad bug 209689 in bzr "KeyError in transport close _file_streams while pulling into a bound branch" [Undecided,New] | 15:28 |
| mgedmin | why oh why bzr always punishes me for trying to start using it??? | 15:28 |
| * mgedmin unhappy | 15:28 | |
| nandersson | Is there I way to "Checkout from Bazaar" (launchpad) directly from BzrEclipse? | 15:30 |
| nandersson | "a way to" | 15:30 |
| jelmer | mgedmin: thanks for the bug report | 15:31 |
| mgedmin | jelmer: no problem; have fun fixing it :-) | 15:33 |
| NfNitLoop | nandersson: can't you "create a new project" and then choose bazaar -> branch or something like that? | 15:55 |
| Tsmith | how do you comment in python? | 17:08 |
| Tsmith | (trying to port svn hook to mantis) | 17:08 |
| andrea-bs | Tsmith: # text | 17:09 |
| Tsmith | thanks | 17:09 |
| andrea-bs | you're welcome :) | 17:09 |
| abentley | lifeless: ping | 17:13 |
| jelmer | 'evening Aaron | 17:14 |
| jelmer | abentley: Do you think it makes sense to move some of the code that figures out whether or not a revision has been merged to bzrlib? | 17:15 |
| abentley | Code in BundleBuggy? | 17:15 |
| jelmer | yeah | 17:16 |
| jelmer | since I'm about to duplicate more of it in my plugin | 17:16 |
| jelmer | and I suspect the launchpad merge request stuff has similar bits? | 17:17 |
| abentley | It doesn't really seem like it. | 17:18 |
| abentley | Too short to bother with. | 17:18 |
| jelmer | abentley: No other objections though? | 17:20 |
| jelmer | abentley: I'm looking at doing pattern matches seeing if .diffs have been merged | 17:21 |
| abentley | Well, considering we've already got an implementation of missing, I'm concerned. | 17:21 |
| jelmer | sorry, I think I'm not wording this very well | 17:22 |
| jelmer | let me rephrase | 17:22 |
| jelmer | abentley: Do you think it makes sense to move some of the code that figures out whether or not a merge directive has been merged to bzrlib? | 17:22 |
| jelmer | e.g. as a MergeDirective.was_merged(branch_tip) function | 17:23 |
| abentley | so basically b = Branch(); graph = b.repo.get_graph(); md.revision_id in graph.heads(md.revision_id, b.last_revision) | 17:24 |
| mkanat | mwhudson: Still no 100% CPU. :-) | 17:25 |
| nandersson | It seems I can not check out a Launchpad project directly from BzrEclipse, but I have to do a manual checkout first from the command line and then create a new project based on that branch in Eclipse. | 17:25 |
| jelmer | abentley: Yes - for the current format | 17:26 |
| nandersson | There is no thing like it's CVS counterpart "Create project from CVS" | 17:26 |
| jelmer | abentley: regular patches or git merge directives (not sure how they call them) will be more complicated | 17:26 |
| abentley | Well, I'm not clear whether heads is 100% trustworthy at the moment. If it is, I guess it's okay. | 17:27 |
| Pilky | does anybody know if anyone has done any sort of plugin for doing a --fixes thing that works with lighthouseapp.com? | 17:39 |
| luks | Pilky: I don't think there is any plugin that touches external bug tracker based on the --fixes flag | 17:45 |
| pickscrape | Can anyone point me at the steps I need to take to install loggerhead? | 17:47 |
| Pilky | luks: isn't the launchpad integration done in a plugin, or does launchpad read the info from the branch when it's pushed up? | 17:50 |
| luks | Pilky: launchpad reads it from pushed branches on it's own | 17:52 |
| Pilky | ok | 17:52 |
| Pilky | guess it's something I'll have to look into at some point in the future | 17:52 |
| === thekorn_ is now known as thekorn | ||
| fog | I am trying to develop a bzr adding for MonoDevelop and calling bzr from the cmdline is quite slow. I'd like to write a little helper that communicated using stdio with the addin and answer simple queries like "whats the status of file xxx?". what's the best place to start? documentation or example code is available? | 18:07 |
| LeoNerd | Maybe look at 'bzr shell' ? | 18:07 |
| james_w | fog: jam had a plugin that was similar to this, bzr-service I think it was called. | 18:08 |
| fog | thak you both | 18:08 |
| jam | fog: and eventually bzr-xmloutput is supposed to turn into a full RPC for a service responding to bzr queries. | 18:09 |
| jam | bzr-service spawns something that you communicate over (currently TCP sockets) eventually should be named pipes on windows / unix sockets otherwise | 18:09 |
| fog | jam: I am currently using xmloutput but does not fit the monodevelop model well | 18:09 |
| jam | though I haven't touched it in a long time | 18:09 |
| fog | i need 3 different commands/outputs to just get the right information for a file | 18:10 |
| jam | that may not change for bzr-service, since it is just a proxy for running "bzr foo" | 18:10 |
| beuno | fog, Verterok has an xml-rpc client | 18:10 |
| fog | file-id to see if a file is under version control, then status to get its status and then log to get extra information | 18:10 |
| beuno | it uses the same concept of bzr-service, so it doesn't spawn a new bzr every time | 18:10 |
| beuno | actually, it's going to be the new version of xmloutput | 18:11 |
| beuno | fog, https://code.edge.launchpad.net/~guillo.gonzo/bzr-xmloutput/xmlrpc | 18:12 |
| fog | not spawning is fine, it is the spawning that is veeery slow. | 18:12 |
| fog | beuno: thanks | 18:12 |
| beuno | fog, np. He uses it for eclipse, and this made it *much* faster | 18:12 |
| leandro_ | hi all. I'm new (comming from cvs/svn) to bzr and I'd like to create a new repository for my project. I decided to used the svn layout MY-PROJECT/trunk. Should I create MY-PROJECT with --no-trees ? | 19:12 |
| leandro_ | I'm planning to store all branches under MY-PROJECT/ | 19:12 |
| james_w | leandro_: if you are planning to do your work there then you probably do not want --no-trees | 19:17 |
| james_w | if you are setting this up on a server, and then you are going to use branches/checkouts locally to do the work then you probably do want --no-trees | 19:18 |
| james_w | the second also applies if you are doing it in two places on the same machine, e.g. /var/repos/whatever and ~/devel/whatever for work. | 19:18 |
| leandro_ | james_w: I'm assuming all work will be done inside MY-PROJECT/trunk or My-PROJECT/branch-x | 19:18 |
| leandro_ | james_w: yes, I'm doing it on a server | 19:19 |
| leandro_ | but i will checkout MY-PROJECT/trunk, not My-PROJECT | 19:19 |
| james_w | yep, then I suspect you want --no-trees | 19:20 |
| leandro_ | forget --no-trees then? | 19:20 |
| leandro_ | ah..ok | 19:20 |
| leandro_ | james_w: tks | 19:22 |
| blueyed | I've asked a few days ago already about keeping local changes in a main.local branch (jam has helped me), but now it seems that every now and then I need to explicitly revert this "local" diff when merging.. the setup is as follows: "main" (dev branch) and "main.local", which has changes I don't want in "main", but for feature branches.. I've done reverse cherrypicking, but somehow bzr seems to forget about it, when I merge between those | 19:25 |
| blueyed | branches now. | 19:25 |
| abentley | jam: So the issue with iter_entries_by_dir is: given a, a/b, c, c/d, you think it'll give a, c, d, b instead of a, c, b, d? | 19:26 |
| jam | abentley: correct | 19:27 |
| jam | the last inserted was the last child of the previous directory | 19:27 |
| jam | rather than the first | 19:27 |
| jam | abentley: however, it may not show up in the children, but only in the grandchildren (underneath b and d) | 19:28 |
| jam | nm, you already have grandchildren of '' | 19:28 |
| abentley | jam: Okay. That gives me a test I can use. | 19:29 |
| NfNitLoop | blueyed: "reverse cherrypicking"? | 19:32 |
| blueyed | NfNitLoop: well, not really.. but in general: merge the other branch, but drop the changes which should differ ("bzr revert ."), then commit. | 19:33 |
| blueyed | basically, I want to have a (submit) branch from "main", with changes to "main", that should never make it into "main" (when merging from or into main) | 19:36 |
| blueyed | NfNitLoop: "reverse cherrypicking" is described at http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#reverse-cherrypicking | 19:37 |
| blueyed | Is this not possible, because bazaar does not track cherrypick merges yet? | 19:57 |
| abentley | jam: Are you satisfied with my email explanation of why we don't need to test the unchanged case? | 20:15 |
| jam | abentley: for the other ones, yes | 20:16 |
| jam | I wasn't sure if that was true, just was pointing out it didn't show in the changes | 20:16 |
| abentley | Are there some that you think we *should* be testing that we're not? | 20:16 |
| abentley | jam: I'm not sure what "for the other ones" means. | 20:18 |
| jam | for things other than testing iter_entries_by_dir() | 20:19 |
| === mw is now known as mw|food | ||
| NfNitLoop | blueyed: your answer seems to be in that document. "Unlike a normal merge, Bazaar does not currently track cherrypicks." | 20:21 |
| abentley | jam: Okay, I've added an iter_entries_by_dir test (using the example in tree.py) and an annotate-with-rename test, and plan to merge everything I've submitted in that series. | 20:22 |
| blueyed | NfNitLoop: yes, that's what I've thought now.. I cannot believe though that this workflow (having a branch with permanent changes) is not supported.. | 20:22 |
| abentley | Thanks for your reviews. | 20:22 |
| jam | I'm not sure that I got to everything | 20:22 |
| jam | but I at least did a good amount | 20:22 |
| NfNitLoop | blueyed: it's only when you cherrypick that it gets forgotten. Usually you just branch off from main and then 'merge' (non-cherrypick) from main as you move forward. | 20:23 |
| name | hey | 20:24 |
| NfNitLoop | blueyed: there's also another plugin/workflow which you may find useful... | 20:24 |
| NfNitLoop | weave? thread? I forget. | 20:24 |
| name | how do i see which branches i have got in my working copy | 20:24 |
| NfNitLoop | bzr switch? | 20:25 |
| blueyed | NfNitLoop: but I want to merge from and to main.local to main.. that seems to be the problem.. loom? (which seems to provide threads) | 20:25 |
| blueyed | name: "bzr info -v"? | 20:25 |
| NfNitLoop | blueyed: aah, loom. | 20:25 |
| name | ah bzr branching is kinda different than git ;) | 20:26 |
| NfNitLoop | I'm not sure if loom is what you want. | 20:26 |
| NfNitLoop | (blueyed) | 20:26 |
| abentley | jam: You did everything directly related to PreviewTree that I've submitted. Which is great. | 20:27 |
| abentley | jam: When lifeless turns up, we can figure out what to do about get_parent_map | 20:27 |
| name | now to my real question. what file in loggerhead shows the source of the file you are viewing? i am trying to implement syntax highlightning | 20:28 |
| NfNitLoop | blueyed: I guess I'm not quite getting your workflow. If you keep main and your branch separate and never merge in changes from main then eventually they'll diverge so that merging from branch into main becomes painful... | 20:28 |
| blueyed | NfNitLoop: I merge changes from main to main.local (and the other way around): I'm merging another upstream branch (CVS/tailor) to main, which I want to have in main.local, too. But new features/fixes come through main.local (or another branch from main - "production"). | 20:32 |
| NfNitLoop | so, just continually merge in changes (non-cherrypick) from main.local into your bugfix branches. | 20:33 |
| NfNitLoop | I think I'm losing track of your original issue. *reads scrollback* | 20:34 |
| blueyed | NfNitLoop: sorry for causing confusion.. the problem appears to be when I merge from main to main.local or from main.local to main.. then the (cherrypicked) difference gets applied again. | 20:35 |
| NfNitLoop | don't cherrypick differences. | 20:36 |
| NfNitLoop | just merge them. | 20:36 |
| NfNitLoop | if you cherrypick, bzr cant' track it. | 20:36 |
| blueyed | Sure. But I need to cherrypick the differences (once).. but then when merging, they get applied again, I "bzr revert" them, but they keep on coming in.. | 20:37 |
| NfNitLoop | why do you need to cherrypick the differences? | 20:37 |
| NfNitLoop | if you branch from main->main.local | 20:37 |
| blueyed | Because when I do "bzr merge main.local" in "main" the first time, I get the local changes.. | 20:37 |
| NfNitLoop | that's... what that command is supposed to do. | 20:38 |
| blueyed | So I "null merge" them, as jam called it.. | 20:38 |
| blueyed | yes. | 20:38 |
| blueyed | But I don't want to revert the changes between those branches every time I merge them.. | 20:39 |
| NfNitLoop | it doesn't... | 20:39 |
| NfNitLoop | or shouldn't. | 20:39 |
| NfNitLoop | I still don't see any reason to cherrypick in your workflow. | 20:40 |
| NfNitLoop | I think we may have a communication issue. can you run some commands and paste them to a pastebin to show the behavior you're describing? | 20:40 |
| blueyed | NfNitLoop: that's what jam recommended, but essentially "bzr revert [particular files]" is a synonym for (reverse) cherrypicking here, isn't it? | 20:40 |
| blueyed | NfNitLoop: sure. | 20:41 |
| NfNitLoop | blueyed: aaah. Yes, if you did 'bzr revert .' and then 'bzr commit', then you have told that branch to merge in the changes, *and then* reverse them. and commited that to history. | 20:41 |
| NfNitLoop | so you'll never be able to merge them in. | 20:42 |
| NfNitLoop | because it thinks they already are. (and then have been changed back.) | 20:42 |
| blueyed | NfNitLoop: so, am I doing something wrong? Maybe I need to add another intermediate branch? | 20:44 |
| NfNitLoop | blueyed: yeah, I dont' think you need to 'bzr revert .', unless there were more details about that case that I mentioned. | 20:45 |
| NfNitLoop | so, let's see what your use cases are. | 20:46 |
| NfNitLoop | 'main' mirrros some remote repo? ] | 20:46 |
| blueyed | NfNitLoop: well, I need to do "bzr revert [files that shouldn't have get merged]".. | 20:46 |
| NfNitLoop | blueyed: that's not quite what that does. | 20:46 |
| blueyed | NfNitLoop: main is bzr+ssh://blueyed@bazaar.launchpad.net/%7Eblueyed/b2evolution/dev/ | 20:46 |
| NfNitLoop | it should more read as 'bzr revert [file-changes taht should never get merged]' | 20:47 |
| blueyed | NfNitLoop: yes. | 20:47 |
| NfNitLoop | but if they should never get merged... how are you going to merge them in in the future? why not just remove them from main.local? | 20:48 |
| blueyed | NfNitLoop: well, they are in main.local, because they are changes like "$debug = 1" and other changes useful/needed for local development. | 20:49 |
| blueyed | ..and therefore I want to have them in my feature branches, too. | 20:49 |
| NfNitLoop | yeah... I'm not sure you want to check those in to any branch... | 20:49 |
| NfNitLoop | it really complicates your branching/merging scheme. | 20:50 |
| NfNitLoop | IMO, only check in production code. have other files or settings files to enable debugging. | 20:50 |
| NfNitLoop | (Others?) | 20:50 |
| blueyed | well, in the case of creating a new feature branch, it makes it easier (to have those changes there already) | 20:50 |
| mwhudson_ | hello | 20:52 |
| NfNitLoop | blueyed: but any time you try to modify code that you've rejected from your main branch, the merge is going to barf. (I think.) | 20:53 |
| NfNitLoop | I'm speculating here, since I haven't tried this workflow. | 20:53 |
| NfNitLoop | likewise, if you ever try to merge main->main.local, it'll try to delete your debug statements. | 20:55 |
| blueyed | NfNitLoop: well, I'm not modifying those changes to main.local (in main or any other branch).. the problem is just that the changes come back "as-is". | 20:55 |
| blueyed | NfNitLoop: exactly. | 20:55 |
| NfNitLoop | right. so, I would recommend against that workflow. :p | 20:56 |
| blueyed | :D oook.. ;) | 20:56 |
| NfNitLoop | you've read the bzr workflows page? | 20:56 |
| NfNitLoop | You may find one there that works for you. | 20:56 |
| NfNitLoop | Hmm... there's another one.... | 20:57 |
| blueyed | I've read it once, yes, but it seems to be more generic than this. | 20:57 |
| NfNitLoop | what's the workflow that lets you table changes? | 20:57 |
| NfNitLoop | is that loom, or another one? | 20:57 |
| blueyed | I'll look at loom or something similar.. | 20:57 |
| blueyed | yes, with threads. | 20:57 |
| blueyed | Read about it the other day, but it sounded quite complicated (was related to keeping the patch size limit for bzr patches) | 20:58 |
| === enobre1 is now known as enobrev | ||
| NfNitLoop | right. so in your .local branch you could shelve those changes, merge from main, then re-import your dev changes. | 20:59 |
| NfNitLoop | that way the bits without your .local changes merge cleanly. | 20:59 |
| NfNitLoop | http://bazaar-vcs.org/BzrShelveExample?highlight=(shelve) | 20:59 |
| blueyed | well, shelve is something different (which I've used already) | 21:00 |
| NfNitLoop | Hrmm, actually, committing them to a loom/thread might be easier than hand-picking them each time. | 21:00 |
| NfNitLoop | yeah. | 21:00 |
| blueyed | It's not about conflicts in merges after all. | 21:00 |
| NfNitLoop | Hmm. | 21:03 |
| NfNitLoop | you could have main (remote), dev (new features) and debug(debug statements) | 21:03 |
| NfNitLoop | merge from main->dev | 21:04 |
| NfNitLoop | imlpement new feature. | 21:04 |
| NfNitLoop | commit. | 21:04 |
| NfNitLoop | merge that into dev | 21:04 |
| NfNitLoop | er, into debug. | 21:04 |
| NfNitLoop | test it in debug. | 21:04 |
| NfNitLoop | if it works, push dev -> main | 21:04 |
| NfNitLoop | and your debug statements never enter the rest of the branches. | 21:04 |
| NfNitLoop | which I guess is sortof what loom would offer in a single branch. | 21:06 |
| blueyed | well, I'd like to have "debug" in "dev" during development, of course. | 21:06 |
| blueyed | I'll look into loom etc some more later, thanks for your help and feedback. | 21:07 |
| === mwhudson_ is now known as mwhudson | ||
| lifeless | ñmoin | 21:58 |
| lifeless | abentley: hi | 21:58 |
| abentley | lifeless: we have inconsistencies between VersionedFiles.get_parents_map and PlanMergeVersionedFile.get_parents_map, when it comes to parentless revisions. Sometimes you get (), sometimes you get NULL_REVISION. | 22:02 |
| lifeless | sorry! | 22:02 |
| abentley | I'd like to unify them. | 22:02 |
| abentley | Interestingly, at least some of the old calling code was expecting (). | 22:03 |
| lifeless | heh. so the NULL_REVISION emitter was for code expecting the behaviour of a Graph created from a Repository which we needed to reused | 22:03 |
| lifeless | we could push NULL_REVISION down to VersionedFiles | 22:03 |
| abentley | lifeless: That's my favourite option, and I think John expects that. | 22:04 |
| lifeless | +1 from me | 22:05 |
| abentley | So to be clear, the ancestor of ('file-id', 'one') would be ('null:',) | 22:06 |
| lifeless | using NULL_REVISION rather than a tuple is a little strange, but it works with all key-lengths, and with all the current graph code, which is why I did it back last year for pack repos | 22:06 |
| lifeless | I'm happy for you to use NULL_REVISION or (NULL_REVISION,) - whichever you like | 22:07 |
| lifeless | if you go for the latter, can I suggest a symbolic constant of NULL_KEY | 22:07 |
| abentley | NULL_REVISION isn't an aribtrary constant, though. It's just a paranoid way of writing the revision-id "null:". | 22:08 |
| lifeless | yes | 22:08 |
| abentley | So I prefer a tuple-- and NULL_KEY WFM. | 22:08 |
| lifeless | jam: good catch on the bloom use | 22:13 |
| === bigdo2 is now known as bigdog | ||
| jam | lifeless: howdy | 22:52 |
| jam | lots of changes for you to pull :) | 22:52 |
| jam | lifeless: so... I outlined it in an email, but I think the next best way to improve performance is a dynamic bloom | 22:53 |
| jam | I think we can shrink a bloom with no loss | 22:53 |
| === mw|food is now known as mw | ||
| jam | and we can expand with minimal loss, as long as the bloom isn't already full | 22:53 |
| jam | (well, it has to be rather empty, but that can be controlled) | 22:53 |
| jam | that would let us grow the bloom as we need to, without always allocating a 10MB bloom and then shrinking it | 22:53 |
| jam | lifeless: and cache thrashing is 100% why iter_random_all performance sucks | 22:55 |
| jam | If you make the node cache bigger, or start caching the individual lines, performance goes from 100s => 8 => 4s | 22:55 |
| jam | versus Graph at 6s | 22:55 |
| lifeless | jam: I think its worth investigating a root bloom vs leaf-1 bloom | 22:59 |
| lifeless | I knew about the cache thrashing btw - it was in an early email :) | 23:00 |
| jam | lifeless: sure, I just have hard numbers to show for it :) | 23:00 |
| lifeless | jam: so did I :) (I tested 100 and 1000 page caches at the time) :> | 23:00 |
| lifeless | jam: so, I'm going to commit my tweaks and merge | 23:01 |
| lifeless | jam: we save nontrivally by only looking at the bloom adjacent to the leaf | 23:02 |
| jam | aka the last one? | 23:02 |
| lifeless | 2seconds out of 46 | 23:02 |
| lifeless | yeah, only probing once | 23:02 |
| jam | lifeless: what benchmark? | 23:02 |
| lifeless | random, ccompononents and miss | 23:03 |
| jam | well, multiway is going to conflict with your changes | 23:03 |
| jam | and brings in 20 => 10s for miss | 23:03 |
| jam | and about the same for ccomponents | 23:04 |
| lifeless | cool | 23:04 |
| lifeless | does multiway bloom as well? | 23:04 |
| jam | lifeless: yes | 23:04 |
| jam | miss_torture 25.094 => 10.96 | 23:04 |
| jam | get_cc 28.4 => 14.5 | 23:04 |
| jam | search 2.5 => 1.2 | 23:04 |
| jam | though this is my code and not yours, so I might have down-performed some stuff | 23:05 |
| jam | Also, my repository recently reset itself, going from 18+ packs to 12 | 23:05 |
| lifeless | :P | 23:05 |
| jam | I must have rolled a digit | 23:05 |
| lifeless | I don't commit in the same repo | 23:05 |
| jam | but I was careful to test these on the same repo | 23:05 |
| jam | lifeless: yeah, I just rsync'd mine out of the way | 23:05 |
| lifeless | wheee | 23:08 |
| jam | ? | 23:08 |
| lifeless | yes iter_entries does 'conflict' | 23:08 |
| jam | It wouldn't be hard to bring in your "only check the last row bloom" | 23:08 |
| jam | though I also pre-compute all of the key => offset mappings | 23:08 |
| jam | so I'm not sure if you would see the same savings | 23:08 |
| jam | Your original code had to do N sha1sums at each row | 23:09 |
| lifeless | is get_raw_offsets in the pybloom code? | 23:09 |
| lifeless | or do I need to pull ? | 23:09 |
| jam | lifeless: no it is in NodeBloom | 23:09 |
| lifeless | cool | 23:09 |
| jam | I haven't committed stuff to pybloom yet | 23:09 |
| jam | Though if I did work on dynamic blooms, I would probably do it there first | 23:10 |
| jam | abentley: ping | 23:10 |
| lifeless | jam: Oh, I've replied to your analysis with some thoughts | 23:11 |
| jam | lifeless: and I think I replied to your reply :) | 23:11 |
| jam | I think bringing the leaf key cache up a level could be interesting | 23:11 |
| jam | probably significantly more beneficial overall | 23:12 |
| jam | plus, sharing a cache means less waste, etc. | 23:12 |
| lifeless | jam: aah cool | 23:13 |
| lifeless | jam: oh, you look for a branch now ? | 23:18 |
| jam | lifeless: yeah, so I can get a proper ancestry to search | 23:19 |
| jam | I kept getting nodes on a trivial plugin | 23:19 |
| jam | and then search would be like 0.1s | 23:19 |
| lifeless | :P | 23:19 |
| jam | I changed the search as well | 23:19 |
| jam | mostly because it was easier to assert correctness with | 23:19 |
| jam | iter_ancestry( | 23:19 |
| jam | though having to change from tuple keys => revision_ids sucked | 23:20 |
| jam | especially because of the NULL_REVISION hackery in bzrlib | 23:20 |
| lifeless | there is an adapter in bzrli | 23:20 |
| lifeless | but yes | 23:21 |
| lifeless | jam: I see iter_random_one at 113 seconds still ? | 23:24 |
| lifeless | jam: is there some option I need to tweak? | 23:24 |
| jam | lifeless: you need to enable the line cache | 23:24 |
| jam | or increase the node cache | 23:25 |
| jam | lifeless: line 391 in btree_index: | 23:25 |
| jam | self._leaf_value_cache = None # lru_cache.LRUCache(100*1000) | 23:25 |
| pickscrape | Is there any way to tell bzr init to ignore any shared repository it finds? | 23:25 |
| pickscrape | Or would issuing bzr init-repo first have the desired effect? | 23:26 |
| jam | pickscrape: not ATM, though you can 'bzr init-repo' in the inbetween | 23:26 |
| pickscrape | jam: thanks :) | 23:26 |
| jam | lifeless: I disable the line cache for testing other things, to see how much it helps/hurts, If you want to move the key cache into the combined index, I would recommend that :) | 23:27 |
| jam | lifeless: I just saw this: self._page_size = transport.recommended_page_size() is that "future work" showing its head? | 23:30 |
| lifeless | jam: yes | 23:33 |
| jam | I was a bit curious how you would handle page_size % _PAGE_SIZE != 0 | 23:33 |
| lifeless | jam: my very initial concept for write once index segments had a fixed size page with network hint | 23:33 |
| lifeless | jam: round :) | 23:33 |
| jam | lifeless: so the idea would be that if you push to remote, it would auto bloat the page size | 23:34 |
| jam | well, auto increase at least :) | 23:34 |
| jam | bloat is probably a bad term | 23:34 |
| jam | abentley: If you get a chance, I'd like to chat quickly on how to pass parameters between the merge objects | 23:36 |
| abentley | jam: sorry, on a call | 23:38 |
| jam | np | 23:39 |
| lifeless | jam: well two things | 23:43 |
| lifeless | jam: you could read additional internal nodes optimistically | 23:43 |
| lifeless | jam: and you could make a bigger page size if you think it makes sense | 23:43 |
| jam | lifeless: yeah, I think the former is likely to be very good, I'm not sure if the latter gets you much | 23:44 |
| jam | especially if your transport supports arbitrary reads | 23:44 |
| jam | we really just want to cap the minimum size | 23:44 |
| jam | rather than bloat every request | 23:45 |
| jam | well, that is my thought at least | 23:45 |
| jam | if I am already reading 64k across 16 disjoint pages, that seems fine | 23:45 |
| lifeless | jam: if there is not much cost to do that; of course FTP has a huge cost ;P | 23:46 |
| jam | lifeless: right, this is more for HTTP & bzr+ssh | 23:46 |
| lifeless | but I'm not worried about FTP per se; but even http and sftp have some trouble with arbitrary readvs | 23:46 |
| jam | and *maybe* sftp with pipelining | 23:46 |
| jam | http does pretty good for most servers | 23:46 |
| jam | except squid proxies :) | 23:46 |
| jam | and the ones that don't support it at all (like BaseHTTP) | 23:47 |
| abentley | jam: pong | 23:55 |
| jam | abentley: so the first problem I'm facing... Merger is the class that find the unique_lca base, and detects a criss-cross, but Merge3Merger is the one that deals with paths, etc. | 23:56 |
| jam | Do I just need to add a "supports_XXXX" member and then pass it in the __init__ like we do now? | 23:57 |
| abentley | Not clear what we'd be passing. The multiple LCAs in a criss-cross? | 23:57 |
| abentley | Don't we want that on a per-file basis? | 23:58 |
| jam | abentley: for the whole-tree-paths logic, I use the whole tree LCAs | 23:59 |
| jam | but at a minimum, I want to pass the criss-cross flag | 23:59 |
| jam | my merge3 code just passes it unconditionally, but certainly that isn't "compatible" | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!