| furicle | lifeless: I'm just doing bzr -r1 | 00:03 |
|---|---|---|
| furicle | lifeless: pardon - bzr diff -r 1 | 00:03 |
| lifeless | furicle: ok, as a workaround you can use filterdiff -x '*.pdf' or something like that, to remove the pdfs in your diff | 00:14 |
| lifeless | please file a bug, this is something we can clearly do better on | 00:14 |
| lifeless | Jc2k: avg 0.00275434756196 | 00:14 |
| lifeless | avg 0.0118949759048 | 00:14 |
| Jc2k | lifeless: did gc just kick some arse or do i need an eye test.. | 00:16 |
| lifeless | arse kicking | 00:16 |
| lifeless | as usual the story is more complex | 00:17 |
| Jc2k | ah boo :[ | 00:17 |
| lifeless | let me paste results | 00:17 |
| lifeless | http://paste.ubuntu.com/113016/ | 00:17 |
| furicle | lifeless: thanks for the info - I can pipe it out to vim and hack it back out, just wondered if I was doing something wrong. Thanks for the info | 00:18 |
| lifeless | furicle: are you going to file a bug? If not, I will - but I don't have the test data to reproduce if its not obvious | 00:19 |
| lifeless | Jc2k: in particular look at the max time | 00:20 |
| lifeless | 0.17 is because we read one big zlib hunk | 00:20 |
| lifeless | but after that the entire inventory for all of the repo is in one compressed record | 00:20 |
| Jc2k | so your saying the zlib reads are gonna kill us anyway? | 00:23 |
| lifeless | I'm saying its going to depend a lot | 00:23 |
| lifeless | >< | 00:23 |
| lifeless | like | 00:23 |
| lifeless | annotate will kick arse | 00:23 |
| lifeless | but 'read the most recent commit message only' will be slow | 00:24 |
| lifeless | read all commits will be fast | 00:24 |
| lifeless | etc | 00:24 |
| lifeless | we can trade time and space here | 00:25 |
| lifeless | if we cap the groups smaller | 00:25 |
| lifeless | then the zlib read will be less | 00:25 |
| lifeless | but we'll have more groups | 00:25 |
| lifeless | its not beyond hope | 00:27 |
| lifeless | we can still look at short reads and decompresses for random access | 00:27 |
| lifeless | we could keep recent texts at the front of groups | 00:27 |
| Jc2k | so in comparison to git: git looking at the most recent commit can generally look at the first object in the pack (or near) and it will generally be a full text rather than a delta so it will be (seek a few bytes in) (hot zlib action) done. | 00:28 |
| lifeless | yah | 00:28 |
| Jc2k | what does gc have to do? | 00:28 |
| * Jc2k missed your intro to gc as rob led you away at guadec :( | 00:29 | |
| lifeless | can I say it depends and wave my hands a lot ? | 00:29 |
| Jc2k | sure :D | 00:29 |
| lifeless | it depends, wave wave wave | 00:29 |
| lifeless | ok | 00:29 |
| lifeless | have you read the README in bzr-groupcompress? | 00:30 |
| Jc2k | nope, *scurries off to look* | 00:30 |
| lifeless | when you've read that you will understand the tuning I'm talking about I hope | 00:31 |
| lifeless | though I can and will enlarge from there | 00:31 |
| Jc2k | GPL GPL GPL GPL, lets make things smaller. read DESIGN. k thx end. :p | 00:32 |
| lifeless | oh yeah DESIGN. | 00:32 |
| lifeless | me | 00:32 |
| lifeless | h | 00:32 |
| lifeless | I knew which document I meant | 00:32 |
| lifeless | pet peeve, -d isn't global | 00:34 |
| Jc2k | ok. generic process parsed. | 00:36 |
| lifeless | wow, think I found a knit bug >< | 00:36 |
| lifeless | so | 00:36 |
| lifeless | two layers | 00:36 |
| lifeless | stream-of-build-recipes | 00:36 |
| lifeless | efficient *fast* compressor on top | 00:37 |
| lifeless | the build recipe stream should be 80% of the compress, or something like that | 00:37 |
| lifeless | cost to get a single text out is clearly: | 00:38 |
| lifeless | cost to decomopress outer enveloper up to the end of the text build recipe + cost to parse and execute the build recipe | 00:39 |
| lifeless | best case cost would be no outer envelope and the first text in the stream | 00:39 |
| lifeless | because we could just read that text and ignore the rest | 00:40 |
| furicle | lifeless: I will file a bug. | 00:40 |
| lifeless | furicle: thanks | 00:41 |
| lifeless | Jc2k: did you catch my cheating ? | 00:41 |
| Jc2k | lifeless: so.. to clarify "no outer envelope", no envelope compression at all? no zlib of the recipes? | 00:44 |
| lifeless | right | 00:44 |
| lifeless | we can get rid of the decomp cost | 00:44 |
| Jc2k | in which case, you just read a full text and there is no decompression or assembly to do at all | 00:44 |
| Jc2k | so its uber fast | 00:44 |
| lifeless | just read as much of the stream as needed | 00:44 |
| lifeless | but larger | 00:45 |
| lifeless | say 100% larger | 00:45 |
| lifeless | which of course for network IO isn't such a great thing | 00:45 |
| lifeless | but its an option | 00:46 |
| Jc2k | but we can fix that with smart reads, right? | 00:46 |
| lifeless | depends on the use case | 00:46 |
| lifeless | like, smart server, the server could zlib on the fly | 00:46 |
| lifeless | sftp, you will be reading whats on disk directly | 00:46 |
| Jc2k | but group compress + smart server could use delta bases that it knows are on the client for example | 00:46 |
| lifeless | ah | 00:46 |
| lifeless | look closely at a recipe | 00:47 |
| lifeless | its not a delta as suc | 00:47 |
| lifeless | this is a recipe: | 00:47 |
| lifeless | ['label: label\n', | 00:47 |
| lifeless | 'sha1: xxxxxxxxxxxxxxxxxx\n' | 00:48 |
| lifeless | 'i,3\n' | 00:48 |
| lifeless | 'strange\n', | 00:48 |
| lifeless | 'common\n', | 00:48 |
| lifeless | '\n', | 00:48 |
| lifeless | ] | 00:48 |
| lifeless | that recipe will create the text ['strange\n', 'common\n'] | 00:48 |
| lifeless | this recipe: | 00:48 |
| lifeless | 'label: newlabel\n', | 00:48 |
| lifeless | 'sha1: xxxxxxxxxxxxxxxxxxxxxxxxxxxx\n' | 00:49 |
| lifeless | 'c,72,7\n', | 00:49 |
| lifeless | 'i,1\n', | 00:49 |
| lifeless | 'different\n', | 00:49 |
| lifeless | 'i,1\n', | 00:49 |
| lifeless | '\n' | 00:49 |
| lifeless | ] | 00:49 |
| lifeless | copies 7 bytes from byte 72 into its output | 00:49 |
| Jc2k | so recipes allow you to select ranges from the base text and insert next text? | 00:50 |
| lifeless | from the stream so far | 00:51 |
| Jc2k | ah | 00:51 |
| Jc2k | where as git patch opcodes only let you reference the base text | 00:51 |
| lifeless | this is why it compresses so well without threaded computation of best-parent | 00:52 |
| lifeless | because it uses every single text compressed so far as a parent | 00:52 |
| Jc2k | gotcha | 00:52 |
| lifeless | so the least cpu work to get the first text out is no zlib wrapper, and read in only the bytes for the first text | 00:53 |
| lifeless | least average work is probably zlib, because less IO does matter | 00:54 |
| lifeless | theres a typical U graph trading off space and time in different scenarios ere | 00:54 |
| lifeless | now, the current decompression code, for the first text, reads the entire zlib envelope, decompresses the entire thing, puts that in a lru cache, then grabs the recipe it needed and generates the output | 00:55 |
| lifeless | changing this to read less is complex in two ways: how much of the zlib record has to be read to decompress the recipe for the first text, and how much will eventually be wanted | 00:56 |
| lifeless | the greedier we are, the more upfront work, but the less round trips | 00:56 |
| spats | hey all. I'm having trouble merging a task branch back to trunk; bzr is telling me there are no changes to commit after I do the merge, despite showing me a +N line during the merge. What am I missing? See http://pastebin.com/d646d281 | 00:58 |
| lifeless | spats: its because you are trying at revision 0 | 00:59 |
| lifeless | spats: do your test case again, but after initing 'main', do a commit | 00:59 |
| lifeless | even a commit with no content | 00:59 |
| spats | aha! okay, thanks :) | 00:59 |
| lifeless | revision 0 can't be merged with things, its a blackhole to bootstrap from :) | 01:00 |
| lifeless | so your merge is in effect a pull | 01:00 |
| lifeless | its a little wart, but one most folk can't ever encounter :P | 01:00 |
| spats | lifeless: I was trying to follow the "never check in to the mainline" theory a bit too literally - make a branch for initial code checkin. I might just add an empty checkin to the process. | 01:01 |
| === mlh_ is now known as mlh | ||
| Jc2k | lifeless: tough problem :) | 01:06 |
| lifeless | Jc2k: does git do delta combining? | 01:07 |
| lifeless | Jc2k: that is, to recreate something at the end of a chain of 200 texts | 01:07 |
| lifeless | does it get(base); patch(base->2); patch(2->3);; etc | 01:07 |
| lifeless | or does it get(base), combine_patches(2,3,4,5,...); patch(base->200) | 01:08 |
| Jc2k | it can chain, and there is a limit on the length of chains | 01:08 |
| Jc2k | its the 1st | 01:08 |
| lifeless | ok | 01:08 |
| Jc2k | base + patch = object 2, object 2 + patch = object 3 | 01:08 |
| Jc2k | and the limit is much lower than 200 from what i recall | 01:09 |
| lifeless | folk on forums say --200 --200 | 01:09 |
| lifeless | and benchmarkers are using that | 01:09 |
| lifeless | default is 50 | 01:09 |
| Jc2k | i think it was just 10 in the beginning | 01:12 |
| lifeless | anyhow | 01:15 |
| lifeless | so to be faster than git | 01:15 |
| lifeless | we have to be faster at some key operations | 01:16 |
| lifeless | and also faster in things like fetch that inspect every object | 01:16 |
| lifeless | I think gc is there now, modulo optimising | 01:16 |
| lifeless | but the recent-history case still concerns me | 01:16 |
| lifeless | I think that that perhaps some hinting to the engine | 01:17 |
| Jc2k | can we be a bit bigger and faster locally, and smaller and a bit slower when doing stuff remote? | 01:17 |
| lifeless | 'I only want one thing, kthanks' | 01:17 |
| lifeless | yes, thats possible assuming decompress and recompress during push | 01:17 |
| lifeless | we could even just change the zlib layer for that | 01:17 |
| === timchen119 is now known as nasloc__ | ||
| lifeless | ok | 01:31 |
| lifeless | so a rough figure | 01:31 |
| lifeless | first 1000 revs of bzr | 01:31 |
| lifeless | knits->knits 5 seconds | 01:31 |
| lifeless | gc->gc 19 seconds | 01:31 |
| lifeless | note that we have much better integrity checking in the latter case, so its not quite apples-apples | 01:31 |
| lifeless | and the gc repo is 50% of the size | 01:32 |
| lifeless | $ du -sh gc/.bzr | 01:32 |
| lifeless | 1.3M gc/.bzr | 01:32 |
| lifeless | $ du -sh plain/.bzr | 01:32 |
| lifeless | 2.4M plain/.bzr | 01:32 |
| === asac_ is now known as asac | ||
| lifeless | slightly faster at some ops too: | 01:33 |
| lifeless | $ time bzr log -v plain/t > /dev/null | 01:34 |
| lifeless | real 0m11.920s | 01:34 |
| lifeless | $ time bzr log -v gc/t > /dev/null | 01:34 |
| lifeless | real 0m10.775s | 01:34 |
| lifeless | tree building too | 01:36 |
| lifeless | gc/t$ bzr remove-tree && bzr checkout . && bzr remove-tree && time bzr checkout . | 01:36 |
| lifeless | 01:36 | |
| lifeless | real 0m0.914s | 01:36 |
| lifeless | plain/t$ bzr remove-tree && bzr checkout . && bzr remove-tree && time bzr checkout . | 01:36 |
| lifeless | 01:36 | |
| lifeless | real 0m1.069s | 01:36 |
| Jc2k | sleep time for me (its 1.30 already!) | 01:40 |
| Jc2k | good luck lifeless | 01:40 |
| lifeless | gnight! | 01:40 |
| lifeless | >< thumper - bzr push bzr+ssh://bazaar.launchpad.net/~lifeless/bzr/fix-chunked | 01:45 |
| lifeless | ... | 01:45 |
| lifeless | bzr: ERROR: exceptions.KeyError: 'pqm@pqm.ubuntu.com-20090131231933-8o4phfvmuuizyyn6' | 01:46 |
| lifeless | Traceback (most recent call last): | 01:46 |
| thumper | lifeless: hi | 01:47 |
| mwhudson | lifeless: is the branch packs5/branch6? | 01:49 |
| lifeless | mwhudson: think so | 01:49 |
| thumper | was probably initially pushed when that combo made a broken branch | 01:50 |
| lifeless | $ bzr push bzr+ssh://bazaar.launchpad.net/~lifeless/bzr/fix-chunked | 01:50 |
| lifeless | Using default stacking branch /~bzr/bzr/trunk at bzr+ssh://bazaar.launchpad.net/%7Elifeless/bzr/ | 01:50 |
| lifeless | Source format does not support stacking, using format: '1.6' | 01:50 |
| lifeless | Packs 5 (adds stacking support, requires bzr 1.6) | 01:50 |
| lifeless | thumper: new branch today | 01:50 |
| thumper | arse | 01:50 |
| lifeless | igc: new groupcompress pushed, FYI | 01:51 |
| lifeless | spiv: ^ | 01:51 |
| mwhudson | lifeless: i suppose you're not using bzr 1.9 still are you? :p | 01:51 |
| spiv | lifeless: shiny | 01:51 |
| lifeless | mwhudson: bzr.dev | 01:51 |
| furicle | lifeless: For the record - bug#320783 - already existed - I just added my two cents - might be any pdf file | 01:51 |
| lifeless | furicle: thanks! | 01:51 |
| lifeless | I'm going to get gc able to pull all of bzr.dev | 01:52 |
| thumper | lifeless: it seems that the branch has repo format 1.9 and branch format 1.6 | 01:52 |
| lifeless | urgh | 01:53 |
| lifeless | so it stacked, but didn't upgrade the branch format on the fly | 01:53 |
| mwhudson | and is not stacked | 01:53 |
| lifeless | oh | 01:53 |
| lifeless | it is a stackable format branch | 01:53 |
| lifeless | just not stacked | 01:53 |
| thumper | http://bazaar.launchpad.net/~lifeless/bzr/fix-chunked/.bzr/repository/format | 01:53 |
| thumper | says 1.9 | 01:53 |
| lifeless | thumper: it should be 1.9, I've upgraded | 01:53 |
| mwhudson | branch.conf is empty | 01:54 |
| thumper | http://bazaar.launchpad.net/~lifeless/bzr/fix-chunked/.bzr/branch/format | 01:54 |
| lifeless | but the branch I pushed from is branch6 or so | 01:54 |
| thumper | says Branch Format 7 | 01:54 |
| lifeless | Bazaar Branch Format 6 (bzr 0.15) | 01:54 |
| lifeless | right | 01:54 |
| lifeless | thats the autoupgrade stuff kicking in to support stacking | 01:54 |
| thumper | k | 01:54 |
| thumper | mwhudson: where is the stacked branch kept? | 01:55 |
| mwhudson | so it converts the formatting appropriately, but doesn't actually set the stacking | 01:55 |
| lifeless | which is a bit odd for folk that don't want their project to suddenly grow a dependency on latest bzr; or is it per-project enabled in lp ? | 01:55 |
| mwhudson | thumper: .bzr/branch/branch.conf | 01:55 |
| mwhudson | lifeless: i'm pretty sure the auto-upgrading only happens when you have a mixed format like a new repo but old branch | 01:57 |
| lifeless | mwhudson: ok, anyhow lets not get distracted | 01:58 |
| mwhudson | yeah | 01:58 |
| lifeless | theory is the autoupgrade half-worked | 01:58 |
| mwhudson | well i'm already distracted :) | 02:00 |
| mwhudson | but yes | 02:00 |
| mwhudson | there should be tests for this stuff, maybe they only check the formats, not that the new branch is stacked? | 02:00 |
| lifeless | none in blackbox.test_push | 02:00 |
| mwhudson | nor branch_implementations.test_stacking it seems | 02:01 |
| mwhudson | spiv: hey you, you fixed this bug | 02:01 |
| lifeless | def test_push_doesnt_create_broken_branch | 02:01 |
| lifeless | is close | 02:01 |
| mwhudson | that sounds like something i wrote :) | 02:02 |
| mwhudson | hm, maybe not | 02:02 |
| mwhudson | test_push_with_default_stacking_does_not_create_broken_branch | 02:03 |
| mwhudson | in branch_implementations.test_push | 02:03 |
| lifeless | spiv: want to hear a fun bug | 02:04 |
| spiv | lifeless: sure | 02:08 |
| spiv | lifeless: so long as I don't have to fix it ;) | 02:08 |
| lifeless | you know how we check file content graph <-> revision graph correspondence | 02:09 |
| lifeless | we greate graphs like that with '' as the content, for directories. | 02:09 |
| lifeless | guess what 'bzr check' and 'bzr reconcile' do not check | 02:09 |
| spiv | They don't check directories? | 02:10 |
| lifeless | RevisionNotPresent: Revision {('selftest-20050621060616-bb8b5b36e3c950c8', 'robertc@robertcollins.net-20050919060519-f582f62146b0b458')} not present in "<bzrlib.plugins.groupcompress.groupcompress.GroupCompressVersionedFiles object at 0x276e390>". | 02:10 |
| lifeless | the source repo checks cleanly | 02:10 |
| lifeless | thats the directory 'bzrlib/tests' | 02:11 |
| lifeless | its being triggered by inserting a child of that | 02:11 |
| spiv | Oops. | 02:11 |
| lifeless | so, I think the child's parent pointer is wrong :P | 02:11 |
| spiv | Yeah, using a directory's "file content" as a parent for anything does seem rather weird. | 02:13 |
| igc | lifeless: new groupcompress in brisbane-core or it's own branch? | 02:15 |
| lifeless | igc: its still seperate | 02:18 |
| lifeless | spiv: well, its another dir | 02:18 |
| lifeless | spiv: this is _very early_ commits | 02:19 |
| lifeless | spiv: so its appropriate, its just not aligned with the graph | 02:19 |
| lifeless | early weave bug I think | 02:19 |
| * igc lunch | 02:19 | |
| lifeless | igc: but mutual dependencies | 02:20 |
| igc | so lifeless, to benchmark your latest groupcompress, I need to grab the latest plugin code | 02:56 |
| lifeless | igc: yes | 02:56 |
| igc | lifeless: and bzr.dev or brisbane-core or doesn't matter? | 02:57 |
| igc | I assume brisbane core is more interesting to you? | 02:57 |
| igc | or not? | 02:57 |
| lifeless | if you are testing bbc node compression, then you need the format in there to use gc | 02:57 |
| lifeless | right now I'm isolating the parameters and performance for the compression layer, which is [mostly] orthogonal to bbc | 02:58 |
| lifeless | igc: have you seen compressbench | 02:59 |
| igc | lifeless: I know of it but I haven't tried it | 03:00 |
| lifeless | well, I'm mainly working with that for micro and then use case tests, for the --gc-plain format, right at the moment | 03:01 |
| lifeless | still trying to rule-out-or-in | 03:01 |
| igc | sure | 03:01 |
| lifeless | uhm, if you want to put the gc-plain format through usertest, that would be nice | 03:02 |
| igc | lifeless: shall do. I have chemo Wed & Fri this week so something mindless like running benchmarks will fit in well :-) | 03:04 |
| lifeless | :) | 03:05 |
| lifeless | look, its legal drugs, can't complain | 03:05 |
| igc | :-) | 03:06 |
| spiv | Speaking of which... coffee. | 03:06 |
| * spiv -> afk | 03:07 | |
| lifeless | spiv: and for entertainment value, this bug is in out mainline repo | 03:39 |
| Peng_ | jelmer: ping? | 03:42 |
| sohail | hi | 03:46 |
| sohail | I just did a bzr merge -r<foo>..<bar> /path/to/whatever | 03:46 |
| sohail | well actually, a bunch of them | 03:47 |
| sohail | is there a way to list what is about to be merged? | 03:47 |
| lifeless | bzr missing | 03:47 |
| sohail | lifeless, no I mean what I am about to commit | 03:47 |
| sohail | I thought bzr st -v listed the relevant data but apparently not | 03:47 |
| lifeless | the merged revisions? | 03:48 |
| lifeless | or the file changes? | 03:48 |
| lifeless | oh sorry | 03:48 |
| lifeless | you have cherry picked | 03:48 |
| lifeless | cherry picks are special and do not record the revision | 03:49 |
| sohail | orly? | 03:49 |
| lifeless | they are essentially just a normal diff+patch operation | 03:49 |
| sohail | why? | 03:49 |
| lifeless | because we haven't implemented a non-transitive graph relationship that is scalable in the cases we know people do cherrypicks in | 03:50 |
| lifeless | sorry if that answer went straight off into technobabble :P | 03:50 |
| lifeless | we have plans to get this fixed, but its not at the top of anyones queue as far as I know | 03:50 |
| sohail | so if I do bzr merge /path/to/whatever it will try to merge again? | 03:50 |
| lifeless | yes, but if you are doing that, why were you cherrypicking in the first place :) | 03:51 |
| sohail | well because for now I just want stuff that i know works | 03:51 |
| sohail | and then later the rest of it | 03:51 |
| lifeless | fair enough | 03:51 |
| lifeless | it shouldn't cause many spurious conflicts when it does merge again | 03:52 |
| lifeless | unless you have changed the lines further | 03:52 |
| sohail | oki, thanks | 03:52 |
| lifeless | igc: around? | 03:53 |
| sohail | is it possible to say "ignore these revisions when merging for now"? | 03:54 |
| lifeless | sohail: no, because merging acts on the whole files, and there is no copy of the files you are merging from that is missing those lines *and* has any new lines added [which might supercede those very lines you wanted to eliminate] | 03:55 |
| igc | lifeless: ping | 03:56 |
| lifeless | igc: I was thinking, for usertest | 03:56 |
| sohail | I understood your other babble better than the latest one :-) | 03:56 |
| lifeless | it would be nice to have both time-to-clone-natively and time-to-clone-from-pack-0.92, which is the only one we have today, isn't it ? | 03:56 |
| lifeless | sohail: heh. So when we merge, you could imagine taking a series of patches and applying them. | 03:57 |
| igc | lifeless: it depends ... | 03:57 |
| lifeless | sohail: or, taking the file contents of the source, and the target, and a common version they both shared, then finding what changes have occured at that level | 03:57 |
| igc | the source repo can be whatever format you like | 03:58 |
| sohail | I see.. I think :-) | 03:58 |
| lifeless | sohail: in the former approach you could 'skip a patch', but in the latter approach, you don't know which lines are from a given patch without doing rather more work | 03:58 |
| igc | the test is currently "bzr branch mirror feature-branch" | 03:58 |
| igc | for gc-plain testing right now, .... | 03:59 |
| lifeless | sohail: and even you did, you then need to detect dependencies in later changes on the patch you are skipping | 03:59 |
| igc | I add an extra step though as I assmue that the source isn't in that format | 03:59 |
| lifeless | sohail: 'darcs' does something in this area, and we'd like to too, but it makes most folks minds hurt ;) | 03:59 |
| lifeless | igc: righto; I'm saying both steps are useful data | 04:00 |
| lifeless | igc: 'how slow to get to this format' and 'how slow to clone in the format' | 04:00 |
| sohail | lifeless, well I'd rather just say something like: "When you are merging from this branch, never ever merge revisions a..b" | 04:00 |
| igc | lifeless: understood | 04:00 |
| lifeless | sohail: the way you say that today is: merge up to b (but don't commit yet), then merge -r b..a --force, and then commit | 04:01 |
| sohail | hmm | 04:01 |
| sohail | let me try that | 04:01 |
| lifeless | sohail: that commits a revert of the a..b change in your branch | 04:01 |
| lifeless | if the other branch merges from you, they will have that revert applied to them | 04:02 |
| sohail | oh | 04:02 |
| lifeless | remember that the point of merging is to make two branches content be combined | 04:02 |
| sohail | so that isn't what I want either... | 04:02 |
| lifeless | so given two branches A and B | 04:02 |
| lifeless | in A, merge B+commit | 04:02 |
| lifeless | then in B, merge A + commit | 04:02 |
| lifeless | is defined as giving you the same content | 04:02 |
| sohail | or maybe I can make a third integration branch? | 04:03 |
| lifeless | I don't know what your scenario is sorry :P | 04:04 |
| sohail | that's ok, you've been helpful | 04:05 |
| lifeless | I'm happy to discuss things further if you like | 04:05 |
| sohail | I'm ok if you're ok :-) | 04:05 |
| lifeless | we're all ok then | 04:05 |
| sohail | I have two branches, master & next. master is meant to be stable... The next branch got some stuff checked in that wasn't quite ready | 04:06 |
| sohail | but I need to make the master use the latest good stuff | 04:06 |
| sohail | I want bzr to keep track of it all for me :-) | 04:06 |
| lifeless | fair enough | 04:06 |
| lifeless | I use looms for that | 04:06 |
| lifeless | but you don't need to | 04:06 |
| * sohail is waiting for The Bazaar Book :-) | 04:07 | |
| lifeless | the key thing to know is that I cherrypick when needed, and I have a branch for each conceptual change I'm making | 04:07 |
| sohail | yeah I think that's the thing | 04:07 |
| lifeless | if a branch B depends on branch A | 04:07 |
| sohail | next time I gotta make a branch for each change | 04:07 |
| lifeless | I merge A into B | 04:07 |
| lifeless | now, if A has bad stuff in it, but the conceptual change in B could be merged to trunk anyway | 04:07 |
| lifeless | what I do is a cherrypick | 04:07 |
| lifeless | -r branch:A..branch:B | 04:08 |
| sohail | what does that mean.. | 04:09 |
| sohail | -r branch:A..branch:B | 04:09 |
| lifeless | well | 04:09 |
| sohail | difference between those two branches? | 04:09 |
| lifeless | like -r x..y | 04:09 |
| lifeless | except that x is the tip of branch A | 04:09 |
| lifeless | and y is the tip of branch B | 04:09 |
| lifeless | so yeah, the difference between the branches | 04:09 |
| sohail | but how does that apply here? | 04:10 |
| lifeless | it cherry picks the unique work in B without the stuff in A I was unhappy with | 04:11 |
| lifeless | it may not apply to you, I was just sharing how I use bzr to track things for me | 04:11 |
| sohail | oh I see | 04:11 |
| sohail | this works if you have a branch per conceptual change | 04:11 |
| lifeless | yes | 04:12 |
| sohail | so do you have any suggestion for my situation? | 04:13 |
| lifeless | you have two branches, master and next, next has some good stuff, and after it some bad stuff, and then some more good stuff? | 04:13 |
| lifeless | and you want all the good stuff in master? | 04:14 |
| sohail | yep | 04:14 |
| sohail | and I want bzr to track this | 04:14 |
| lifeless | ok, firstly I'd merge all the good stuff to master that is before anything bad | 04:14 |
| lifeless | bzr merge -r last_good_before_bad; commit | 04:14 |
| lifeless | then, I'd : bzr merge next; bzr merge -r last_bad..first_bad --force next; bzr commit -m "Pull in all ready code from next"; | 04:15 |
| lifeless | I would then go immediately to next and | 04:15 |
| lifeless | bzr merge master; "bzr merge -r first_bad..last_bad ."; bzr commit -m "Master excluded $topic_that_is_bad but merged everything else." | 04:16 |
| lifeless | which will merge back from master but keep the bad content (by reinstating it during the merge) | 04:16 |
| lifeless | at this point, master has all the good stuff; next has everything including bad; the next merge from next to master will carry over the bad stuff | 04:17 |
| lifeless | I would then rename 'next' to 'bad-feature' | 04:17 |
| lifeless | and make a new next :) | 04:17 |
| lifeless | spiv: any idea how to get pdb to handle BZR_PDB=1 when inside a generator? | 04:19 |
| spiv | lifeless: Hmm, I'd expect it to Just Work, aside from the usual trick with generators which is they don't really start until the first iteration. | 04:20 |
| lifeless | spiv: bt shows me the current call stack up to the generator only | 04:21 |
| lifeless | spiv: I can tell you how to reproduce easily if you like | 04:21 |
| spiv | Weird, but I'm not totally surprised either. pdb is a bit stupid. | 04:21 |
| spiv | Sure. | 04:21 |
| sohail | lifeless, OK, gonna try now | 04:21 |
| lifeless | spiv: install bzr-groupcompress to start with | 04:21 |
| spiv | I have encountered wierdnesses with pdb + generators before. | 04:21 |
| lifeless | sohail: cool | 04:21 |
| lifeless | spiv: I know which is why I am mentioning | 04:21 |
| sohail | lifeless, ok so bzr merge -r last_good -> bzr is not tracking this merge | 04:21 |
| sohail | i.e., it is a normal diff+patch | 04:22 |
| lifeless | sohail: it should track it. Its '-r X..Y' that it won't track | 04:22 |
| lifeless | sohail: '-r X' will get tracked | 04:22 |
| spiv | Mostly it's just "output looks a bit wonky", occasionally it's "pdb crashes"... | 04:22 |
| lifeless | spiv: this is 'interpreter exits' | 04:22 |
| lifeless | spiv: anyhow, bzr init-repo --gc-plain /tmp/foo | 04:23 |
| lifeless | bzr branch $bzr.dev /tmp/foo/t | 04:23 |
| lifeless | woops | 04:23 |
| sohail | lifeless, howcome when I do bzr st -v it just says files are modified? | 04:23 |
| lifeless | -r 1500 on that | 04:23 |
| sohail | oh no, there it goes | 04:23 |
| sohail | my bad | 04:23 |
| lifeless | spiv: then, BZR_PDB=1 bzr pull -r 1600 -d /tmp/foo/t | 04:23 |
| lifeless | spiv: you will want to do a setup.py build_ext -i in groupcompress | 04:25 |
| sohail | lifeless, it is warning me that I am doing a criss-cross merge | 04:26 |
| lifeless | sohail: thats probably ok in this case, just check the diff before committing and make sure its what you want | 04:27 |
| lifeless | spiv: how is it going | 04:28 |
| spiv | lifeless: just started the -r 1500 | 04:30 |
| spiv | Oh, heh, I need your fix_chunked fix :) | 04:30 |
| lifeless | you worked with mbp on the stacking stuff didn't you ? | 04:30 |
| spiv | I worked a bit on fixing a bug well after it landed... | 04:31 |
| spiv | (bug 291046) | 04:31 |
| ubottu | Launchpad bug 291046 in bzr "pushing branch6/packs5 to location with default stacking policy creates broken branch" [High,Fix released] https://launchpad.net/bugs/291046 | 04:31 |
| lifeless | do you know why add_fallback_repository sets fetch_order to 'topological' ? | 04:31 |
| lifeless | seems weird/unrelated to me | 04:32 |
| davidstrauss | I think Bazaar developers might enjoy this: http://fourkitchens.com/blog/2009/02/03/importance-atomicity-or-why-git-staging-area-bad | 04:32 |
| spiv | No, I don't know why either. I share your confusion. | 04:32 |
| davidstrauss | :-) | 04:32 |
| lifeless | davidstrauss: heh; so I would like to add commit -i | 04:33 |
| lifeless | I do appreciate the philosophic argument that commiting untested code is bad | 04:33 |
| davidstrauss | lifeless: what is commit -i? | 04:33 |
| lifeless | interactive commit, prompt you like shelve does | 04:33 |
| davidstrauss | ah | 04:33 |
| lifeless | but what you say 'n' do isn't committed | 04:33 |
| lifeless | s/do/to/ | 04:34 |
| sohail | lifeless, should I try bzr merge --weave for the bzr merge next step | 04:34 |
| lifeless | I think that we should encourage good behaviour but not punish folk that want to run with knives | 04:34 |
| sohail | it causes less conflicts | 04:34 |
| davidstrauss | an interactive commit would have the same philosophical issues of git staging | 04:34 |
| lifeless | sohail: ah yes, thats probably the criss-cross | 04:34 |
| lifeless | davidstrauss: indeed | 04:34 |
| sohail | lifeless, ok thanks | 04:34 |
| lifeless | davidstrauss: though some less, in that at least it can only commit things that are in front of you | 04:35 |
| lifeless | davidstrauss: git can commit content which isn't in your tree, and wasn't in the previous tree either, if you staged half way through some operation | 04:36 |
| lifeless | I don't want *that* | 04:36 |
| davidstrauss | true | 04:36 |
| lifeless | but I would like you to (for instance) exclude a debugging comment easily | 04:37 |
| lifeless | at the moment you can do that by listing every other file | 04:37 |
| lifeless | a -x option to exclude some files would let you exclude one file, and its a small step from there to excluding one hunk | 04:37 |
| davidstrauss | lifeless: I'd like an interactive commit that cancels if you choose to shelve or unshelve anything. Then, you can run your tests again, re-run commit. If you don't shelve or unshelve anything, the commit goes through. | 04:38 |
| spiv | Right. It's not so much that the ability to do selective commits is bad; but like many tools it should be used with care. | 04:38 |
| lifeless | davidstrauss: Would you be happy if a plugin could hook into bzr commit -i, to make that happen? | 04:39 |
| davidstrauss | lifeless: I think interactive commit itself ought to be the plugin. | 04:39 |
| spiv | lifeless: Hmm, how many minutes and hundreds of MB of RAM will it take for this branch to get past "Transferring:Walking content. 2320/2504"? :) | 04:40 |
| davidstrauss | lifeless: At least initially. | 04:40 |
| lifeless | davidstrauss: I believe it is already. I want something polished and core-quality | 04:40 |
| davidstrauss | lifeless: I see | 04:40 |
| lifeless | spiv: about 4-5 | 04:40 |
| spiv | Oh, there it goes. | 04:40 |
| davidstrauss | spiv: You forgot to tell it to --run-content. | 04:40 |
| lifeless | spiv: I blame knits | 04:40 |
| davidstrauss | spiv: Or --jog-content | 04:40 |
| spiv | davidstrauss: --hyperspace-warp-content would do ;) | 04:40 |
| davidstrauss | Or --meandering-content if you're a masochist with too much time | 04:41 |
| spiv | lifeless: 10.5 for the whole branch -r1500. | 04:41 |
| spiv | 10.5 minutes, that is. | 04:41 |
| davidstrauss | though that kills parallelism :-/ | 04:41 |
| lifeless | spiv: yeah | 04:41 |
| lifeless | spiv: cloning it again is a lot faster | 04:42 |
| lifeless | bzr branch /tmp/foo/t /tmp/faster ;P | 04:42 |
| lifeless | 1m4 for me that is | 04:43 |
| spiv | lifeless: hmm, I'm not sure this is pdb's fault so much as Python's... | 04:44 |
| lifeless | spiv: I didn't blame pdb ;) | 04:45 |
| lifeless | I asked how to get pdb to be useful here | 04:45 |
| lifeless | here @ pedants R us | 04:45 |
| spiv | Actually, no, I blame pdb after all... | 04:47 |
| lifeless | cool | 04:47 |
| lifeless | patch? | 04:47 |
| lifeless | :) | 04:47 |
| spiv | lifeless: http://rafb.net/p/6deAgv30.html is your traceback | 04:47 |
| spiv | I'm still figuring out why pdb can't figure that out. | 04:48 |
| lifeless | yeah thats what I want to see in pdb | 04:48 |
| spiv | And that's what traceback.print_tb(sys.exc_info[2]) gives in that except block. | 04:49 |
| spiv | (using sys.exc_traceback gives the same result) | 04:49 |
| * davidstrauss revs up to start a multi-part blog post series on how we used Bazaar last week during the Drupal.org upgrade sprint to manage a complex set of core patches. | 04:52 | |
| spiv | Ah, I think I see why pdb gets confused. | 04:52 |
| lifeless | davidstrauss: cool | 04:52 |
| davidstrauss | Unfortunately, one of the conclusions is that Loom isn't ready for prime-time. | 04:52 |
| lifeless | thats fair enough | 04:53 |
| lifeless | I would really love feedback on any new (no bugs exist) issues | 04:53 |
| lifeless | even conceptual ones | 04:53 |
| davidstrauss | I'm very happy with the conceptual foundations of Loom. | 04:53 |
| davidstrauss | I think it completely trumps Mercurial queues and StGit there. | 04:54 |
| spiv | lifeless: pdb recursively does t.tb_next on the traceback to find out where to start pdb (because you want to be at bottom of the traceback, where the exception happened), | 04:54 |
| spiv | lifeless: but it relies on being able to recursively walk t.tb_frame.f_back.f_back.f_back... to get back to the top | 04:54 |
| davidstrauss | It's very important that a patch management tool integrated into a distributed VCS allow branching, pushing, pulling, etc. *with all the patches*. | 04:55 |
| spiv | lifeless: and generators break that; f_back ends up as None | 04:55 |
| spiv | lifeless: so pdb takes a perfectly good traceback and manages to fail to use most of it | 04:55 |
| lifeless | davidstrauss: ah yes your bug | 04:56 |
| davidstrauss | lifeless: I'm a little disappointed with the "record" command. | 04:56 |
| lifeless | I haven't seen that bug before and its high on my todo list | 04:56 |
| davidstrauss | It seems like it would be architecturally easier to natively support in-place branch switching and layer loom on top of that. | 04:58 |
| davidstrauss | And by in-place, I mean with all branches being stored git-style. | 04:58 |
| lifeless | davidstrauss: I don't think it would make a great deal of difference; but yes it would reduce the loom-specific code somewhat | 04:58 |
| davidstrauss | Most of the loom issues I run into involve loom's implementation of multiple branch storage for one working tree. | 04:59 |
| lifeless | davidstrauss: ok, well I'm be sure to read your posts if you could link them here | 04:59 |
| davidstrauss | thanks :-) | 05:00 |
| lifeless | userfeedback++ | 05:00 |
| davidstrauss | I love the work you guys do. It's really inspired me to care about the theoretical underpinnings of VCS. | 05:00 |
| lifeless | spiv: so what should pdb do ? | 05:00 |
| spiv | lifeless: http://rafb.net/p/SORZ1J60.html | 05:08 |
| spiv | lifeless: it seems the Pdb class handles this just fine | 05:08 |
| spiv | lifeless: it's just the pdb.post_mortem function that makes the bad assumption that f_back will always work. | 05:08 |
| lifeless | bb:approve | 05:09 |
| lifeless | with extra credit or a bug repo on python itself | 05:09 |
| spiv | Specifically, bdb.Bdb.get_stack seems to cope just fine with this traceback, so long as post_mortem hasn't already neutered it. | 05:09 |
| lifeless | spiv: though s/\<t\>\/tr/ or something | 05:11 |
| spiv | lifeless: sure | 05:11 |
| spiv | lifeless: "tb" is fairly idiomatic | 05:12 |
| lifeless | sure | 05:12 |
| lifeless | just 't' is teh short | 05:12 |
| spiv | Yeah. | 05:12 |
| spiv | I was cribbing furiously from pdb.py at that point, which uses f and t everywhere. | 05:13 |
| lifeless | ugh | 05:13 |
| lifeless | do you debug pdb to fix it | 05:18 |
| lifeless | or just poke to get a theory? | 05:18 |
| spiv | I inserted a "import pdb; pdb.set_trace()" near the top of the except block, and interactively poked at the traceback object while looking at the pdb source. | 05:19 |
| spiv | lifeless: here's a snippet of my session: | 05:19 |
| spiv | (Pdb) pp exc_info[2].tb_next.tb_next.tb_next.tb_next.tb_next.tb_next.tb_next.tb_next.tb_next.tb_next.tb_next.tb_next.tb_next.tb_next.tb_next.tb_next.tb_next.tb_next.tb_next.tb_next.tb_next.tb_next.tb_next | 05:19 |
| spiv | None | 05:19 |
| spiv | ;) | 05:19 |
| spiv | Anyway, post_mortem() is pretty short, it basically follows the tb_next chain to the bottom, so it was a matter of finding out how pdb tries to get back to the top given the bottom. | 05:21 |
| spiv | lifeless: hah, I see that current trunk pdb.py simply doesn't do the fast-forward in post_mortem anymore | 05:24 |
| spiv | AFAICT it will actually leave you at the top of the stack when the prompt starts, though. | 05:25 |
| lifeless | shrug ;P | 05:26 |
| spiv | Hmm, and prior to that change that function had been untouched since 1992... | 05:26 |
| lifeless | ok | 05:28 |
| spiv | Weird, the offending code was removed in http://svn.python.org/view?rev=61312&view=rev, but the commit message is about a totally orthogonal issue. | 05:28 |
| lifeless | so, mathias needs to backport it :) | 05:28 |
| spiv | I was going to try submit a patch to Python, but not I'm just confused :) | 05:28 |
| spiv | Maybe I'll submit a patch anyway, restoring the "start from the innermost frame" feature without the bug we're hitting. | 05:29 |
| lifeless | would be nice | 05:29 |
| spiv | Ah, no, a different commit removed those lines. | 05:35 |
| spiv | I think maybe I want a gannotate that puts a thin red line where some revision deleted lines without adding any... | 05:35 |
| spiv | lifeless: http://bugs.python.org/issue4150 | 05:36 |
| lifeless | spiv: that would be nice, though perhaps nicer would be a [+] | 05:37 |
| lifeless | or a slider for time for the file | 05:37 |
| spiv | lifeless: so, it appears to already be fixed in upstream; the patch is small and nice, I'll ask about a backport. | 05:38 |
| lifeless | well, I'm doing yet-another-check of bzr.dev to validate this fetch issue | 05:39 |
| lifeless | I doubt I'll get more done today :( | 05:39 |
| spiv | lifeless: btw, if you use Python 2.6 you should already have the fixed pdb.py, I think. | 05:42 |
| lifeless | I'm on 8.10 | 05:46 |
| lifeless | perhaps I should take the plunge | 05:46 |
| lifeless | igc: interesting patch | 05:52 |
| lifeless | igc: do you handle new children being added, and do you track those children thereafter? | 05:52 |
| lifeless | and the converse | 05:52 |
| igc | lifeless: i believe so, and files being changed to directories and vice versa :-) | 05:53 |
| igc | lifeless: I'm looking forward to getting a TreeDelta directly from the lower layers when the split inventory stuff is closer | 05:54 |
| igc | then log -v will be *much* better | 05:55 |
| igc | lifeless: just to be clear, I track the *directory* and changes to it | 05:55 |
| igc | so if I file moves out of it, it's no longer tracked when it's out of the directory | 05:56 |
| lifeless | ok | 05:56 |
| igc | in other words, it's more than simply logging dir/* as separate files | 05:56 |
| lifeless | I'm not saying thats right or rong | 05:57 |
| lifeless | but I think it should be made clear to users of the cli and api, if its not today | 05:57 |
| lifeless | I haven't read the code yet | 05:57 |
| igc | lifeless: shall do | 05:57 |
| lifeless | I have some partial parsin via regex stuff I did for bzr-search, which I then shelved. | 05:57 |
| lifeless | how are you doing your partial parsing? | 05:57 |
| lifeless | oh, and a note that may be obvious - you can't use knit deltas at all for what you are doing | 05:58 |
| igc | checking against file-ids and parent-ids in the inventories | 05:58 |
| lifeless | if its not I'll walk you through that | 05:58 |
| igc | please do | 05:59 |
| lifeless | brb gotta pickup caffeine at the shop | 05:59 |
| igc | np | 05:59 |
| lifeless | so | 06:11 |
| lifeless | to do a delta you need to know about deletes | 06:11 |
| lifeless | and knit deltas only tell you about the fact of a delete, not the content of the delete | 06:12 |
| lifeless | igc: ^ | 06:20 |
| igc | lifeless: I think the fact of a delete is enough | 06:24 |
| igc | show_diff_trees() is used to show the patch if requested | 06:24 |
| lifeless | you don't know the id that was deleted | 06:25 |
| igc | won't changes_from() work that out given two RevisionTrees? | 06:26 |
| lifeless | or even that a delete occured in the general case | 06:26 |
| lifeless | igc: yes but that isn't using knit deltas | 06:26 |
| lifeless | maybe we're talking about different things :) | 06:27 |
| igc | lifeless: I think so. I'm generating filtered revision trees and them passing them to changes_from to calc the TreeDelta | 06:28 |
| lifeless | igc: so you let them fully parse the inventory | 06:28 |
| lifeless | igc: ? | 06:28 |
| igc | that's one option (2a in my email), yes | 06:28 |
| lifeless | you said you went 2b though | 06:29 |
| igc | the other option is only building the InventoryEntry's we want. So we parse until we're found the fileids we care about | 06:29 |
| lifeless | igc: using the full xml of the inventory ? | 06:29 |
| igc | saving some time and some oject creation | 06:29 |
| igc | yes | 06:30 |
| lifeless | ok | 06:30 |
| lifeless | also not using the knit deltas ;) | 06:30 |
| igc | right | 06:30 |
| igc | I wasn't clever enough to even consider the knit deltas :-) | 06:30 |
| lifeless | bzr-search has a tuned function for this that does most of what you want | 06:32 |
| lifeless | you might like to compare against it | 06:32 |
| igc | shall do | 06:32 |
| lifeless | it doesn't parse | 06:32 |
| lifeless | but it gets file paths for a set of ids | 06:32 |
| igc | I've been playing with bzr-search a bit lately but haven't dived into the code much yet | 06:32 |
| lifeless | which is similar, it might have some ideas for you even if its not highly relevant | 06:32 |
| igc | lifeless: I like how bzr-search uses it's own area under .bzr | 06:33 |
| igc | I suspect bzr-revnocache ought to do the same thing | 06:33 |
| lifeless | as a starting point, definitely;) | 06:33 |
| igc | I suspect users will feel 100x more confident deleting a cache under .bzr/bzr-revnocache than .bzr/branch :-) | 06:34 |
| lifeless | yah | 06:34 |
| igc | lifeless: any reason why bzr-search shows rev-ids in the UI. I expected revnos :-) | 06:35 |
| lifeless | bzr-revnocache doesn't exist | 06:35 |
| lifeless | at the time of writing | 06:35 |
| lifeless | I have some ideas about how to do it | 06:35 |
| lifeless | but hadn't implemented | 06:35 |
| igc | sure | 06:35 |
| lifeless | a goal in bzr-search was to never implement things that scale badly | 06:36 |
| lifeless | a related issue is 'is this revid in the branch' | 06:37 |
| lifeless | until I can answer that I can't share search indices across branches | 06:38 |
| igc | right. The functionality is sweet, the UI disappoints though. I half-expected to see the same output as bzr-log | 06:38 |
| lifeless | well, I could, but it would be odd to get hits not in your branch | 06:38 |
| lifeless | igc: it does hook into log | 06:38 |
| igc | ah - ok | 06:38 |
| igc | I was aware of the log hook for messages | 06:39 |
| lifeless | igc: bzr log -m '\bRobert\b' | 06:39 |
| lifeless | igc: time that with and w/o a search index | 06:39 |
| lifeless | I would kindof like to add a search specific search syntax - let log use bzr searches native syntax | 06:40 |
| igc | it was more that I hoped bzr-search made "log --authors 'Mr Smith|Mrs Smith'" unnecessary | 06:40 |
| lifeless | but thats harder | 06:40 |
| lifeless | igc: oh, I see. Well it finds both revisions and files; I think hooking into log is appropriate for showing revisions in full detail | 06:41 |
| lifeless | igc: so I'd like 'log -s Smith' to Just Work | 06:41 |
| lifeless | but that needs some refactoring around the query concept in log | 06:41 |
| igc | interesting. | 06:41 |
| lifeless | to hook in cleanly | 06:41 |
| lifeless | not to mention adding a parameter, or whatever | 06:42 |
| lifeless | log -m is unsatisfying in two ways at the moment | 06:42 |
| lifeless | firstly its a regex, and bzr-search doesn't [yet] have a regex engine built in | 06:42 |
| lifeless | so I check for the simplest form of regex I can match | 06:43 |
| lifeless | \bfoo\b == ('foo',) as a search term inside bzr search | 06:43 |
| lifeless | and anything I cant handle, I pass through | 06:43 |
| igc | I saw that bit of the bzr-search code | 06:45 |
| lifeless | I could turn -m 'foo' into '\bfoo\b', in regex terms | 06:45 |
| lifeless | but that isn't drop-in for users | 06:45 |
| lifeless | I like drop-in | 06:45 |
| igc | what's the second issue? | 06:46 |
| lifeless | the standard ui only searches the message | 06:48 |
| lifeless | so bzr-search has to search more, then filter back the results | 06:49 |
| lifeless | its a bit ugly | 06:49 |
| sabdfl | lifeless: how is your current work landing in brisbane-core? | 06:52 |
| jelmer | Peng, pong | 06:52 |
| jelmer | Peng_, pong | 06:53 |
| sabdfl | i haven't seen any movement in brisbane-core since jon in the first week of Jan, other than bzr.dev merges | 06:54 |
| sabdfl | wondering if i'm missing the goodness | 06:54 |
| lifeless | sabdfl: I'm hammering on compression logic at the moment | 06:55 |
| sabdfl | what's the best way to keep up? | 06:56 |
| lifeless | sabdfl: which is why its not showing up in brisbane core; I've been trying to be sure we know what makes git fast/us slow at text extraction, to decide what approach we take to fix the delta compression [and we have to fix it to use brisbane core otherwise its bigger rather than smaller] | 06:56 |
| lifeless | at the moment, because I'm not making changes to brisbane-core, there is my compressbench benchmarker | 06:57 |
| sabdfl | ok | 06:57 |
| lifeless | and groupcompress had some stuff land in it today, which takes it to 5 times faster than knits for decompression, on average | 06:57 |
| lifeless | for the use case of examine-all-history | 06:58 |
| lifeless | I'm sorry, I have to head off now, just about 6 and stuff happening :) | 06:58 |
| lifeless | I'll drop a mail to you about tracking what we're doing, and what we're doing tomorrow | 06:59 |
| * lifeless is gone | 07:01 | |
| vila | hi all | 07:13 |
| Peng_ | jelmer: Hi. I just wanted to ask you one thing: You marked bug 322856 as fixed, but I still get it. Do I have to delete svn-cache or anything? | 07:19 |
| ubottu | Launchpad bug 322856 in bzr-svn "svn-v4 revids are used for tags on an svn-v3 branch" [Medium,Fix released] https://launchpad.net/bugs/322856 | 07:19 |
| jelmer | Peng_, bzr-svn 0.5 revno 2507 ? | 07:22 |
| Peng_ | jelmer: Yep. | 07:23 |
| jelmer | Peng_, Which tags do not work ? | 07:27 |
| Peng_ | jelmer: .bzr/branch/tags is exactly the same as it was beforehand. | 07:27 |
| Peng_ | jelmer: Ehh, what's the right way to test it? i just renamed .bzr/branch/tags and tried "pull". | 07:28 |
| jelmer | Peng_: Yeah, that should work | 07:28 |
| jelmer | Peng_: So lots of question marks? | 07:28 |
| jelmer | I've confirmed it working here with lighttpd 1.4.x and trunk | 07:28 |
| Peng_ | jelmer: Hmm, I just tried it on 1.4.x and it only produced two svn-v4 tags, which means it's almost perfect. I had tried it on 1.3.x earlier. | 07:29 |
| jelmer | Peng_, 1.3.x will indeed give lots of "?" marks since I suspect most of the revisions that are tagged are not in its ancestry | 07:30 |
| Peng_ | ...Good point. | 07:31 |
| Peng_ | OK, my mistake. (Especially since 1.3.x uses all svn-v4 IDs anyway.) | 07:32 |
| Peng_ | 1.4.x still created a couple bad tags, though, didn't it? | 07:32 |
| jelmer | just two question marks here | 07:33 |
| jelmer | and those are for revisions not in the ancestry | 07:33 |
| Peng_ | OK. | 07:33 |
| Peng_ | Sorry for bothering you, then. | 07:34 |
| Peng_ | And thanks for fixing the bug. | 07:34 |
| jelmer | np | 07:34 |
| sohail | more bzr-hole-digging... I did rm -rf /path/to/branch but now when I try to switch an checkout bound to branch to master, it says: "unable to connect to target of bound branch /path/to/branch: not a branch: /path/to/branch" | 07:58 |
| davidstrauss | sohail: are you running unbind? | 08:12 |
| sohail | davidstrauss, yeah I ran unbind after I saw that message | 08:15 |
| sohail | then it said: "Can't switch on branch only checkout" | 08:15 |
| davidstrauss | sohail: unbind does not talk to the parent branch | 08:15 |
| davidstrauss | sohail: branch-only checkout? | 08:15 |
| sohail | argh | 08:15 |
| sohail | this is so confusing | 08:15 |
| davidstrauss | sohail: what did you run to create the checkout? | 08:16 |
| sohail | davidstrauss, I'm pretty sure it was a clone actually | 08:16 |
| davidstrauss | sohail: then unbind should say that you can't unbind what is already a standalone branch | 08:16 |
| sohail | davidstrauss, it didn't say that | 08:18 |
| davidstrauss | sohail: what do you get from bzr info? | 08:18 |
| ronny | moin | 08:18 |
| sohail | davidstrauss, oh I decided to dig myself into a deeper hole and rm -rf | 08:19 |
| sohail | so now I don't know | 08:19 |
| sohail | ronny, moin | 08:19 |
| ronny | jelmer: can you take a look at the commit method line 125 in http://paste.pocoo.org/show/102549 | 08:19 |
| davidstrauss | sohail: i'm talking about the alleged checkout | 08:19 |
| sohail | davidstrauss, yeah I know it's gone | 08:19 |
| ronny | jelmer: it complains about added paths in the repo not being versioned | 08:19 |
| davidstrauss | sohail: what do you have left? | 08:19 |
| sohail | davidstrauss, nothing | 08:19 |
| sohail | I'm just doing a fresh checkout now | 08:19 |
| davidstrauss | sohail: oh, yeah, bzr can't help if you delete everything | 08:20 |
| sohail | nope | 08:20 |
| sohail | oh well :-) | 08:20 |
| sohail | davidstrauss, can I still work offline with a checkout? | 08:20 |
| davidstrauss | sohail: sort of, but i don't recommend it | 08:20 |
| sohail | argh | 08:21 |
| sohail | so how do you do this when offline: http://bazaar-vcs.org/Tutorials/CentralizedWorkflow | 08:21 |
| * igc dinner | 08:21 | |
| sohail | ah I see | 08:22 |
| davidstrauss | sohail: you sort of can't | 08:22 |
| sohail | bzr commit --local | 08:22 |
| sohail | orly? | 08:22 |
| davidstrauss | sohail: be very wary of --local | 08:22 |
| sohail | http://bazaar-vcs.org/CheckoutTutorial | 08:22 |
| sohail | why? | 08:22 |
| davidstrauss | sohail: https://bugs.launchpad.net/bzr/+bug/113809 | 08:23 |
| ubottu | Launchpad bug 113809 in bzr "update performs two merges" [High,Confirmed] | 08:23 |
| sohail | wonderful | 08:25 |
| sohail | well it is as important to know the limitations of your tools as it is to know your own limitations :-) | 08:26 |
| ronny | hmm | 08:27 |
| ronny | i wish i did know whats wrong there | 08:27 |
| ronny | jelmer: it seems like some methods require me to use the way of abspath -> wt.relpath to get working results | 08:33 |
| ronny | hmm | 08:38 |
| ronny | jelmer: WorkingTree.rename_one seems nasty, imho too much semantics | 08:38 |
| jelmer | ronny: hi | 08:42 |
| ronny | ok | 08:43 |
| ronny | wth a bit luck all bzr tests will pass now | 08:43 |
| ronny | yay | 08:43 |
| ronny | native bzr support done | 08:44 |
| ronny | (at least for workdirs) | 08:44 |
| jelmer | ronny: w00t :-) | 08:44 |
| ronny | hmm | 08:44 |
| jelmer | hmm? | 08:44 |
| ronny | i still have to deal with branch-management now | 08:45 |
| jelmer | I'll be away again in a bit, my class is starting | 08:45 |
| jelmer | ronny: but feel free to talk to me, I'll reply when I get back | 08:45 |
| ronny | k | 08:46 |
| ronny | i have no classes at, exams time | 08:46 |
| jelmer | ronny: ah, that explains why you have so much time to work on anyvc ;-) | 09:46 |
| nua | if I run a smartserver over ssh and someone pushes/pulls/commits/uncommits will the post_push() etc hooks run on the server machine? If not, can I find out what the action was that caused a post_change_branch_tip() hook to fire? | 10:00 |
| nua | ...obviously the plugin would be installed on the server, not the client machine | 10:00 |
| mwhudson | nua: the hooks will run on the server side, yes | 10:05 |
| nua | mwhudson: thanks, I'll get writing some code then :) | 10:06 |
| nua | mwhudson: I can't seem to get post_commit to work on the server, currently only have post_change_tip_working | 10:31 |
| Peng_ | Do pushes count as "commits" for post_commit? | 10:34 |
| Peng_ | jelmer: ping? | 10:41 |
| jelmer | Peng_, pong? | 10:41 |
| Peng_ | jelmer: Hi. Quick question: is it safe to do "bzr log" on an svn branch at the same time as a "bzr branch" is importing it? Can svn-cache handle concurrent access and all? | 10:43 |
| jelmer | Peng_, You might run into bug 185200 | 10:43 |
| ubottu | Launchpad bug 185200 in bzr-svn ""database is locked" bzr internal error" [Low,Triaged] https://launchpad.net/bugs/185200 | 10:43 |
| jelmer | although it shouldn't cause corruption or anything | 10:43 |
| Peng_ | jelmer: If it happens at the wrong time, could that kill the "bzr branch"? | 10:43 |
| jelmer | peng_: yes | 10:44 |
| Peng_ | Eh. That would be bad. | 10:44 |
| Peng_ | Oh, good. I risked it anyway and nothing bad happened. | 10:44 |
| Peng_ | jelmer: Thanks. :) | 10:46 |
| * Peng_ wonders why the progress bar says revision 1154 is taking so long, when it should be tiny. | 10:46 | |
| jelmer | no idea | 10:46 |
| Peng_ | I _do_ have several really large revisions, but it shouldn't be that one. | 10:47 |
| vila | mwhudson: ping | 10:51 |
| UdontKnow | Hi | 11:24 |
| AfC | That's a good nick. | 11:33 |
| UdontKnow | AfC: and an old one | 11:38 |
| === abentley1 is now known as abentley | ||
| === Kamping_Kaiser is now known as kgoetz | ||
| gorgapor | #join bzr-dev | 14:12 |
| Peng_ | There's a #bzr-dev? | 14:12 |
| gorgapor | lol, no actually | 14:12 |
| gorgapor | sorry for the typo | 14:12 |
| gorgapor | but i do have a development question: with bzrlib, how do i get the root folder of the current branch? | 14:13 |
| Peng_ | I don't know. You mean like the "bzr root" command? If so, you could check how it's implemented. | 14:13 |
| gorgapor | hey cool, i didn't know about that command | 14:14 |
| gorgapor | yeah i'll check that | 14:14 |
| gorgapor | thanks | 14:14 |
| guilhembi | gorgapor: hi! you could do this: | 14:19 |
| guilhembi | self.wt = WorkingTree.open_containing(u'.')[0] | 14:19 |
| guilhembi | then self.wt.basedir is the root dir. | 14:20 |
| guilhembi | (at least it used to be true a few months ago, haven't checked since). | 14:20 |
| gorgapor | guilhembi: thanks. actually though, i came up with a very similar solution from diving into the bzrlib source | 14:20 |
| gorgapor | but you suggesting the same thing gives me much more confidence that i'm doing it the right way | 14:20 |
| guilhembi | :) | 14:21 |
| igc | night all | 14:30 |
| === nevans1 is now known as nevans | ||
| === kiko-afk is now known as kiko | ||
| nua | quick q: just looking at the bzrlib api docs, what is branch stacking? | 15:16 |
| Peng_ | nua: Errm. When you do "bzr branch --stacked", bzr does not download and save the entire history. | 15:17 |
| Lo-lan-do | nua: As far as I understood it, it's just saying that part of the history of a branch is stored remotely. | 15:17 |
| Peng_ | That works too. | 15:17 |
| nua | Ok, I can safely ignore that for now then :) | 15:17 |
| nua | If I'm adding something to the post_change_branch_tip hook on a smart server, I get passed branch as an arg, how do I get the path that branch is currently stored at on the server? get_bound_location()? | 15:19 |
| ronny | jelmer: ping? | 16:29 |
| jelmer | ronny, pong | 16:29 |
| ronny | jelmer: is there any reason why some apis require me to call WorkingTree.relpath on absolute paths before they work? | 16:30 |
| ronny | and does it change for newer bzr versions | 16:30 |
| ronny | (im currently on 1.6) | 16:31 |
| ronny | cause of ubuntu | 16:31 |
| jelmer | ronny, generally, relative paths should always be save (since that's what the Tree API uses) | 16:38 |
| jelmer | ronny, I think my earlier recommendation to just specify absolute paths is incorrect | 16:39 |
| jelmer | ronny, and that using relative paths everywhere would be the sa{f,n}est way to go | 16:39 |
| ronny | jelmer: my cwd is always different from the tree path, and it takes all relative paths relative to the cwd | 16:39 |
| jelmer | ronny, you should be able to use wt.relpath(wt.abspath(path)) | 16:41 |
| jelmer | ronny, not really neat, but should do the job.. | 16:41 |
| ronny | not exactly nice | 16:41 |
| ronny | well, its what i do atm | 16:43 |
| kfogel | I just did 'bzr tag release-0.1.82' in a branch of the bkrpr project that otherwise was totally up-to-date and had no uncommitted changes, then did 'bzr push lp:bkrpr'. | 16:51 |
| kfogel | But nothing got pushed, and when I later did 'bzr pull' in my mirror of trunk, nothing came down. | 16:52 |
| kfogel | The help for 'bzr tag' says that tags are pushed/pulled between branches just like revisions, but that didn't seem to happen. | 16:52 |
| kfogel | Am I missing something? | 16:52 |
| fullermd | You sure the tag didn't come down? | 16:52 |
| kfogel | By the way, 'bzr status' immediately after I made the tag also showed no changs. | 16:52 |
| kfogel | fullermd: well, let me see... | 16:52 |
| kfogel | fullermd: holy cow | 16:53 |
| kfogel | fullermd: well, you're right | 16:53 |
| kfogel | it came down | 16:53 |
| kfogel | it's just that neither the push nor the pull indicated that *anything* had been transmitted. | 16:53 |
| * fullermd nods. | 16:53 | |
| kfogel | They looked exactly as if I had pushed or pulled when there are no changes. | 16:53 |
| fullermd | That's one of the long-standing quirks of tags. | 16:53 |
| Lo-lan-do | Is there a way to tell bzr not to look for a smart server when accessing a branch through HTTP? | 16:55 |
| Lo-lan-do | I'd like to get rid of "File does not exist: /srv/bzr/fusionforge/svn-Branch_4_7-ro/.bzr/smart" in the Apache logs. | 16:56 |
| sanctus | Hi, can I hide my commit made in one of my branch before pushing it to the main repository? (distribute) | 16:56 |
| === NfNitLoo` is now known as NfNitLoop | ||
| Tak | jelmer: ping md-bzr | 17:10 |
| jelmer | Tak, hi | 17:10 |
| Tak | hello | 17:10 |
| Tak | so, I'm playing with bzr shell as an alternative interface | 17:11 |
| Tak | it's a bit slower for "regular" operations like checking file status | 17:11 |
| jelmer | Tak: If you're looking at alternative interfaces, xmloutput should be the primary choice I think | 17:11 |
| Tak | is there a minimum version for that? | 17:12 |
| jelmer | it's a plugin, I'm not sure what bzr version it requires | 17:12 |
| jelmer | Tak, I thought you were importing bzrlib using IronPython - does that not work? | 17:13 |
| Tak | no, ironpython only works with ironpython :-/ | 17:13 |
| Tak | using bzrlib directly would be ideal | 17:14 |
| === thekorn_ is now known as thekorn | ||
| Tak | hmm, xmloutput only implements a subset of the commandset I'm using | 17:15 |
| jelmer | there is also another C#-based wrapper of bzrlib around, ahve you looked at that? | 17:16 |
| jelmer | I think it's in the bzr-visualstudio project, not sure what state it's in | 17:16 |
| Tak | hmm, I think you pointed me to that before | 17:16 |
| Tak | if it's the one I recall, I couldn't get it to build | 17:16 |
| enigma42 | subvertpy question... | 17:25 |
| enigma42 | I'm getting errors | 17:25 |
| mwhudson | darn it vila | 17:25 |
| mwhudson | 's gone | 17:25 |
| enigma42 | bzr: ERROR: subvertpy.SubversionException: ("Commit blocked by start-commit hook (exit code 1) with output:\nProject 'sequoia' requires that committing clients be mergeinfo-aware,\nbut yours is not. Consider upgrading to a client that is using Subversion 1.5\n(or newer) libraries.", 165001) | 17:25 |
| enigma42 | I'm thinking the subvertpy client isn't "mergeinfo" aware? | 17:26 |
| jelmer | hi enigma42 | 17:26 |
| enigma42 | jelmer: Hi. :-) | 17:26 |
| Peng_ | jelmer: If I discover some odd traceback in bzr-svn, should I ask you here or go straight to filing a bug? | 17:28 |
| jelmer | enigma42: hmm | 17:28 |
| Peng_ | jelmer: BTW, congrats on releasing 0.5.0. :) | 17:28 |
| jelmer | enigma42, this is not a standard svn server, is it? | 17:28 |
| Tak | "pybaz - python bindings for the bazaar revision control system" | 17:28 |
| * Tak blink | 17:28 | |
| Peng_ | Tak: Presumably the old "baz" project, not the current "bzr" project. | 17:29 |
| jelmer | Peng_, thanks! | 17:29 |
| jelmer | enigma42, Is this against a project you've used bzr-svn with before? | 17:30 |
| enigma42 | jelmer: It's a collabnet server. | 17:30 |
| jelmer | enigma42, is subvertpy linked against svn 1.5 on your machine? | 17:31 |
| enigma42 | jelmer: Yeah, I've used this project before. | 17:32 |
| enigma42 | jelmer: The difference is that collabnet just upgrade us to SVN 1.5 on the server recently. | 17:32 |
| jelmer | enigma42, it seems like a change on their end, could that be? | 17:32 |
| jelmer | enigma42, it's not just svn 1.5 on the server, it's some custom commit hook they seem to have | 17:32 |
| enigma42 | Oh...I see... | 17:33 |
| jelmer | enigma42, I would be curious as to what they seem to use as the metric to determine whether a client is merge-info aware | 17:33 |
| enigma42 | Yeah....I'll try to track that down. | 17:33 |
| enigma42 | jelmer: Oh...how can I tell which svn lib subvertpy is linked against? | 17:35 |
| jelmer | ldd on _ra.so | 17:35 |
| enigma42 | jelmer: OK. Thanks. | 17:35 |
| enigma42 | jelmer: subvertpy is definitely linked against svn 1.5...so like you said...it seems like a strange hook. | 17:38 |
| Peng_ | jelmer: Well, um, I got an assertion in RevisionMetadata._set_direct_lhs_parent_revmeta while pulling a branch with bzr-svn 0.5 (latest revision) that I used to use with 0.4. http://paste.pocoo.org/show/qHxKKSCAS4i2Xv3Z0VaY/ | 18:04 |
| === bac is now known as bac_lunch | ||
| luke-jr | Does Bazaar support write-once repositories? ☺ | 18:06 |
| luke-jr | for example, a CD-R | 18:07 |
| luke-jr | (with a tar filesystem, not iso) | 18:08 |
| mwhudson | packs are written in big chunks | 18:08 |
| jelmer | Peng_, please file a bug | 18:08 |
| Peng_ | jelmer: Alrighty. | 18:08 |
| mwhudson | but i guess it will be unhappy that it can't delete old ones | 18:08 |
| Peng_ | Did I file another bug about that repo in the past? | 18:08 |
| jelmer | Peng_, nope | 18:09 |
| Peng_ | Bazaar would probably also be unhappy if it couldn't take out locks... | 18:09 |
| jelmer | peng_: ah, oops | 18:10 |
| Peng_ | jelmer: ? | 18:11 |
| jelmer | peng_: it's barfing on the fact that that file is named "tags" | 18:11 |
| Peng_ | jelmer: Oh. Well, um, I just filed a bug anyway. Oops? | 18:16 |
| jelmer | Peng_, Thanks | 18:16 |
| jelmer | Peng_, This way we can track it, that's useful. | 18:16 |
| Peng_ | Okay. | 18:16 |
| Peng_ | (Bug 324970, if you haven't checked your bugmail yet.) | 18:17 |
| ubottu | Launchpad bug 324970 in bzr-svn "RevisionMetadata._set_direct_lhs_parent_revmeta asserts while pulling ack's trunk" [Undecided,New] https://launchpad.net/bugs/324970 | 18:17 |
| speakman | hi folks, how is rebase supposed to work? i tried bzr rebase -r 10..11 and it just tracebacked. | 18:26 |
| jelmer | speakman, which version of rebase? | 18:26 |
| jelmer | Peng_, ROFL | 18:26 |
| jelmer | Peng_, I was checking for path_elements[i-1] == "tags" somewhere | 18:27 |
| jelmer | Peng_, of course when parsing "trunk/tags", that ends up being [-1] | 18:27 |
| jelmer | speakman: generally though, you shouldn't need to specify a range of revisions to rebase | 18:28 |
| Peng_ | jelmer: So it's easy to fix? :) | 18:28 |
| speakman | BBBBBBbzr: ERROR: No common revision, please specify --revision | 18:28 |
| speakman | except for those "BBBB" :D | 18:28 |
| speakman | rebase 0.3 | 18:29 |
| jelmer | speakman, what are you trying to accomplish exactly? Because I think rebase might not be the right tool for the job | 18:29 |
| jelmer | you can't combine two unrelated branches with it, since they will have different file ids | 18:29 |
| jelmer | Peng_, yup | 18:29 |
| speakman | I'm not sure what rebase actually means, but I was thinking it could "flatten" all merges in the history log | 18:30 |
| Peng_ | jelmer: Great. :) | 18:30 |
| jelmer | speakman: not existing merges though, it's more of an alternative to merge than a way to change merges | 18:32 |
| jelmer | speakman, of course, you should be able to re-do all your merges using rebase | 18:32 |
| speakman | boh, i see | 18:34 |
| speakman | oh* | 18:34 |
| speakman | jelmer: can I redo merges now, or what do you mean? | 18:34 |
| speakman | hm, now bzr (in another branch) claims that it's locked. How do one remove locks? | 18:37 |
| jelmer | speakman, you'll basically have to uncommit everything in your branch and re-do the merges, but running "bzr rebase" where you had previously run "bzr merge"" | 18:37 |
| jelmer | speakman, "bzr break-lock" | 18:37 |
| jelmer | speakman, what's the fundamental problem you're trying to solve? | 18:41 |
| jelmer | (Why do you need to flatten your merges?) | 18:42 |
| speakman | most curios actually, but if there's a way to put merges on top of history instead of making a unnecessary merge post it's pretty interesting | 18:43 |
| speakman | I've now "uncommit" so it says "pending merges:" at "bzr status", could I do rebase at this stage? | 18:43 |
| jelmer | Peng_, pushed | 18:44 |
| jelmer | speakman, yes, you can now run e.g. "bzr rebase --pending-merges" | 18:44 |
| jelmer | for --pending-merges you need 0.4 though I think | 18:44 |
| === kiko__ is now known as kiko-afk | ||
| jelmer | speakman: rebasing is generally considered bad though, because it changes the identity of rebased revisions so you should only ever use rebase on revisions that aren'd pushed yet and in use by other people. | 18:49 |
| Tak | hmm, it was pretty straightforward to move to xmloutput for the supported commands | 18:49 |
| jelmer | tak: cool | 18:49 |
| speakman | bzr: ERROR: no such option: --pending-merges | 18:50 |
| jelmer | tak: now if only I could get it to compile.. :-( | 18:50 |
| jelmer | speakman, you need bzr-rebase >= 0.4 | 18:51 |
| speakman | oh, is there a PPA for that? | 18:51 |
| jelmer | no, but you should be able to run something like "bzr branch lp:bzr-rebase ~/.bazaar/plugins/rebase" to install it | 18:51 |
| mwhudson | bzr will never block on taking a read lock, will it? | 18:51 |
| Tak | jelmer: what's the issue you're having? | 18:53 |
| jelmer | Tak, monodevelop version too old | 18:53 |
| sanctus | can I hide my commit made in one of my branch before pushing it to the main repository? (distribute) | 18:54 |
| Tak | ohh...yeah, and md-trunk requires mono >= 2.0 which isn't in any distro but opensuse yet | 18:54 |
| === bac_lunch is now known as bac | ||
| speakman | jelmer: thanks, now rebase actually works too ;) | 18:55 |
| dobey | hola | 19:02 |
| dobey | bzr can have commit hooks that run at the commit stage, rather than the push stage, no? | 19:02 |
| jelmer | dobey, yes | 19:02 |
| dobey | is that documented on the wiki? | 19:03 |
| jelmer | I'd doubt it, there isn't much API documentation on the wiki | 19:03 |
| jelmer | dobey: the regular python API tools should be able to help you | 19:04 |
| dobey | ah. how would i set up a pre-commit hook? write a plug-in? | 19:04 |
| jelmer | dobey, yep | 19:04 |
| dobey | ok | 19:04 |
| dobey | well that's 43433232x better than what git does :) | 19:04 |
| dobey | though i was hoping i could just drop a script somewhere, and anyone that pulls the branch will get that hook run when they do a commit | 19:05 |
| dobey | which i suppose i could sort of implement with a plug-in as well anyway | 19:06 |
| jelmer | dobey, that seems like a bad idea to me for security reasons | 19:06 |
| dobey | why? | 19:07 |
| jelmer | I wouldn't want code from $RANDOM_BRANCH I fetched to automatically run | 19:07 |
| dobey | well, people already do that anyway | 19:07 |
| dobey | ./configure && make will do that :) | 19:07 |
| jelmer | dobey: that's intentional decision by the user; it's not a side-effect of running "bzr <subcommand>" | 19:08 |
| dobey | jelmer: but you can stick arbitrary code in configure, or a makefile, or have it run a built binary, and very few people if any actually read every line of code before building/running a project | 19:09 |
| dobey | so i don't know that i would call it a security issue really | 19:10 |
| LarstiQ | dobey: I know I do. | 19:10 |
| LarstiQ | dobey: at least with confingure you are aware there is execution going on. | 19:10 |
| dobey | interestingly enough, we just had a similar conversation in #gnome-hackers, because i was wondering if git would let me do stuff | 19:10 |
| dobey | LarstiQ: but you don't necessarily know what | 19:11 |
| dobey | you just assume it's configuring to build | 19:11 |
| jelmer | dobey, you can have a look before you run configure | 19:11 |
| jelmer | dobey, hooks can even trigger e.g. during fetch | 19:11 |
| LarstiQ | dobey: you have a lead to go find out if you want to, and you can do so before running anyting. | 19:12 |
| dobey | they could, but i only want these to run before commit succeeds | 19:12 |
| jelmer | dobey, of course, nothing stops anybody from creating a "bzr-insecure" plugin that provides this sort of functionality :-) | 19:12 |
| LarstiQ | dobey: unless hooks prompt everyhere, without being able to override that from the hooks, you have no such protection. | 19:13 |
| dobey | LarstiQ: you could too if the hooks were in the branch | 19:13 |
| LarstiQ | dobey: hmja | 19:13 |
| dobey | bah, if you don't trust the branch your pulling, don't pull it! | 19:13 |
| dobey | i doubt you've read every line of code that's currently running on your machine :) | 19:14 |
| LarstiQ | dobey: if you were to have a go at a bzr-insecure plugin, I'd start by printing out a summary of what hooks are 'hooked' | 19:14 |
| LarstiQ | dobey: I've delegated that to the Debian developers, whom I trust ;P | 19:15 |
| dobey | LarstiQ: by default it probably wouldn't be anything | 19:15 |
| LarstiQ | dobey: that way you might have a better chance of convincing people who don't share your opinion that the risk is mitigated. | 19:15 |
| dobey | of course the things i want to do this with are currently in git or svn (and about to be moved to git :-/), so making a bzr plug-in wouldn't really help me all that much | 19:17 |
| speakman | is there any reason there's not an "--update-working-tree" option in "push"? :) | 19:17 |
| dobey | but i wanted to compare, since git doesn't do it at all | 19:17 |
| jelmer | speakman, at some point the smart server will hopefully update the working tree automatically | 19:19 |
| jelmer | speakman, it's not feasible over e.g. sftp or ftp | 19:19 |
| speakman | how come? | 19:20 |
| speakman | aka why not? | 19:20 |
| rexbron | james_w: Did you get a chance to look at my reply to your review of bd.profiles? | 19:20 |
| jelmer | speakman: you have to retrieve / re-upload every single file | 19:21 |
| speakman | using (s)ftp to send the files directly from the current working tree? | 19:21 |
| jelmer | speakman, you can't just upload, you have to make sure the remote hasn't changed | 19:21 |
| speakman | hm what about requiring --overwrite ? :) | 19:21 |
| jelmer | speakman, --overwrite is about overwriting the branch, not about overwriting files in the working tree | 19:21 |
| jelmer | speakman, there is a plugin that can ssh into the remote server and run "bzr up" for you | 19:22 |
| speakman | I'm aware of that plugin, but would be builtin imo | 19:23 |
| speakman | when supported in smart server; will it then work with ssh+bzr which I believe runs the same code? | 19:23 |
| speakman | (at the remote place) | 19:23 |
| jelmer | speakman, it would do something similar, but inside of bzr and wouldn't require any additional connections | 19:24 |
| speakman | But I will not be required to have an "bzr serve" runnint 24/7 to be able to update remote tree? | 19:24 |
| speakman | as long as bzr is actually running on the remote side, there should be any differences right? | 19:25 |
| jelmer | speakman, bzr serve isn't used by bzr+ssh | 19:25 |
| jelmer | well, not as a daemon, anyway | 19:25 |
| speakman | but if smart serve is able to update remote working tree, why should bzr+ssh ? :) | 19:27 |
| jelmer | speakman: bzr+ssh is using the smart server | 19:30 |
| jelmer | speakman, it basically runs "ssh <host> bzr server --inetd" | 19:30 |
| speakman | hm? 20:25 < jelmer> speakman, bzr serve isn't used by bzr+ssh | 19:30 |
| jelmer | speakman, <jelmer> well, not as a daemon, anyway | 19:31 |
| speakman | oh, missed that :D :D | 19:32 |
| speakman | how far away is that support? is there something one could support? | 19:33 |
| jelmer | for updating the workingtree from the smart server? | 19:35 |
| jelmer | I think the main thing that needs to be done is adding a verb in the smart server protocol for it | 19:35 |
| jelmer | don't think anybody is planning on working on it though | 19:35 |
| speakman | how can one get engage with bzr? | 19:38 |
| LarstiQ | jelmer: did I already congratulate you with getting 0.5 released? If not, bij deze :) | 19:38 |
| speakman | 0.5? | 19:39 |
| jelmer | LarstiQ, thanks! | 19:39 |
| jelmer | speakman, see http://bazaar-vcs.org/BzrDevelopment for hints about development | 19:39 |
| jelmer | you can also always ask here of course | 19:39 |
| jelmer | speakman, bzr-svn 0.5.0 | 19:39 |
| LarstiQ | it does seem like that page is a bit out of date | 19:41 |
| LarstiQ | http://bazaar-vcs.org/BzrGivingBack might also have some bits | 19:42 |
| speakman | bzrtools in the PPA is lagging behind and currently stops bzr for being upgraded | 19:55 |
| Lo-lan-do | What is this PPA everyone complains about? | 19:57 |
| speakman | deb http://ppa.launchpad.net/bzr/ubuntu intrepid main | 19:57 |
| Lo-lan-do | What's it supposed to mean? | 19:58 |
| Lo-lan-do | (Also, why don't you just grab the packages from experimental?) | 19:58 |
| jelmer | Lo-lan-do, it's the ubuntu equivalent of private repositories | 19:59 |
| LarstiQ | Lo-lan-do: Personal Package Archive | 20:04 |
| LarstiQ | jelmer: any idea what the policy is, would I be allowed to upload bzrtools to the PPA? | 20:05 |
| jelmer | LarstiQ, yes, you only have to be in ~bzr | 20:05 |
| Lo-lan-do | So any Launchpad user can have their archive hosted on Launchpad? | 20:05 |
| jelmer | Lo-lan-do, yep | 20:05 |
| jelmer | unfortunately uploading for multiple versions of Ubuntu is a pain | 20:06 |
| Lo-lan-do | I'll bet many people use these PPAs too. | 20:06 |
| Lo-lan-do | Sounds like an excellent way to get packages of dubious origins and quality on one's system. | 20:06 |
| jelmer | Lo-lan-do, a lot of them are just used for testing the packages | 20:07 |
| jelmer | Lo-lan-do, since you upload a source package, and it builds in a chroot | 20:08 |
| jelmer | well, in some sort of jail (xen?) | 20:08 |
| lifeless | moin moin | 20:08 |
| LarstiQ | Lo-lan-do: trusting PPAs is of course up to the user/sysadmin. | 20:08 |
| LarstiQ | hey lifeless | 20:08 |
| Lo-lan-do | I don't doubt it, I just fear that many users will trust the URL ("oh, it has launchpad in it, must be supported by Canonical in some way") and install stuff from there with no second thoughts. | 20:08 |
| maxb | Well, apt will do the usual "key not trusted" warings | 20:09 |
| maxb | *warnings | 20:09 |
| Lo-lan-do | I'm still amazed at the amount of trust people put in *random* URLs, so I can only be frightened by such a thing. | 20:09 |
| maxb | Well, there's little that can be done to help people who don't check anything at all :-/ | 20:10 |
| jelmer | Lo-lan-do, they have different keys they're signed with | 20:10 |
| Lo-lan-do | Sure, but giving them the appearance of being "official" probably doesn't help. | 20:10 |
| maxb | Uploading for multiple versions would probably be reasonably scriptable, using "dch" | 20:10 |
| Lo-lan-do | (And "invalid key" mostly means not much more than "one extra click") | 20:11 |
| Lo-lan-do | But pardon me for rambling at users, we're here to celebrate bzr-svn 0.5 :-) | 20:12 |
| jelmer | Lo-lan-do: otoh, there's lots of people installing *single* .deb's they download from the net | 20:12 |
| jelmer | Lo-lan-do, stuff in PPA's will at least build from source cleanly | 20:13 |
| Lo-lan-do | jelmer: Do you know of a (possible) bug where bzr-svn would output "bzr: ERROR: No such file" after a merge done in SVN? | 20:15 |
| jelmer | Lo-lan-do, nope | 20:15 |
| jelmer | Lo-lan-do, what does ~/.bzr.log say? | 20:15 |
| Lo-lan-do | jelmer: http://pastebin.com/d47efe066 | 20:16 |
| Lo-lan-do | But I'm not sure it still happens with 0.5.0 since I upgraded later than that log, and I also tried to work around the bug based on a hypothesis of mine. | 20:17 |
| jelmer | Lo-lan-do, yeah, some similar issues to this were fixed | 20:18 |
| Lo-lan-do | As far as I can tell, the problem appeared when pulling from a branch that's bound to (and bzr update'd from) an SVN trunk after a merge. | 20:18 |
| Lo-lan-do | Data flow: on my local machine, bugfix in branch_foo (bound to SVN /branches/foo), cd ../trunk (bound to SVN trunk), bzr merge ../foo, bzr commit. | 20:19 |
| Lo-lan-do | On the remote box, bzr update in svn-gw/trunk (bound to SVN trunk), cd ../branch-foo, bzr pull ../trunk. | 20:20 |
| Lo-lan-do | Anyway, I added a gateway for the SVN branch too, and it seems to work now. | 20:21 |
| === spm_ is now known as spm | ||
| LarstiQ | speakman: ok, ppa is a liiitle more involved to set up. | 20:34 |
| maxb | only just barely. sources.list line, pgp key, done :-) | 20:35 |
| speakman | hm? | 20:35 |
| === abadger19991 is now known as abadger1999 | ||
| LarstiQ | maxb: I meant building bzrtools 1.11 for the ppa | 20:38 |
| LarstiQ | maxb: doc/developers/ppa.txt if you're interested | 20:38 |
| maxb | hm? I built it locally just by grabbing the Debian experimental source | 20:38 |
| Lo-lan-do | jelmer, Jc2k: Can the bzr-*-pack scripts from bzr-git be run from ~/.bazaar/plugins/git, or do they need to be installed somehow? | 20:40 |
| jelmer | Lo-lan-do, they would have to be installed (as /usr/bin/git-*pack actually) | 20:41 |
| jelmer | Lo-lan-do, they're for the server side with ssh though | 20:41 |
| Lo-lan-do | I gathered that much, but apparently symlinking them into ~/bin isn't enough and I get "ImportError: No module named git.server" | 20:42 |
| Jc2k | Lo-lan-do: that may well just be typos - i cant remember how thoroughly they were tested.. | 20:44 |
| Jc2k | hmm | 20:48 |
| Lo-lan-do | Jc2k: I can't seem to get it working after an installation --prefix=$HOME, either. | 20:52 |
| vila | mwhudson: ping | 21:03 |
| mwhudson | vila: hi! | 21:03 |
| vila | great, I wasn't sure you was already awake :-) | 21:03 |
| mwhudson | i've actually been awake for 4 hours, but that's kinda unusual :) | 21:04 |
| vila | wow, is it 08:04 your time ? | 21:04 |
| mwhudson | vila: 10:04 | 21:07 |
| mwhudson | vila: we're utc+13 | 21:08 |
| LarstiQ | lifeless: you're listed as maintainer in ~bzr/bzrtools/packaging-dapper, but not in the other distro packaging branches | 21:09 |
| lifeless | odd | 21:09 |
| LarstiQ | lifeless: I optimistically decided to build bzrtools 1.11 for the ppa | 21:10 |
| LarstiQ | lifeless: are these packaging branches supposed to stay entirely seperate? | 21:11 |
| LarstiQ | lifeless: and should the Debian uploaders really be in there still? | 21:11 |
| lifeless | LarstiQ: I'm not entirely sure | 21:11 |
| LarstiQ | lifeless: should I bother someone else? :) | 21:11 |
| lifeless | LarstiQ: its documented in the hacking guide I believe | 21:11 |
| LarstiQ | lifeless: I'm trying to follow doc/developers/ppa.txt | 21:12 |
| lifeless | LarstiQ: ah, and its incomplete? | 21:12 |
| lifeless | LarstiQ: I'd ask the list | 21:12 |
| lifeless | poolie isn't online, nor is hjam | 21:12 |
| LarstiQ | will do | 21:12 |
| MattCampbell | kfogel: I just learned that you're working for Canonical. Given that you were one of the Subversion project leaders, I'm curious about what you think of bzr now that you've been working with it for a little while. Have you written your opinion on bzr somewhere, e.g. a blog post? | 21:46 |
| kfogel | MattCampbell: no, haven't written it up yet, and am actually avoiding that for now. I'm still very green with bzr. | 21:46 |
| MattCampbell | I know some other SVN developers have expressed concerns about DVCSes, e.g. that a DVCS makes it too easy to fork a project. | 21:47 |
| kfogel | MattCampbell: I don't think that's ever been the concern. I've heard concerns that dvcs makes it too easy to develop in isolation, which is slightly different. | 21:49 |
| MattCampbell | kfogel: Oops, yeah, you're right. | 21:50 |
| kfogel | MattCampbell: I haven't experienced that in bzr so far, I have to say. | 21:51 |
| kfogel | But then, I reflexively want to publish my changes, so I wouldn't wait for the tool to encourage it. | 21:51 |
| MattCampbell | I'm green with bzr too, so I may be wrong, but I think bzr encourages non-core developers to publish changes in a way that makes them easy to merge. | 21:53 |
| MattCampbell | especially when combined with Launchpad. | 21:54 |
| thumper | abentley: unshelve is leaving UserWarning: ProgressTask(0/3, msg='Merge phase') is not the top progress task ProgressTask(None/None, msg='') type messages | 23:12 |
| abentley | thumper: I was not involved in the progress bar changes. | 23:13 |
| thumper | abentley: ok | 23:13 |
| fullermd | There's a bug about it. | 23:13 |
| fullermd | bug 321750 | 23:13 |
| ubottu | Launchpad bug 321750 in bzr "unshelve emits "UserWarning: ProgressTask(0/3, msg='Merge phase') is not the top progress task ProgressTask(None/None, msg='')"" [Undecided,New] https://launchpad.net/bugs/321750 | 23:13 |
| igc | morning | 23:21 |
| poolie | hello igc! | 23:24 |
| * lifeless kicks off a uncapped compressbench run on bzr.dev | 23:29 | |
| jml | poolie: hi | 23:37 |
| jml | poolie: did we ever get that lp-open patch landed? | 23:38 |
| lifeless | mmm busy machine | 23:40 |
| lifeless | load average: 9.12, 8.39, 5.12 | 23:40 |
| poolie | jml: i did not | 23:49 |
| poolie | nagging will get you everywhere :) | 23:49 |
| poolie | lifeless: i think you should go ahead and send that mail about brisbane-core | 23:50 |
| poolie | but it would be good to add some kind of indicative number | 23:50 |
| poolie | with caveats if needed | 23:50 |
| lifeless | poolie: I thought you thought it was at the wrong level ? | 23:50 |
| poolie | it's still worth sending | 23:54 |
| poolie | rather than waiting to make something else | 23:54 |
| lifeless | poolie: pst'd you | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!