[00:00] It will run pre_change_branch_tip and post_change_branch_tip hooks if used by a 1.6 client. [00:00] pre_change_branch_tip is probably what you'd want to use to replace a pre-commit hook from SVN, I think. [00:01] I haven't quite landed the change to make it possible for pre_change_branch_tip to reject a change cleanly, but I ought to have that done this morning. [00:02] jelmer: Ah yes! This is the problem. The requirements for the bzr-svn ubuntu package are broken: bzr-svn: Depends: bzr (< 0.91~) but 1.4rc1-1~bazaar1~feisty1 is to be installed [00:02] awmcclain, bzr-svn isn't maintained in the ppa at the moment [00:02] :( [00:02] morning [00:02] it hopefully will starting 1.6 if I can get autoppa working [00:02] jelmer: ooo, autoppa [00:02] jelmer: I like the sound of that [00:02] 'morning Ian, Andrew, Martin [00:03] jelmer: What's the best way of installing? [00:03] awmcclain, You should be able to grab the package from Debian sid [00:03] for ubuntu? what's the sources entry? [00:04] awmcclain, You should be able to download it manually from the intrepid repo [00:04] jelmer: 0.4.10? Will that work? [00:05] yeah, it should. I think the dependencies are all available from either the ppa or hardy [00:05] Ok, so I'll install the dependency packages from the ppa [00:11] Hi - is it possible to set the submit_to option on a bzr branch so that people branching don't have to specify the email address when using the bzr send command ? [00:12] jelmer: Great. Works. Thank you! [00:13] mathiaz, yes - it's called child_submit_to [00:16] jelmer: well - I'd like to set in the public branch so that contributors don't have to do it themselves. [00:16] mathiaz, yes, that's exactly what child_submit_to is [00:16] jelmer: gotcha - and how do I do that ? [00:17] submit_to is retrieved from the local branch [00:17] child_submit_to is retrieved from the submit branch [00:17] mathiaz, set child_submit_to in the .bzr/branch/branch.conf of the main branch [00:18] jelmer: great - thanks :) [00:18] fullermd, Peng_: fastimport does have some limited support for incremental mirroring [00:18] jelmer: but that will be pushed to the public location of the branch ? [00:18] igc: oh yes, i want to talk to you about that at some point :) [00:19] mathiaz: how do you mean? [00:19] mathiaz, you need to set that option in the submit branch (e.g. the one you specify as first argument to "bzr send") [00:19] igc: Yeah, jam set me straight. Sorry for spouting bs. [00:19] jelmer: I'd like to setup ubuntu-doc@lists.ubuntu.com as the email address to be used to send patches for the ubuntu documentation (which is hosted in lp:ubuntu-doc) [00:20] mathiaz: launchpad doesn't make this very easy [00:20] you need to edit the .bzr/branch/branch.conf on launchpad to contain "child_submit_to = ubuntu-doc@lists.ubuntu.com" [00:20] jelmer: right - that's what I thought - I'll check with the LP guys. [00:21] mathiaz, I think you should be able to create it locally and then upload using sftp [00:21] at least that's what I did for bzr-gtk [00:21] gedit will probably work with an SFTP url... :) [01:26] igc: i think deprecating both those two apis, get_tar_file and put_on_disk would be good [01:26] they're very anachronistic there [01:27] poolie: yeah, they feel out of place [01:35] there may even be others that should also go === herb__ is now known as herb [01:49] spiv: prompted by #twisted.web [01:49] mwh@grond:bzr.dev$ PYTHONPATH=/home/mwh/src/pyflakes/support-lazy-imports /home/mwh/src/pyflakes/support-lazy-imports/bin/pyflakes bzrlib/ | grep -v 'could be lazy' | wc -l [01:49] 1239 [01:50] mwhudson: btw, the supports-lazy-imports branch seems to give duplicate warnings sometimes. [01:50] spiv: oh, hm [01:51] i know the version in hardy does [01:51] Hmm, I'm fairly sure I'm using supports-lazy-imports [01:51] (the current tip) [01:52] It's possible that I sometimes run from vim and thus side-step my bash aliases, though. [01:55] spiv: in running it over bzrlib, four lazy imports used at module level come out twice [01:55] that's all [01:55] unless my unix pipeline foo is lacking [01:56] mwhudson: Interesting. I guess I'll pay more attention and file an actual bug report next time :) [01:56] The "problem" is that it doesn't stop the tool being usefl :) [01:58] heh, 89 flakes in bzrlib/tests/test_lazy_import.py [01:58] bet most of those are false positive [01:58] spiv: the import could be lazy one is probably a mistake [01:58] it should at least be optional, or only spat out in files that already have lazy imports [02:02] ah, that cuts out 2500 flakes [02:03] Yeah, by default I wouldn't want to see those warnings for a file that doesn't use lazy imports. [02:03] * mwhudson pushes that [02:15] mwhudson: also, I wouldn't mind a way of whitelisting certain modules as ok to not lazy import. [02:15] mwhudson: e.g. I don't really care if sys "could be lazy". [02:15] spiv: you do know how much support pyflakes has for configuration, right? [02:15] Happily, no :) [02:16] "none at all" [02:16] No wonder I was so happy :) [02:16] it doesn't even take options [02:16] mwh@grond:support-lazy-imports$ pyflakes --help [02:16] Traceback (most recent call last): [02:16] File "/usr/bin/pyflakes", line 70, in [02:16] main(sys.argv[1:]) [02:16] File "/usr/bin/pyflakes", line 63, in main [02:16] warnings += checkPath(arg) [02:16] TypeError: unsupported operand type(s) for +=: 'int' and 'NoneType' [02:16] :) [02:16] Just Works is awesome. [02:17] i guess 'sys' can be whitelisted in pyflakes itself, mind [02:18] what is 'could be lazy' for? [02:20] lifeless: an import that isn't used by any code run at import time, and thus can possibly by productively changed to a lazy_import [02:21] s/by/be/ [02:21] spiv: I'm currently looking at whether we can remove lazy_import completely :) [02:21] lifeless: given that we use it to dodge circular import issues, probably not without some effort beyond just optimisation : [02:21] :) [02:28] ah yes, like bzr --no-plugins merge exploding? [02:29] spiv: keeping it for that might be ok, but actually I hit those regularly even with it [02:32] lifeless: *nod* [02:33] however, its breaks freeze,py2exe,cxfreeze,pyflakes, pydoctor etc [02:33] it doesn't make the general case faster (because code that is needed is still loaded) [02:35] It doesn't break pyflakes if you use mwhudson's branch :) [02:37] lifeless: we actually do have quite a bit of ancillary imports that don't always get loaded [02:37] like importing gpg.py [02:37] which imports subprocess [02:37] but is only used if you actually sign a commit [02:38] We could make that lazy in other ways [02:38] like by importing them in the function that uses them [02:38] we just have to be careful that those aren't in inner loops [02:47] jam: Remember that issue that you debugged on my server (AssertionError: 442 != 443). What do I have to do to work-around it? [02:47] Is upgrading bzr on the remote server the only option? [02:47] I guess I can use sftp, too...? [02:54] fbond: I thought it was a client bug [02:54] lifeless, fbond: I think you can upgrade the branch format [02:55] lifeless: I think it is caused because he is using Branch5 format branches [02:55] and the server is re-generating the history [02:55] but there is a ghost [02:55] or something along those lines [02:57] jam: sounds familiar. [02:57] bzr upgrade on the client will fix things? [02:57] The server? [02:57] bzr upgrade on the server [02:57] jam: great, thanks! [03:01] so how is the stacked branch stuff coming along? [03:05] lifeless: looking at groupcompress... you start off with 'self.lines = []', do you only add things via "compress" ? [03:05] jam: yes [03:05] I'm just wondering why you didn't special case the first compress() [03:05] since you know there are 0 matches [03:06] or would you actually match against text you have already output [03:06] I think you actually *do* self compress texts [03:06] because output_lines() updates the line_locations [03:07] ah, but you don't do output_lines until you are done [03:07] so anyway, it seems like you could trivially say [03:07] if len(self.lines) == 0: [03:07] self.output_lines(lines, [True]*len(lines)) [03:07] return [03:08] jam: it doesn't seem worth special casing [03:08] jam: as we generally get thousands of texts in a group [03:08] lifeless: well, for a 10,000 line text you skip a fairly long loop [03:08] I suppose [03:09] lifeless: how did you benchmark it? [03:09] I didn't see any direct functions here [03:09] and I have some work done for a python version of the hashtable [03:09] and thinking to extend that to a pyrex one [03:09] though customized for what groupcompress actually needs [03:09] well I didn't benchmark special-cashing not-special casing [03:10] lifeless: no, I just mean *I* want to benchmark here [03:10] and am looking for pointers [03:10] oh [03:14] jam: mailed you my hacked-up scripts [03:14] lifeless: thanks [03:15] with the ability to do 'bzr branch' I'm benchmarking branching operations nowadays [03:17] get_matching_blocks is 23% of a branch of gc itself [03:17] flush_range 10% [03:17] and output_lines 8% [03:20] stupid special keys with compize [03:20] I don't know what they are and keep accidentally triggering them [03:20] I just resized my screen [03:20] "zoom" [03:20] only I can't pan [03:21] :P [03:21] I run metacity [03:23] brb [03:26] It seems I'm hitting everything today [03:26] since when does Ctrl+Alt+Backspace reboot your machine instead of just killing X? [03:26] rotfl [03:26] I might have hit it 2x, and maybe at exactly the wrong time? [03:27] * igc lunch & doctor visit [03:29] igc: eat hardy, and feel well [03:41] jam: meh, should have shelved setup.py; pushed a new rev [03:41] lifeless: not a big deal, I already converged it with my setup.py :) [03:41] which did ~ the same thing :) [03:41] oh cool [03:42] so I have get_matching_lines up to 33% [03:42] get_matching_blocks ? [03:42] yes [03:45] jam: what are you working on, I don't want to overlap too much [03:46] lifeless: well, *right now* trying to get 'bzr branch' to actually work for me :) [03:46] ~/source/baz/btree-graphindex/bzr init-repo --gc-plain --no-trees gc [03:47] time ~/source/baz/btree-graphindex/bzr branch ~/source/baz/plugins/index2/trunk/ gc/t [03:47] I get the feeling get_matching_blocks is getting stuck in an infinite loop [03:47] lifeless: do you have a custom bzr as well? [03:47] what are you branching? [03:47] bzr.dev [03:47] that will take quite some time [03:47] is gc that slow? [03:48] ah ok [03:48] its recompressing everything [03:48] I thought it was at the point of being real-world usable and that is why you said you were testing with "bzr branch" :) [03:48] I'm working up to bigger and bigger branches [03:49] lifeless: so... I was thinking about bringing a pyrex version of the hash-table [03:49] at the moment, I've just been prototyping it out [03:49] in python [03:50] interesting [03:50] my change at least doesn't slow it down [03:51] Am I correct in determing that none of the DVCS systems support svn-like versioned properties (metadata), but bazaar ir probably the closest to having that feature? [03:51] maybe 41s versus 43s for bzrtools [03:51] probably the big win is that you don't actually need to use sets() everywhere [03:51] as a plain list is just as good [03:51] (you know you won't get duplicates because of how the line lists are built up) [03:52] djbclark: seems plausible [03:53] looks like i broke a bzr-svn repository by running "bzr uncommit" on it. i get internal errors now. any way to revert back to the committed state. then, any way to safely have bzr forget what i committed? [03:53] ah, just found http://thread.gmane.org/gmane.comp.version-control.bazaar-ng.general/40419/focus=40479 :-) [03:53] berto-, broke it how? [03:53] berto-: well, file bugs please :P [03:54] lifeless: i want to see if it's really broken first. :P [03:54] berto-: if you are getting internal errors, its a bug [03:56] jam: so - I'll work on getting the fetch order to be good [03:56] jam: as hacking on get_matching_blocks would collide with you [03:56] sure [03:56] sounds reasonable [03:58] jelmer: hmm, may not be the uncommit that broke it. i ran bzr merge on ~/.bazaar/plugins/svn and recompiled, got some error, ran make clean && find . -name '*.pyc' | xargs rm && make, and now i get an import error on from bzrlib.plugins.svn.versionedfiles import (SvnTexts, VirtualRevisionTexts[...]: File "/home/berto/.bazaar/plugins/svn/versionedfiles.py", line 18 [03:58] ImportError: cannot import name VirtualVersionedFiles [03:58] berto-: you need a newer version of bzr [03:58] jelmer: cool, thanks, working on updating [03:58] VirtualVersionedFiles is only in a recent revision of bzr.dev [04:03] jelmer: alright, working great again, thanks! [04:03] :-) [04:04] jelmer: i take it bzr uncommit now works? should i remove it from the wiki as an unsupported command? [04:04] jelmer: how about bzr push --overwrite ? [04:04] berto-: what did uncommit do? [04:05] jelmer: i ran bzr uncommit -r ; that uncommitted a directory i had added as well as some other files i had modified. it basically put the added directory back into an add state, then put the other files back in a modified state. i was then able to run bzr ci -m'[...]' [04:06] ... which just committed the added directory and left all the modified files alone. [04:06] Was that committing it back to svn as well though? [04:07] jelmer: no, all that was local, i have not committed back up to svn as it's an svn repo i don't have commit access to. [04:07] berto-, ok, so that's all unrelated to bzr-svn [04:07] berto-: then you're operating purely in bzr land :) [04:07] jelmer: ah, ok. cool. [04:07] i see, awesome. === sm_ is now known as sm [04:08] so it's trying to uncommit something that was committed in svn that's not going to work right. [04:08] [the current version of] svn has no concept of being able to uncommit, so will there ever be some sort of support for that, or is a revert mechanism as close as it gets? [04:09] it will be possible to uncommit, but it'll basically do a revert (copy from a revision in the past) [04:09] s/copy/replace/ [04:42] back later [04:46] jelmer: thanks again for the help! [04:46] lifeless: thank you too. [04:49] lifeless: holy crap [04:49] compacting all of NEWS in 'topological order' [04:49] Compressed 3213 text with 437350320 bytes to 74265451 bytes (5.89:1) in 109.994s [04:49] and in *reverse* topological order [04:49] Compressed 3213 text with 437350320 bytes to 5814355 bytes (75.22:1) in 271.026s [04:50] 75:1 versus 6:1 [04:50] bit of a difference [04:50] i also guess that this is going to be quite a slow 'bzr upgrade'? [04:50] but wow, nice numbers [04:51] mwhudson: well, I'm working on writing a C extension to improve the speed [04:51] ah right [04:51] but the 75:1 compression ratio is pretty darn good [04:52] I have the feeling it owes the most to the multi-location abilities of groupcompress [04:52] basically, it follows *all* matches concurrently [04:52] and picks the one with the longest sequence [04:52] And NEWS is rather a special case [04:52] since it is 95% insert-only [04:53] jam: yeah, i guess builtins.py is another obvious one to try [04:54] mwhudson: running it now [04:54] :) [04:54] forward: Compressed 1837 text with 210568735 bytes to 38663891 bytes (5.45:1) in 80.498s [04:54] mwhudson: builtins.py was the one I used for my xdelta testing [04:55] ah right, i remember now [04:55] though it had only 1300 texts, IIRC [04:56] reverse: Compressed 1837 text with 210568735 bytes to 21061973 bytes (10.00:1) in 76.862s [04:56] Don't trust the times completely, as I'm poking at the code while waiting :) [04:56] heh [04:56] less spectacular [04:56] less spectacular, but 2:1 for going in reverse versus forward [04:56] and faster in reverse [04:57] bob2: well, as I said, I poked at the code in there, so maybe, maybe not [04:59] also [05:00] is that the raw output or the gzipped? [05:00] lifeless: raw [05:00] yah [05:00] thought so :) [05:00] but now you see why I think this has legs :) [05:00] lifeless: does that normalize a bit more? [05:01] jam: its the gzip phase takes the reverse output below git in size [05:01] is gc similar to how git does packs? [05:01] bob2: git does xdelta compression [05:01] gc is a different algorithm [05:01] the idea of --reverse versus --forward is somewhat taken from git [05:01] jam: oh, it *does* do xdelta? [05:01] lifeless: yes [05:01] I'm not sure if it is xdelta 1,2,3 [05:02] but xdelta [05:02] at least, that is what I remember [05:04] lifeless: interestingly, sorting by text size [05:04] is slightly better for group-compress [05:04] (without gzip) [05:05] rather than reverse topological [05:05] jam: as expected; though we don't cache size at a good place to use for this [05:05] at least, in my 2 trivial tests [05:05] lifeless: strictly because it gives more locations to match ? [05:05] yes [05:05] well [05:06] because it can encode longer sequences [05:07] lifeless: you may be interested in lp:~jameinel/+junk/test-groupcompress [05:07] You may not [05:07] but it provides direct GC testin [05:07] testing [05:08] by extracting the texts from the ancestry of a supplied file [05:08] and --lsp filename.callgrind will profile *just* the GC operations [05:15] hey guys, I deleted directory foo in commit 560 but also a whole bunch of other stuff that I don't want. How can I bring back just directory foo? [05:17] sohail: bzr revert -r 560 foo [05:17] lifeless, ah! [05:17] * sohail tries [05:18] lifeless, "ERROR: Path(s) are not versioned: foo" [05:23] sohail: oh :( [05:24] sohail: try -r 559 ;) [05:26] lifeless, I did bzr merge -r560..559 aka svn :-) [05:26] but what I really want to do is bzr cp foo@559 dir/foo [05:26] but I can't figure out how to do that [05:27] sohail: well, merge -r560..559 foo should work [05:28] lifeless, yeah that worked [05:28] sohail: revert -r 559 foo should have worked too [05:28] (clearly -r 560 can't as foo doesn't exist there :p) [05:29] lifeless, trying now [05:31] lifeless, you were right, it worked === samurai_ is now known as samurai [05:33] in the star trek universe, the person who figures out how to transport with shields still up will win the nobel prize [05:48] bzrlib.tests.blackbox.test_info.TestInfo.test_info_standalone in bzr.dev is failing for me. [05:48] File "/home/andrew/code/bzr/bzrlib/tests/blackbox/test_info.py", line 158, in test_info_standalone [05:48] bzrlib.upgrade.upgrade('bound', knit1_format) [05:48] AttributeError: 'module' object has no attribute 'upgrade' [05:49] spiv: funky [05:50] spiv: and does it? [05:51] lifeless: [05:51] $ PYTHONPATH=. python -c "from bzrlib.upgrade import upgrade" [05:51] $ [05:51] Hmm. [05:53] circular imports again? [05:53] Ah. [05:53] It's the 'bzrlib' object that lacks the 'upgrade' attr, not the 'bzrlib.upgrade' object. [05:54] i.e. there's a missing "import bzrlib.upgrade" [05:54] oh hee [05:54] it makes a difference whether you selftest [05:54] or selftest -s [05:54] Yeah. [05:54] Which is why I couldn't reproduce it with 1.5: I couldn't use -s :) [05:55] * spiv fires off a trivial fix. [09:00] hi, I've just read quickly through the bzr user guide, but couldn't see an example of how to make a topic branch. How do I do this? [09:00] bzr branch A B? [09:01] what's A and what's B? [09:01] as in, which is the trunk? [09:01] A is the original branch, B is the branch you want to create [09:01] A [09:02] thanks [09:05] Just trying to get my head around bazaar after using Git for a while. So if I do "bzr init repo" and then "bzr branch repo repo2", do I then have two full repositories? [09:06] Kindof. [09:06] Stumbles: there's some terminology differences with Git that confuses things a little. [09:06] bzr makes a distinction between things that are conflated in git. [09:07] * RAOF leaves it to the more knowledgable spiv [09:07] Stumbles: you have two branches, each with a full copy of history in them. (And so if you haven't done other set up to avoid this, you'll be using twice as much disk space as if you only had one branch). [09:08] Stumbles: "bzr init" creates a what we call a "branch". [09:08] Stumbles: "bzr init-repo" creates what we call a "shared repository". [09:09] Thanks, this is a great help. So the way to go is "bzr init-repo myrepo", "mkdir myrepo/trunk", "cd myrepo", "bzr branch trunk mytopicbranch"? [09:10] Stumbles: so for comparison, if you did "bzr init-repo repo", then "cd repo; bzr init branch-one; bzr branch branch-one branch-two", you'd have two branches inside one shared repository. [09:10] Stumbles: right, except "bzr init myrepo/trunk" rather than "mkdir myrepo/trunk". [09:10] lovely [09:11] ok, right [09:11] and that way the second branch doesn't take additional space until I change files? [09:12] Right. [09:13] The two branches will use the same storage for their revisions. [09:13] ah right, I see, shared repository, but two full working copies [09:14] shared history i mean [09:15] thanks spiv, much appreciated [09:16] you can have just one working directory, but then it gets a little complicated [09:16] Stumbles: you're welcome [09:32] so if you were doing lots of short-lived branching, say one or two commits before merging with the main line, a shared repository would definitely be the way to go, right? [09:33] Stumbles: yep === weigon_ is now known as weigon [09:39] if not using a shared repository, what would the difference be between "cp -r original branch" and "bzr branch original branch"? [09:41] Stumbles: Since it actually access the repo, it would somewhat verify that it isn't broken. It won't copy working tree modifications and unversioned files. [09:43] thanks [09:43] accesses* [09:44] Even without doing lots of short-lived branching, you probably want a shared repository anyway. Pulling other people's remote branches is orders of magnitude faster when you pull them into a shared repository which already contains most of the history. [09:46] And the way that I use bzr, pulling other people's branches is by far the slowest operation, so a shared repository makes a lot of difference. [09:51] thans RAOF === yacc__ is now known as yacc [10:07] hi [10:08] KnitCorrupt: Knit text:x_Matt_Zimmerman__Sun_Mar_13_00:51:19_2005_1366.38 corrupt: line-delta from stream for version mdz@mizar-20051205230117-c327e75be767f237 references missing parent Arch-1:matt.zimmerman@canonical.com--2004%casper--main--0--patch-21 [10:08] oh, the late wrath of arch... [10:08] I get that when trying bzr get lp:~ubuntu-core-dev/casper/trunk casper [10:08] any idea what I can do to debug/fix this/ [10:08] ? [10:22] hi pitti [10:22] in the meantime I found some pointers to that [10:22] I've heard rumblings about the casper branch. [10:22] bug 246880 and https://answers.launchpad.net/launchpad-bazaar/+question/39693 [10:22] Launchpad bug 246880 in bzr "Can't branch casper which misses some parents in old revisions" [Undecided,New] https://launchpad.net/bugs/246880 [10:23] I'm working on it [10:23] mdz still has the old branch kicking around [10:24] so I'll fetch the ghosts [10:24] pitti: no point you working on this simultaneously :) [10:24] right, I just started asking here [10:24] cjwatson: thanks [10:24] though first I have to remember how the hell to mirror an archive using baz [10:25] recycled neurons FTW [10:25] I might still have it in the REAME.Developers of postgresql-common in an ancient revision [10:25] it's OK, I've got far enough to remember the basics [10:26] ouch [10:27] * pitti reads about make-archive, register-archive, branch, get, and gets painful memories [10:27] "27 easy steps to check out a branch" [10:38] * Kinnison giggles [10:38] * Kinnison has utterly evicted that knowledge from his head too [10:39] hey Kinnison, how's life? [10:39] busy and full of windows, poorly written packet sniffers, and embedded RF microprocessors [10:39] yay hardware development :) [10:40] indeed [10:40] * pitti was happy about the atmel toolchain back then, which ran fine under linux [10:40] In this instance, I'm trying to work out why a three-byte payload packet ends up doing around 8 packets, comprising around 200 bytes over the air [10:40] mmm 802.15.4+ZigBee2004 [10:41] Kinnison: hi! TLNS [10:41] err, ^T [10:41] * Kinnison grins [10:41] * Kinnison is usually around :-) [11:37] hi! I'm having a problem. a developer branched my repo, worked on something, created a bundle with "bzr bundle" and send it to me.. I worked on my branch too... Now everytime I want to merge his bundle "bzr merge file.bundle" I'm getting an error "Revision {('dev mail address-foo bar',)} not present... [11:38]