[00:00] How do we write a test for say qdiff? [00:01] side - by - side qdiff [00:01] and check that the systax highlighting is working? [00:01] puzzling [00:01] Obviously, you write two tests and run them side by side! [00:01] if our internal data is correct then colors should be correct [00:02] fullermd :-P [00:02] Ok - thats a very extreame case. [00:02] qlog should not be too hard - just lots of work. [00:03] garyvdm: I've installed winmerge today. it's more powerful than qdiff s-b-s, albeit lacks syntax highlighting [00:03] there is too much 3rd party diff gui tools [00:04] may be we just need ad them [00:04] On windows - I prefer Araxis Merge - unfortunately it is proprietary. [00:04] But I'm doing most of my dev on ubuntu these days - so I use meld [00:04] some people can buy proprietary soft [00:05] or crack pro^H^H^H^H^H^H^H^H^H^H^H^H^H^ [00:06] I dunno, luks rewrote qdiff s-b-s several times and we still is not perfect [00:06] garyvdm, I understand [00:07] there is one area we can do better: qann [00:07] Yes - we need to be able to select the revision you are annotating. [00:07] Go back [00:08] yes, something like this [00:08] I personally don't gannotate's ui for that though. [00:08] don't? don't like? [00:08] err - yes - don't like [00:09] I would rather have this: you right click on a revision in the revision list - and click "Annotate this revision" [00:09] I don't ran bzr-gtk for ages, I don;t remember how it [00:10] this is fine way [00:10] The revision that is annotated is highlighted in the list. [00:10] * fullermd just wishes viz would stop polluting his clipboard... [00:10] one thing that turn me mad in qt is clipboard [00:11] I'm selecting some text in qdiff, close it -- and then find that clipboad is empty [00:11] You need to go back to an older qt [00:12] err, I mean I'm copy text to clipboard but qt clear it on exit [00:12] older? [00:12] I'm using 4.3.1 [00:13] fullermd: switch to qbzr and your clipboard will be empty all the time [00:13] Are you sure - We had a discussion on the ml about it - you told me that it worked in 4.3.1 [00:14] Subject: Copy, Close Window, Paste does not work [00:14] qbzr requires qp 4 though, don't it? [00:14] Yes [00:14] yes, I'm observing this issue only in qdiff, but not in qlog [00:14] I don't have 4 around. And QT is freakin' HUGE. [00:14] (only reason I have bzr-gtk around is that I already have GTK anyway) [00:14] fullermd: windows installer is about 12MB [00:15] it's not very huge for me :-P [00:15] * fullermd doesn't own a machine that runs Windows :p [00:15] morning [00:15] good day igc [00:15] Heck, even QT 3 takes longer to build than Firefox, IIRC. Nutbar. [00:16] fullermd: so you have never tried qbzr? [00:16] that's why I prefer python tools: I don;t need to compile tem (usually) [00:16] No. I wouldn't have tried bzr-gtk if I didn't already have all the pieces but the python gtk bindings either. [00:16] I don't have any real use for it. [00:17] I don't think I've ever even fired up anything but viz, and I've only used viz recreationally. [00:17] garyvdm: I've re-read that discussion about clipboard [00:18] I have no problem with most of the q-windows, only with qdiff [00:18] only with s-b-s qdiff, because it's default [00:18] bialix: ok === mark1 is now known as markh [00:18] I suspect it's because there is different widget used [00:19] maybe something related to painting [00:19] * bialix checks [00:19] bialix: linux desktops generally have clipboard managers. I wounder if you can find one for windows. [00:20] (I note that viz resets its clipboard damage when it exits too, which makes it either better or worse; I'm not actually sure which) [00:20] wow [00:20] it looks interesting [00:20] hi bialix [00:20] it works now on win xp for black text [00:20] ian, I have question about fast-import [00:20] garyvdm: http://msdn.microsoft.com/en-us/library/ms649014(VS.85).aspx [00:21] bialix: sure, and I have a Q for you! [00:21] garyvdm: which is, its built in. You can supply the content or you can be called back. [00:21] bialix: bug 328007 - any thoughts? [00:21] Launchpad bug 328007 in bzr "UnicodeDecodeError on 'log -p'" [Undecided,Confirmed] https://launchpad.net/bugs/328007 [00:21] garyvdm: but it does not work as expected with win2k I'm using at work [00:22] * bialix looks [00:22] bialix: my simply fix breaks a fair few tests that I think you wrote so I wanted to hear how you thought we should proceed there [00:23] * bialix cough [00:23] it's tricky [00:23] honestly, I think we should have versioned properties to store encoding of files [00:24] or at least rules [00:24] lifeless: thanks [00:24] it's ideal situation I know [00:25] igc: you can't use exact on log [00:26] otherwise you have to manually encode log messages [00:27] bialix: I'm not sure I understand how encoding files/rules will help here? [00:28] igc: because then you can decode them to unicode [00:28] lifeless, do you remember the subject of your email with instructions on running bzr serve from homedir on a remote side? [00:28] *site [00:29] igc: I think to fix this issue one have to provide exact stream for log formatter but create another wrapped stream internally to log everything but diff [00:29] streaming-push alpha testing [00:29] igc: is it correct? [00:30] bialix: something like that but I have next to no idea on how to do that :-( [00:31] ok, I can try to figure it out, but I have a question about fast-import first [00:31] bialix: my knowledge in the whole encode/decode space is "just the basics" [00:31] bialix: fire away [00:32] hey igc [00:32] hi poolie [00:32] igc: I'm pleased to hear you think I'm expert in unicode, of course, I hope I can help [00:33] lifeless, jam, poolie: got a bzr-1.12 branch converted to gcchk255 yesterday [00:33] oh ok [00:33] it took 4.5 hours [00:33] igc, i'd like to set them up on orcadas [00:33] igc: I have a real need to replay some my branches and filter them in very smart way. But I need to preserve file-ids [00:33] but it's 1/2 the size!!! [00:34] jam: I've been trying to benchmark it this morning but I've been running into gremlins here and there - mostly in my setup [00:34] i had many gremlins on orcadas [00:35] jam: however, "./bzr log -r-1 NEWS" doesn't work for me on brisbane-core [00:35] the patch i sent you was really pathetically small for how long it took me to work out :-} [00:35] igc: where the code for generating diff in log lives? [00:35] poolie: what is orcadas [00:35] bialix: the machine that's http://benchmark.bazaar-vcs.org/ [00:36] bialix: the diff gets generated by calling into diff.py - the result is stored in a StringIO [00:36] you can really see in that first graph how the noise makes it hard to say straight away whether there was a meaningful change or not [00:36] poolie: your genius to choose right names for things is imressive [00:36] bialix: later on, the LOgFormatter calls a method called show_diff that tries to dump it to self.outf [00:36] bialix: is that sarcasm or not? :) [00:37] poolie: but Kergelen is a bit offensive :-P [00:37] a bit [00:37] ah ok [00:37] the naming of cat is a difficult matter [00:37] well, that one i did not choose [00:37] :-) [00:37] Orcadas Base [00:38] the worst canonical machine name (for me) is in russian actually [00:38] um [00:38] soyuz [00:38] poolie: sorry that the usertest code is pretty rough - it gets minimal love because it doesn't necessarily deserve/need more [00:38] yes? [00:38] Novolazarevskaya [00:38] poolie: well until some other por sucker tries to tweak it :-( [00:38] LOL LOL LOL LOL [00:38] s/por/poor/ [00:39] igc, i know, it's ok [00:39] ROTFL!!!!!!!!!!!!!!!!!!!! [00:39] poolie: you know the English is hard language too [00:40] i'm not sure if this is true but i've heard it means something like "New Miami Beach" [00:40] which is a joke because it's a place in Antarctica [00:41] they have a bath there [00:41] bath == warm [00:41] warm == beach [00:42] Novolazarevskaya is just a name [00:42] Novo == new [00:43] maybe it's the nickname for the place or something [00:43] soyuz is about the last part of landscape to have an obscure code name [00:43] lazarevskaya it's the beach near the Sochi [00:43] Black Sea [00:44] so yes, it's ~= New Maiami Beach [00:45] igc: so what about fast import and file ids? [00:46] bialix: its a good question! [00:46] bialix: fast-import has some support for incremental changes ... [00:47] but I feel it needs some deeper thought [00:47] at a minimuym, some better ui polish and doc on how to do it and the limitations would be nice [00:47] igc: until I saw fast-import in action I'm thinking about writing my tool for this [00:48] also, I have many failures with renames [00:48] bialix: I really need to bug Jelmer about this topic when we both have some time [00:48] some of my branches even have cyclic renames??? [00:48] bialix: please raise bugs for the rename issues [00:49] bialix: I've recently added a heap of tests for fast import, though fast-export doesn't have any yet [00:49] igc: it's occured on private branches [00:49] bialix: I know I'm still missing fast-import tests for renaming and copying directories though [00:50] I dunno how to properly write bug report [00:50] igc: 1/2 size, thats a bit disappointing [00:50] bialix: all I need is a minimal fast-import stream showing the scenario and expected outcome [00:50] igc: ok I see LogFormatter.show_diff, but who call it? [00:51] lifeless: you were expecting more? [00:51] rats [00:51] I'm back [00:51] igc: yes, various sample data goes to 1/7th [00:51] jam: probably need the byte-length encoding for gc 'i' instructions [00:51] lifeless: the other curious thing about running brisbane-core/bzr upgrade --gcchk255 was that the dirstate size went up [00:52] not by much but a bit (328 blocks to 36) - something like that) [00:52] igc: ? *blink* [00:52] s/36)/360/ [00:52] igc: how about this fix for log -p [00:53] igc: store original exact stream as self.exact_stream and use it for show_diff [00:53] bialix: show_diff is called by the ShortLOgFormatter and LOngLF [00:53] igc: did you do a full branch of the result? [00:53] igc: and wrap it as in command.py Commad._setup_outf and store as self.to_file [00:54] igc: that will get rid of some redundancy (outside a shared repo, obviously) [00:54] bialix: line 1311 of log.py is one called to show_diff() [00:55] igc: I'll write it for you. Here is just 02:56 and I'm don;t sleep anyway [00:55] bialix: legend [00:55] lifeless: I was upgrading from a pack branch - no shared repo before or after [00:55] legend? [00:56] * bialix hates chatzilla but have no better irc client [00:56] bialix: I was trying to say thnk-you very, very much [00:56] s/thnk/thank/ [00:57] lifeless: I'll upload the branch (as an archive) to orcadas - I just wanted to make sure it mostly worked first [00:58] lifeless: I've used to pb. don't see it with bzr 1.12 is hurt [01:00] igc: one downside with using exact encoding for log: output will be LF-only on Windows [01:02] bialix: yeah, I'm not sure whats going on; if it was 1.13 I'd know (because spiv and I broke it temporarily) [01:02] but I think for Windows qlog is rocks [01:03] lifeless: and I don;t see pb in qbzr too, it seems it's just disappear [01:04] bialix: does diff have the same issue? [01:04] igc: what issue? [01:05] igc: for plain diff exact is right thing [01:05] igc: but for plain log -- i'm not sure [01:05] but I can live with this [01:06] I just want to inform you abut this side effect [01:12] igc: ping [01:12] is there a way to delete a bazaar branch remotely? without logging into launchpad per se? [01:13] shtylman: there probably is an API for it in launchpadlib but i don't think there is a UI at present [01:13] poolie: thanks [01:13] igc: I have the patch for you [01:14] bialix: thanks! I'll test it later today [01:14] send it to list or to you personally? [01:15] shtylman: you could add one to bzr's launchpad plugin if you're keen [01:15] I've tested it manually only, have no desire to write unittest [01:16] poolie: well, I don't just want to be able to do it in launchpad, but for other projects as well [01:18] igc: sent to ML [01:19] perhaps I need to manage me to sleep. bye [01:34] whos bazaar for windows developer? [01:46] how does one duplicate a bzr repository to another bzr repository -- do you have to do it one branch at a time? [01:46] khemicals: I'd probably use rsync. [01:46] rsync doesn't talk http [01:47] There might be a plugin that helps, but if so, I don't remember it. [01:47] so -- there's no command I am m issing [01:47] but bzr doesn't natively support it [01:48] If it's plain HTTP, there's no way to walk the file system, so unless bzr kept a list of branches somewhere, which it doesn't, it isn't possible... [01:48] Mmm, commas. [01:48] k [01:48] it doesn't keep a list of branches? [01:49] mlh: Correct. [01:49] nowhere? [01:49] mlh: Correct. [01:49] so you can't discover branches remotely, you have to know what you want. [01:49] So, I pulled a branch from an existing public repo (just playing with bzr here to see how it goes) and tossed it into a local repo (was created using repo-init) using something akin to bzr push bzr+ssh://host/PATH_TO_REPO but now I cannot check it out since I don't know what the branch name is [01:50] There are find_bzrdirs and find_branches methods, but they just go recursing through the file system. [01:50] is there a default branch name [01:50] khemicals: ...What? [01:50] khemicals: Branch names shouldn't matter, just the specific location. [01:50] it errors [01:50] let me get the error for you [01:50] * Peng_ avoids knowing much about checkouts [01:51] bzr: ERROR: Not a branch: [01:51] and then the path thereafter [01:52] with git, for instance, I can clone the ENTIRE repository [01:53] just trying to figure out how to do the same without filesystem access to the repo I am trying to duplicate [01:53] Peng_: Why do you avoid knowing much about checkouts? [01:53] trying to figure out where I am going wrong here [01:56] khemicals: Checkouts are something extra to learn. Regular branches are usually enough for me. [01:57] what's the difference between pull/checkout/branch commands? [01:57] * khemicals reads the man I guess [01:57] Ehh, I'm not good at explaining things. [01:58] khemicals: Were you trying to "bzr branch" from a repository or checkout instead of a branch? [02:00] it was a branch since none of it worked against the repo root I don't think [02:00] khemicals: pull maintains a mirror; checkout creates a checkout - a place to edit an existing branch, branch creates a new branch (and if the target is local it can be edited in-place) [02:00] so, pull still only works against a branch though, right? [02:01] khemicals: Right. Use "update" against a checkout. [02:02] so, can I pull a branch from one repository and use push to push it to another? [02:02] khemicals: yes [02:02] do I need to create a destination branch in the repo I am pushing to first? -- or is that was export is for? [02:03] khemicals: no, push will make a branch if one doesn't exist alrady [02:03] what's the name of the branch -- the same as what I pulled? [02:03] khemicals: branches have urls, not names [02:04] khemicals: in git branches are 'refs in a repo', in bzr 'branches are directories at a url' [02:04] s/refs in a repo/'named refs in a repo' [02:04] well, the name is essentially just a subdir of the repo [02:04] so, how is that name determined [02:04] khemicals: you don't need a repo [02:05] khemicals: try it - bzr branch [some branch] /tmp/demo [02:10] bzr branch http://bazaar-vcs.org/bzr/bzr.dev bzr [02:10] so, how do I populate a new repo, that I want to share, with that content (including full history)? [02:12] khemicals: bzr branch [02:12] bzr branch bzr SOME_NEW_URL ? [02:12] khemicals: Sure. [02:13] khemicals: if you have a lot of branches, or a lot of history, you can run 'bzr init-repo URL' to create a history-sharing repository with no content, then whenever you bzr branch URL/suffix, or bzr push URL/suffix, bzr will use that repository to share branch content [02:14] khemicals: but generally most folk don't need this [02:14] the folk that do tend to be server admins and developers on projects with hundreds of MB's of history [02:22] I found my issue [02:22] in checking out the various protocols server side, I set the --directory option on the bzr daemon [02:22] it stripped too much of the path out [02:23] so it didn't match the path used by the other mechanism [02:23] thus confusing the heck out of me [02:24] but I do understand it enough to limp along now -- will keep reading, thx for the assist [02:24] khemicals: no problem [02:24] khemicals: most folk just use 'bzr+ssh://' as the protocol, which sets --directory automatically [02:25] I am just toying with all its server side functions [02:25] bzr+ssh is fine [02:25] cool [02:25] but wanted to try native bzr [02:25] protocol [02:25] as well [02:25] feel free to shout if you want any more input [02:25] you can checkout from loggerhead to? or no? [02:25] I think you can branch from loggerhead in the very latest versions [02:25] mwhudson: ^ please confirm or deny [02:26] yes you can [02:26] s/checkout/branch [02:26] wrapping head around new nomenclature that overlaps others [02:26] but it doesn't support Range:s so don't use it on anything big... [02:26] yeah, I can appreciate that [02:27] strictly speaking you could checkout from loggerhead, but it doesn't support writing back to it, so you wouldn't be able to commit -> checkout isn't that useful in that case :) [02:32] loggerhead will do bzr+http sooner or later i guess [03:06] lifeless: can you help me with a CHKInventory issue please? [03:07] lifeless: what's the way forward wrt referencing "children" of an InventoryDirectory? [03:08] it looks like iter_entries() on a chk-inventory can break because the attribute is now _children, not children, and there's a children() method on the ... [03:08] ChkInventryDirectory class but not one I can see on InventoryDirectory? [03:09] jam: ^^^ [03:10] igc: I would say we need to add one to InventoryDirectory() [03:10] we really want to be able to lazily bring stuff in [03:11] jam: ok, I'll do that and change the references to .children to .children() [03:11] jam: sound right? [03:11] sounds right to me [03:11] jam: thanks [03:12] jam: fyi, to see the bug in action, try bzr ls -r-1 on a chk branch and you'll see nothing listed [03:13] interesting [03:13] igc: btw, I just finished another improvement to chk+gc [03:13] which improves inventory compression by 50-100% [03:13] jam: sweet [03:13] I'm pushing it up now === montywi is now known as montywi|zzz [03:14] jam: is gcchk255 still the preferred format for me to be benchmarking? [03:14] igc: I need to do another round of testing myself [03:14] jam: it souded like you were leaning towards a 127? [03:14] I might also be cheating more than I realized [03:14] igc: I have to test *after* compression [03:14] it can make smaller things become bigger [03:16] * fullermd blinks. [03:17] Something went screwy with pushing multi-initial-rev branches? [03:17] * fullermd really needs to watch bugs more closely... [03:18] fullermd: apparently! [03:18] fullermd: I was surprised too. [03:19] * fullermd is extremely surprised. [03:19] A very large number (quite possibly a majority) of my branches have >1 initial rev. [03:20] I've never seen issues pushing with say a up to 1.5 version spread between my bzr.dev client and the latest-release-mod-upgrade-slack-time server. [03:20] It's only a blowup, right? Not a "gee, it worked fine, but it's gonna screw you later"? [03:20] Right. [03:21] And it's purely a client-side issue. [03:21] spiv, lifeless: question on the new stream tests [03:21] if an entry is in "Chunked" encoding [03:21] Oh, good. That leaves me with only 38,849 entries on my worry stack for today. [03:21] the "capture_stream()" fails [03:21] because "self.assertIsInstance(factory.get_bytes_as(factory_kind), str)" [03:21] groupcompress hits this [03:21] because it only talks in fulltexts/chunked (so far) [03:21] igc: so as jam says, it needs to stay lazy [03:22] igc: there is a property for children; if the property isn't working correctly there is a bug [03:22] I would guess that ultimately we want to have gc go the same route as your "knit-delta-closure" patch [03:22] igc: it sounds like something changed in bzr.dev [03:22] jam: yes, knit-delta-closure is roughly the same problem case as gc for streaming network [03:23] jam: I just haven't gotten around to it [03:24] jam: that might be a bug in the test; but generally we don't want any stream returning direct Chunked or Fulltext objects, because they don't have a small network representation [03:28] igc: for example, I expect 255-way to compress better, because you have a big top level page, and fewer intermediate pages [03:28] so even though its raw size is slightly larger [03:28] it may end up smaller post compression [03:32] * igc lunch [03:34] igc: So if you pull the latest groupcompress, you should be able to 'bzr pack' [03:34] and have it spend far too long with no progress bars [03:35] but end up with a smaller inventories [03:40] jam: so just running pack is enough? I don't need to upgrade to another format then upgrade back for example? [03:40] igc: for this, that should be enough [03:40] so in my quick test [03:41] lifeless,jam: so I missed the @property bit - make me wonder whether the bug is in the inventory building rather than the inventory lookup? [03:41] lifeless,jam: but lots of stuff *is* working [03:42] so it's not obvious to me yet where the bug is [03:42] pre-compression, gc+chk16 is 20MB versus gc+chk255 is 31MB, after compression it is 9.5MB versus 7MB [03:42] so 20MB raw => 9.5MB comp, 31MB raw => 7MB comp [03:42] which makes gc255 better [03:42] There are other factors to test, though, so I'll get there [03:43] jam: any do you expect lookup speed to be much the same? or 255 faster? [03:43] s/any/and/ [03:44] How relevant are those compression numbers, though? Aren't you still to-do delta compression or other schemata on them? [03:45] igc: smaller == less bytes to read, larger fan-out means you filter more keys per pass. So overall, I expect 255 to be better on both counts [03:45] but expect != measured [03:45] fullermd: this is one form of delta compressino [03:45] still one of the factors to be evaluated [03:46] Well. But does it have the same properties as $FINAL, though. [03:48] it should at least have *similar* properties [03:48] jam: pulled groupcompress rev 50 and kicked off that pack now [03:52] igc: So yeah, there is a property; it should work; there are tests - perhaps the input is flawed in some way. Cross checking by using iter_entries_by_dir or something might be enlightening [03:52] igc: wait [03:53] I just found a quick bug when there are signatures [03:53] I'll have a fix in just a sec [03:54] jam: ok, I'll stop it [03:54] I'll also get a quick progress on the texts done [03:55] lifeless: sure. I tried a quikc corss check using entries but it's not defined on CommonInventory, just Inventory, so I might move that up a level too [03:56] igc: when moving up just take the time to check it uses public interfaces not private attributes [03:58] lifeless: sure [04:00] igc: revno 52 is available [04:00] should give you some idea of progress now [04:00] I also noted that converting is slower than 'bzr pack', which is good [04:00] well, good that 'pack' is faster :) [04:10] jam, lifeless: so I'm closer t finding that children() bug - the "slow path" in CHKInventoryDirectory.children() gives a good result while the code after that if statement finds no children [04:13] lifeless: so here are some hard numbers for including/removing 'label' and 'sha1' sum fields. [04:14] for gc+chk255, the inventories go from 8.3MB compressed down to 7.0MB compressed [04:14] the texts go from 11.0MB => 9.6MB [04:15] or approx 107 bytes per object for inventories [04:16] and 202 bytes/object for texts [04:16] [compressed] [04:20] though interestingly enough, after a 'bzr pack', the final inventories shrunk dramatilaly [04:21] as it is now 6.5MB rather than 8.3 (so w/ labels is smaller than w/o labels) [04:22] though after 'bzr pack' the *text* size went up, 11.0MB => 11.3MB. [04:42] hm [04:43] in a test, i want to create a (local) branch, then open it over the smart protocol [04:43] what's the easiest way to do this? [04:46] nm, got something working [05:04] lifeless: I deleted your subunit/filter merge proposal and created it again so that I could blog about something more easily [05:04] lifeless: please ignore the mail :) [05:10] igc: a quick update. revno 53 drops it by another 2MB, so now 4.4MB down from 6.5 [05:11] how to undo last changes in my directory [05:12] Stanlin: "bzr revert" [05:19] lifeless: woot!. Surprisingly, changing the grouping had a much bigger impact than I expected. [05:19] thanks [05:19] By creating more groups, I'm down to 1.5MB, which is actually finally *smaller* than the knit source [05:19] (1.8MB) [05:19] I'm going to do a conversion from scratch to confirm, but it looks good so far [05:19] (raw size is identical, etc) [05:20] igc: You may want to stop it and use revno 55 [05:20] jelmer: so, it's still running [05:20] jelmer: "copying revision 1405/6696" (I killed it and restarted it at one point, in a bout of nervous fear) [05:37]