[00:34] Hi [00:35] Isn't "bzr pack" supposed to reduce the size of .bzr, and not to double it? http://paste.ubuntu.com/215878/plain/ [00:36] Or is it keeping an uncompressed backup around or something? [00:43] RainCT, you need to clean the old packs [01:50] bzr revno file:///d:/Programação/Utilidades/csvt.rb [01:50] bzr: ERROR: Unsupported protocol for url "file:///d:/Programa├º├úo/Utilidades/csvt.rb" [04:13] lifeless: I've integrated bzrlib.commands.Command and Command.hooks into Commandant and I have all the tests passing! [04:14] lifeless: There's still more tests to write and I'd like to do some cleanup. Thanks a lot for the Command.hooks refactoring, it's really working well for me. [07:10] EOL filter doesn't work in bzr, is there any plan on it? === ddaa1 is now known as ddaa === tro|| is now known as tro === tro|| is now known as tro [15:35] how interested are you guys in hearing about crazy (but real world) comparisons between 2a and 1.14-rich-root? [15:37] faceprint: rather [15:39] I'm moving my development team off of CVS to bzr later this month. The repository dates back to 2003, and I've used tailor to create and keep up to date a bzr mirror of the CVS repository. I've got about 30k revisions of about 10k files. [15:40] faceprint: that's a nicely sized tree [15:40] I've got code files that have between 1 and a few hundred revisions, typical development commit patterns, and then some data files that are less-than-ideal for an SCM. One example has 220 revisions, about 400k lines, and weighs in at about 10 MB [15:41] right [15:41] I've been trying to benchmark this repo 6 ways from sunday so I can be prepared for any complaints from my teammates [15:42] on a 1.14-rich-root copy, that big data file takes 5:30 to annotate, and chews up about 1.8 GB of memory in the process [15:42] ouch [15:42] faceprint: which version of bzr is that with? [15:42] 1.16.1 [15:42] ok [15:43] * LarstiQ looks up when jam's annotate-for-big-files changes landed [15:43] 2a has been running for 30 minutes so far, and I think it's up over 6 GB of memory [15:44] this is the first thing i've seen "worse" on 2a, thought you guys might like to hear about it [15:44] hi [15:44] faceprint: certainly! [15:44] is there a way to bypass aliases for automation? [15:45] faceprint: could one of the core devs experiment with a copy? [15:45] LarstiQ: unfortunately that's out of the question. very private repo. [15:46] Raim: --no-aliases? [15:46] but if you can tell me which "dimension" of absurdity to go in, I might be able to try and recreate something similar that exhibits the behavior [15:47] faceprint: I think jam or igc would be better suited to give you that feedback [15:47] LarstiQ: yeah, was looking for that exactly. thanks :) [15:47] Raim: lifted from `bzr help global-options` [15:47] Raim: now, if you're doing automation with python and bzrlib, the answer would be different :) [15:48] faceprint: are you subscribed to the mailing list? [15:48] LarstiQ: not yet. i've been reading archives all weekend ;-) [15:49] LarstiQ: no, it's about shell automation. I ran into a problem as I aliased "bzr diff" to "diff --using 'colordiff -u'" and then patch naturally chokes on the color codes [15:49] faceprint: since a post about this to the list will get more exposure than irc when most core devs are not working :) [15:49] Raim: right [15:50] LarstiQ: is it relatively easy to grab bzr.dev and use it w/o touching my regular install? [15:50] Raim: how about `bzr cdiff` from bzrtools? Doesn't it do terminal detection? [15:50] faceprint: yes, very [15:50] faceprint: since bzr runs from source, no installation required, just invoke the right binary [15:51] excellent. i'll give that a whirl and see what kind of results I get. [15:51] faceprint: you will want to make sure the C extensions are built for performance, but that can happen inplace [15:51] just run `make` and install the dependencies (pyrex, python-dev and a C toolchain afaik. Oh, libz-dev perhaps [15:52] faceprint: do I understand it correctly that your 1.14-rr is based on a continual tailor conversion? [15:53] LarstiQ: I think I tried that, but it had problems in combination with bzr-pager [15:53] Raim: ah [15:53] Raim: sounds like something to fix :) [15:53] Raim: if you can tell me how to reproduce it, I can file a bug [15:54] correct. it syncs the CVS once an hour to a 1.14-rr that is bound to a server with a rich-root-pack repo (because I can't upgrade that copy of bzr yet) [15:54] LarstiQ: this one, https://bugs.launchpad.net/bzr-pager/+bug/329845 [15:54] Ubuntu bug 329845 in bzr-pager "Incompatibility with diff from bzrtools ('DiffWriter' object has no attribute 'isatty')" [Medium,Fix committed] [15:54] * LarstiQ sits back as other people file bugs ;) [15:55] Raim: also seems like luks merged the fix [16:25] LarstiQ: FYI, bzr.dev on the 1.14-rr was twice as slow as 1.16.1. I'm running it on 2a now. [16:26] faceprint: specifically annotate on that large file? [16:26] crap, I forgot about running make. that's probably not valid results [16:27] valid if you want pure python, but slower :) [16:28] i'll wager that my 1.16.1 deb has the C extensions, so not apples to apples at the very least [16:32] wow, big difference. bzr.dev much faster on that repo now. 1:02 vs 5:28 with 1.16.1 [16:33] Yeah, there's some new stuff with annotate since then. In the last few days, actually. [16:36] 2a is much better as well: 2:32 vs (did not finish) with 1.16.1. and it ended up using a few hundred MB, vs 6 GB with 1.16.1 [16:36] are those speedups destined for 1.17, or a later version? [16:37] They'll be in 1.17 I'm pretty sure, it hasn't branched yet. [16:37] (always barring bugs being found that call for backing it out prior to that of course) [16:38] naturally === abeaumont_ is now known as abeaumont === thekorn is now known as THEKORN [18:57] Is it possible to have shelve give me a move granular choice. It's groups some changes together. [18:57] s/move/more [18:57] garyvdm: as opposed to? [18:58] It groups some of the changes together. [18:58] I want to shelve only some of them, [18:58] garyvdm: in one hunk you mean? [18:58] garyvdm: ie, you want hunksplitting? [19:00] LarstiQ:http://paste.ubuntu.com/216364/ [19:00] I want to shelve the refresh button code. [19:00] but not the larst change. [19:01] garyvdm: yeah, hunk splitting [19:01] Ok [19:01] garyvdm: which would be very cool to have [19:01] I would think that those are different hunks... [19:02] anyway === THEKORN is now known as thekorn [19:02] garyvdm: right, but the diffing algorithm didn't [19:02] garyvdm: so that is where you as a human could come in to augment the algorithm [19:03] LarstiQ: from my understanding of the term hunk - the diffing algorithm would think that those are different hunks. [19:05] garyvdm: they're both in the same set between @@' right? [19:05] Yes [19:05] those are the hunk delineators [19:06] Ok [19:06] gnu diff has some options to make it try harder to make the hunks smaller [19:06] don't know about patience diff [19:07] garyvdm: all a long way of saying, afaik you can not easily do that right now [19:07] garyvdm: but I'd really like to be able to :) [19:24] hi [19:24] i'am completely new to a vcs and bazaar. i've read the user guide but having some problems to understand some things. [19:26] i'am developing a software that is hosted on sourceforge and want to use the bazaar service there. I'am the only developer there so i need the repo so users can get the latest source code. [19:26] so the first thing. i did [19:26] bzr init [19:26] bzr add [19:26] bzr commit -m "blabla" [19:27] bzr push ... [19:27] now i get a message [19:27] "This transport does not update the working tree of: bzr+ssh://christianrapp@tv-viewer.bzr.sourceforge.net/bzrroot/tv-viewer/. See 'bzr help working-trees' for more information. [19:27] Created new branch." [19:28] what does this mean? when i did some changes to the code. how do i update the repository on sourceforge? using bzr push? [19:29] saedelaere: yes, using bzr push [19:29] saedelaere: I wonder why youget that message though [19:29] saedelaere: how did the branch at .../tv-viewer/ come into existance? [19:30] bzr should only say that if there is a working tree present, which there is no need for [19:30] Well, presumably by that push, since it said 'created new branch'... [19:31] fullermd: then why does it mention updating a working tree? [19:33] should i have done this first? [19:33] bzr init-repo --no-trees sftp://centralhost/srv/bzr/PROJECT [19:33] and then continue like this? [19:33] http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#publishing-a-branch [19:33] saedelaere: not per se [19:34] saedelaere: it will consume less storage and be faster if you use multiple branches, but other than that no difference [19:34] branch, working-trees puhh still not understanding completely :) [19:34] ok then i've done nothing wrong [19:35] like i said i need the repo on sourceforge only so users can get the latest source code [19:35] No - people will still get a working tree when they pull [19:35] I would think that is a bug with the hosting. [19:35] *think* [19:35] garyvdm: are you seeing someting I'm missing? [19:36] LarstiQ: I'm baseing that on a big assumption. Let me just somthing. [19:36] sure [19:40] ok one more thing. when i ever find someone who whants to contribute and is also allowed to write to my repo, how do we keep our work synchronized? bzr merge "path_to_my_repo_on_sourceforge", will this command add all changes to my local repository? [19:41] LarstiQ: my assumption was wrong. So the branch with working tree must have been created before the push? [19:42] saedelaere: Yes [19:42] garyvdm: I don't really understand what is going on, lack of information [19:42] saedelaere: that will work [19:43] saedelaere: and if someone else who does not have permissions to you trunk branch on sf, they can push there changes to another branch sf, and you can merge from that branch. [19:44] This is one of the big wins for Distributed VCS. [19:44] or you can even use `bzr send` and email the commits [19:45] saedelaere: If you get the "can't update remote wt" error in future... [19:46] You need to get on of the sf admins to do "bzr remove-tree BRANCH" on the server. [19:47] if you can access it with bzr+ssh, you can do it yourself [19:47] Oh [19:47] * fullermd isn't sure that follows... [19:48] LarstiQ: bzr: ERROR: You cannot remove the working tree of a remote path [19:48] garyvdm: I was thinking of hitchhiker [19:49] but you are right, that is more manual than `bzr remove-tree` [19:49] hitchhiker? [19:49] which I guess is not a good idea for non-experienced people [19:49] What is hitchhiker? [19:49] garyvdm: lp:hitchhiker, an ftp like client based on bzr's transports [19:49] ok [19:50] It's sorta a manual shell on the bzr protocol. [19:51] I understand why we can push to a remote wt, but would it not be easy to code bzr to remove a remote wt? [19:52] s/can/can't [19:53] garyvdm: not entirely [19:53] garyvdm: you need to check for unknowns [19:53] Oh - right [19:53] garyvdm: you are right that we don't have to do conflict merging, so no getting of the content [19:54] so at a minimum one extra listdir [20:05] ok i just pushed my second revision and the error did not appear again. [20:05] thanks for all your help and hints. oh and great tool. really easy to use. I also tried svn but that was much to complicated. [20:06] saedelaere: good to hear :) [20:37] i do a commit with [20:37] bzr commit -m "foo" [20:37] now i want to add several different messages to this commit [20:37] bzr -m "foo [20:37] bar [20:37] baz" [20:37] seems not to be possible to split the message into several lines. Correct? [20:38] saedelaere: incorrect. But if you use -m it depends on your shell being able to handle it. [20:38] saedelaere: I use zsh and there it works. [20:39] saedelaere: alternatively, don't use -m and just let the editor come up, or write a commit message to file and use -F [20:39] saedelaere: see `bzr help commit` [20:39] ah thats a good idea, thanks :) [20:47] saedelaere: There also guis available. [20:47] bzr qcommit from qbzr [20:47] or bzr gcommit from bzr-gtk [20:48] On windows - qbzr comes with the installer. [20:51] i wanted to learn bazaar from the scratch so i started with the terminal. perhaps later i will try a frontend [21:54] moin [21:55] jkakar: glad you like it ;) I did it to tease apart bits of bzrlib mainly. Still its very nice that its found external love as well. [21:56] lifeless: It's awesome, getting takes_args and takes_options for free is worth a lot. :) [21:57] lifeless: I'm using run_bzr to run the commands and that's working pretty well too. [21:57] lifeless: At some point I'd like to see if there's a way to make use of the bzrlib.help_topics stuff. Right now I'm using my own code, but using Command.get_help_text to generate verbose output for commands. [21:58] jkakar: have you seen bzr-guess? [21:58] lifeless: Nope. [21:59] It was one of the things I had in mind with the hooks ;) [21:59] you might like to load that particular bzr plugin in commandant [21:59] lifeless: That is creepy. :) [21:59] (import bzrlib.plugin; bzrlib.plugin.set_plugin_path(); import bzrlib.plugins.guess) [22:00] jkakar: ? [22:00] lifeless: bzr-guess, that is. :) [22:00] why creepy? [22:00] lifeless: Hmm, I guess I'd also need to register a function for "get_missing_command" to look at plugins. [22:01] lifeless: Right now I implement hooks for "list_commands" and "get_commands" and leave the rest in their default unbound state. [22:01] no; get_missing_command is one of the three hooks we provide [22:01] bzr-guess hooks get_missing_command [22:01] but it only depends on list and get [22:01] Ah ha, I get it, nice. [22:02] * saedelaere zzz [22:25] jelmer: hi? [22:32] mwhudson: iirc jelmer is on a 4-day trip atm [22:32] LarstiQ: ok [22:33] mwhudson: yeah, at oxegen.ie [22:59] spm, hello. [23:01] jml: howdy! [23:01] spm, I need to release a new version of Bazaar, and I need you to help me [23:01] jml: your wish is my command :-) [23:02] spm, can you please make a pqm managed branch for 1.17? [23:03] jml: sure. one sec or three [23:03] spm, thanks [23:11] jml: that should be all systems go for 1.17 [23:11] spm, thank you! [23:12] * jml trundles off to a leisurely breakfast where bzr may in fact be released [23:13] jml: bzr v1.17 "Coffee & Danish" ? [23:13] spm: Sounds better than KFC! [23:14] spm, "So late it's brunch", more likely [23:14] jpds: for breakfast? KFC? blurg. :-) [23:14] jml: not... optimistic enough imho :-) [23:15] oh well, I'll have plenty of time to think about it on the way to crows nest :) [23:15] "So late it's brunch" - Ha Ha +1 [23:21] jml: are you still on leave? [23:33] morning [23:33] igc: hello [23:36] hi mwhudson! [23:38] igc: i still need to reply to that mail about bzr-svn [23:38] but basically i think we need to talk to jelmer a bit [23:39] Hi igc [23:39] mwhudson: cool. I have 800 emails to start the day so I'm not missing it. :-) [23:39] hi garyvdm [23:40] garyvdm: it looks like jam has been playing with Qt tree models. Is he aware of your stuff yet? [23:40] I don't know. [23:40] igc: What's jam doing? [23:42] garyvdm: not sure exactly - fixing bugs maybe? [23:42] garyvdm: https://code.edge.launchpad.net/bzr-explorer [23:59] igc: lp:~jameinel/bzr-explorer/wt_model very much duplicates the work I've done. - I'll send jam an email. [23:59] garyvdm: thanks