[00:06] davidstrauss: I think one of the Canonical folks is in charge of it, not sure who. Probably best to mail Martin [00:06] jelmer: Can I get Martin's email address? [00:07] davidstrauss, If you're a bzr contributor you should know that already :-) [00:07] jelmer: I've been posting a bunch about Bazaar and Drupal on my company blog, and I'd like it to find its way into the Planet. [00:08] jelmer: I'm a Drupal infrastructure team member, and we use Bazaar for a number of projects. [00:08] davidstrauss, What's the URL of your blog? [00:08] jelmer: If you only want to see Bazaar-related posts, http://fourkitchens.com/tags/bazaar [00:16] jelmer: Thanks. I've emailed him. [00:55] svn-to-bzr question [00:56] I have a svn repo that I'd like to import a sub-project into bzr [00:56] i.e. I want to import /trunk/project into its own bzr repo, but svn-import seems to only want to pull the entire repo in [00:56] is this possible? [00:57] I've split apart the svn repo with svnadmin dump/load so that I re-import only /trunk/project into a new repo, and import that, but I still wind up with reponame/trunk/project as the bzr structure which is cumbersome [00:57] I'd like to wind up with a bzr branch just called project/ as the root of the new brach [00:57] (I could just take an export and import into a new bzr, but I'd like to keep revision history if possible) [01:02] hi ledge [01:02] ledge: You can use "bzr branch

" [01:04] does that bring down revision history with it? [01:04] (I'm pretty much a bzr noob right now) [01:04] ledge, yes [01:05] well [01:05] that's pretty easy then [01:05] :/ [01:05] thanks. :) [01:06] I was sure I had to go through svn-import somehow... [01:06] there it goes, it's working. yay! [01:54] Hi. I have bzr 0.11.0. How do I bzr branch lp:liveusb? [01:55] KragenSitaker: `bzr branch lp:liveusb` [01:55] :) [01:55] it complains, "bzr: ERROR: Not a branch: /home/kragen/devel/lp:liveusb/" [01:55] KragenSitaker: ah 0.11 [01:55] :( [01:55] sorry [01:55] you should upgrade bzr [01:55] I assume "lp:liveusb" is short for some longer URL? [01:55] KragenSitaker: it is [01:55] KragenSitaker: you have an ancient bzr [01:56] well, in a way, that's what I'm trying to do --- by virtue of installing a new OS [01:56] what URL is it short for? [01:56] pretty much all of my software on Debian Etch is ancient [01:56] http://code.launchpad.net/liveusb should work I believe [01:56] thanks! [01:57] james_w: I'm not so sure [01:57] https maybe [01:57] hey thumper [01:57] KragenSitaker: http://bazaar.launchpad.net/~probono/liveusb/main [01:57] KragenSitaker: that is the long name for lp:liveusb for reading [01:57] thumper: awesome, thanks! [01:57] hi james_w [01:58] KragenSitaker: however [01:58] KragenSitaker: you won't be able to read it [01:58] KragenSitaker: with 0.11 as the format is packs [01:58] :( [01:58] KragenSitaker: which needs at least bzr 0.92 [01:58] KragenSitaker: can you install a later bzr? [01:58] this is stupid. why can't probono make tarballs? [01:58] I'm trying to install Ubuntu! [01:58] heh [01:59] which includes a current bzr [01:59] ubuntu is easy to install [01:59] KragenSitaker: check http://bazaar-vcs.org for Debian debs [01:59] well, liveusb sounded the easiest of the options on https://help.ubuntu.com/community/Installation/FromUSBStick [02:01] KragenSitaker: http://backports.org/debian/pool/main/b/bzr/ (debian backports) [02:01] oh, that's probably an easy enough solution [02:01] KragenSitaker: for my installs I normally just burn a cd [02:04] thumper: yeah, I have a burned CD, but the new machine doesn't have a CD drive [02:04] KragenSitaker: ah [02:07] I figured a USB key cost about the same as a CD drive and would be more useful [02:08] I wasn't counting on having to update my backports GPG key ring in order to install an updated version of bzr in order to download a third-party utility to make the USB key bootable [02:08] I thought it was something on the CD, or at least a tarball on the web [02:08] sorry for the rant [02:08] and thanks for the help! [02:11] :) np [02:12] I'm off to install [06:59] Does anyone know what the hold up with bzr >1.5 is in Debian sid? [07:21] cammoblammo: Debian is the hold up. I thought it was common knowledge how slow Debian updates. [07:25] Toksyuryel: I know Debian can be slow, but other packages seem to get in within days of upstream release. Every version since 1.6 has been in experimental, but I don't seem to be able to put my finger on why none of them have been moved to sid. [07:38] bzr has been releasing like once a month. they might be waiting for it to settle down a bit [07:40] Toksyuryel, nothing wrong in once-per-month release cycle [07:53] And hasn't it been that way a while anyway? === Mario__ is now known as pygi [08:18] pygi: never said there was anything wrong with it. just said that they might be waitinng for it to settle down a bit. I don't know. I don't use Debian. [08:20] Toksyuryel: the intersection between debian developers and bzr developers is not empty, so that's probably not the case :) [11:45] If I set up a branch in a repository, but the branch has different permissions than the repo (write access for someone else), will commits to that branch work? [11:52] Apparently not. I guess that's what stacked branches are for. === beaumonta is now known as abeaumont === cprov is now known as cprov-afk === fawek_ is now known as fawek === thekorn is now known as thekorn1741 === thekorn1741 is now known as thekorn === [1]joergbw is now known as joergbw [17:05] how do I programatically get the location of a bzr repository clone? [17:07] jezdez: The location of a clone after it's been made? [17:07] not sure I follow [17:11] jelmer: sorry, I wasn't very clear :) I mean the location of the original repository [17:11] jezdez, generally, repositories are not cloned but branches [17:11] for the location of the parent branch, see Branch.get_parent() [17:12] right, that's just me confusing the terms in the different dvcs :) [17:13] is there a way to get that information through the bzr command? [17:14] There's at least "bzr info | awk" [17:14] Lo-lan-do: indeed, that's what I've been using until now [17:15] hi! [17:16] When I push to a remote server and then use bzr diff on the remote machine to see the difference between the last commit and the working tree, it doesn't return any differences. [17:17] Does this sound right? [17:17] isr: You need a bzr update on the remote machine, I think. [17:18] isr: Actually, probably not. I think I read what you want to do backwards. [17:19] Lo-lan-do: I do a bzr update to get the tree up to date, but before that I do a bzr diff to see what was changed, cause the working tree is out of date [17:19] I see. Then my answer is the wrong one, sorry. [17:20] Lo-lan-do: I would expect to see the differences of the last commit and the tree, or even a "tree is out of date" text [17:20] And I don't know the right answer, either. [17:20] Lo-lan-do: Thanks anyway [17:28] If my submitted [MERGE] request is in Bundle Buggy already, should I poke on the list if I don't see any action (either positive or negative), or just wait? Not sure what the standard procedure is. [17:28] It's been in there a few days. [17:28] kfogel: just wait normally [17:28] james_w: ok, thanks [17:28] there are plenty of merge requests :-) [17:28] yes, I imagine so :-) [17:29] feel free to poke if it's blocking something, or it's been to long I believe [17:29] unfortunately I can't vote, so I can't help I'm afraid [17:35] how would I get the parent branch of a checkout? [17:36] try "bzr info" [17:37] programmatically [17:38] You could check how "bzr info" is implemented. :D [17:38] bzrlib.builtins.cmd_info [17:39] jezdez, you mean the master branch of a checkout? [17:40] jelmer: yes [17:40] Peng_: thanks, that's a good pointer [17:40] jezdez: I think it's just Branch.get_master_branch() [17:41] you mean BzrBranch.get_master_branch()= [17:41] ? [17:41] yes [17:42] well, BzrBranch is the implementation [17:42] Branch.get_master_branch() is the interface [17:45] oh, I see [17:45] the formats [17:46] maby I should just parse the command line output :P [17:47] in case you wonder what I'm trying to do: I'm adding bzr support to pip === k4v is now known as m4v [17:49] jezdez: Branch.open("/path/to/branch").get_master_branch() should do it [17:57] hi davidstrauss [17:57] jelmer: hi [18:24] Is it possible to search for a string across all files in all of the revisions in a branch? [18:24] (need to locate if the string ever existed) [18:24] vadi2: Maybe use bzr-search? [18:24] jelmer: awesome, that works. [18:25] Peng_: I don't have such a command [18:25] vadi2: It's a plugin. [18:27] Anyway, yeah, bzr-search can totally do that. [18:29] it seems 8.10 does not has a package for it. I'll try the bzr stable ppa [18:29] (it does appear in 9.04 repository though) [18:30] It's not in the PPAs. [18:30] That's cool that it'll be in Jaunty though. :) [18:30] Oh. that's dissapointing [18:32] You can just "bzr branch lp:bzr-search ~/.bazaar/plugins/search" or something. [18:35] heh: http://paste.pocoo.org/show/100279/ [18:37] Peng_: I branched, but it says the following: "Unable to load plugin 'search' from '/home/vadi/.bazaar/plugins'" [18:40] * Peng_ dies [18:41] I guess this is why they invented apt. :P [18:41] Guess so. What to do? [18:41] Oh. [18:42] You may have put the plugin itself in ~/.bazaar/plugins/search/trunk or ~/.bazaar/plugins/search/search or something, instead of ~/.bazaar/plugins/search. [18:42] No, it is proper [18:42] http://paste.pocoo.org/show/100280/ [18:42] Oh, 100,000 pasts. Congrats pocoo. :) [18:43] Yeah, I like their pastebin. [18:43] Is there a traceback? Perhaps in ~/.bzr.log? [18:43] * Peng_ doesn't understand why bzr-search wouldn't work. Old bzr version maybe? [18:44] That file is huge [18:44] I'll delete it and try the command again [18:45] this is a debug log for diagnosing/reporting problems in bzr [18:45] you can delete or truncate this file, or include sections in [18:45] bug reports to https://bugs.launchpad.net/bzr/+filebug [18:45] 0.597 encoding stdout as sys.stdout encoding 'UTF-8' [18:45] 0.614 bzr arguments: [u'search'] [18:46] Oops [18:46] http://paste.pocoo.org/show/100284/ is what I meant to paste [18:46] maybe getting the latest version of the plugin against not the latest version of bzr wasn't a good idae [18:46] *idea [18:47] Yeah, your bzr is too old. What version is it? [18:47] whichever 8.10 comes with.. [18:47] 1.6.1.1 [18:47] er, 1.6.1 [18:48] Yeah, it requires something newer than that. [18:48] Um, sorry this is such a pain. [18:48] I think it might have been quicker to just start grepping. :P [18:49] Would that cover past revisions however? [18:49] nope [18:49] No, but "grep foo; bzr revert -r -2; grep foo; bzr revert -r -3; ..." doesn't take *forever*. :P [18:49] Uh. Heh [18:50] I guess you could use the PPA bzr. [18:50] how about using bzr-bisect? [18:50] what's that do? [18:51] vadi2: bisect! :) [18:51] vadi2: it is used to find when a bug was introduced for example [18:51] * LarstiQ missed some context so maybe this is not a suitable solution [18:51] Thanks for the tip, I'll need it for another problem [18:51] right now I need to search for a string across all files in bzr across all of their revisions [18:52] vadi2: you give it a range of revisions, and then it will start to do a binary bisection to find the revision you're looking for [18:52] vadi2: ah [18:52] vadi2: I don't think there is a ready answer for that [18:52] vadi2: try revert search to rev 61 [18:52] It's the 'I'm definitely positive it I did this, but I cannot find it' type of moment [18:52] vadi2: right [18:52] garyvdm: not 52? [18:53] Or upgrade bzr. [18:53] ok [18:54] vadi2: Well, it wouldn't take long to try them and find out. :D [18:56] r52 seems to have worked, thanks much [18:56] 61 didn't? [18:57] would be nice if there was a bzr-plugins ppa or something [18:57] I didn't test 61 :\ [18:57] 52 just says added support for 1.6 so I'm happy [19:07] Peng_ thanks for the tip, but sadly bundlebuggy still ignores me. I think I should wait for aaron to set me straight. Hopefully this doesn't block reviews.. [19:08] Huh. [19:09] Maybe BB just doesn't like you. [19:09] my thoughts exactly :) [19:10] Ohh. Maybe BB doesn't like using bzr+ssh? [19:10] aaarg [19:11] I want to refraigh from sending more spam untill aaron can tell me what goes for what [19:11] is he on holiday? [19:13] I dunno. [19:13] I vote for sending one more message, but I'm not the one sending it, soo. :P [19:14] it looks like my full bundle went trough on the list, but BB ignored that too === Spaz is now known as Kittens [19:47] garyvdm: ping [19:47] Hi vila [19:47] hey :) [19:48] I just finished reviewing your patch for bzr-upload [19:48] Cool! [19:48] I think we started on the wrong foot :-/ [19:48] Take a look at lp:~bzr-upload-devs/bzr-upload/upload-from-remote-branch (built on top of your patch), read my review, and tell me what you think [19:49] Ok [19:49] I won't stay there long, so take your time :-) Just wanting to "talk" a bit as a review may sounds more rude than it is [19:50] garyvdm: on another subject, you said you'll work on qbzr regarding the new UI, I had to too [19:51] [19:51] [19:51] -class SubprocessGUIFactory(ui.text.TextUIFactory): [19:51] +class SubprocessGUIFactory(ui.CLIUIFactory): [19:51] [19:52] seems to be enough (and simpler because there are circular dependencies otherwise (simplifying)) do you know why qbzr was using a TextUIFactory ? [19:53] Re:review - that cool. [19:53] I'm not sure why it was using TextUIFactory, but I can tell you why it is now. [19:53] has anybody else seen problems with the new progress code [19:53] just hit the recursion limit :-( [19:54] P.S. I've pushed new revisions to lp:qbzr [19:54] garyvdm: why is it now ? [19:54] jelmer: file a bug [19:54] qbzr now displays the transport activity [19:55] hmmm, that's a very good reason... [19:55] I reuse some of the TextUIFactory code to generate the transport activity string. [19:55] vila: it used TextUIFactory, because it implemented methods I didn't have to implement on my own [19:56] then I think qbzr should define that class in a lower package that it can lazy import :-/ [19:56] luks, garyvdm : I tried to play a bit *without* pushing down the class definition but I went nowhere [19:57] Yes- I've moved the class and import to lib/subprocess.py [19:57] so if qbzr *needs* textUI *and* you want to lazy import (which are both valid wishes :-)... [19:57] garyvdm: great, I should pull :-) [19:58] I'm off, have fun [19:59] Some of the methods that I'm using fro TextUI are _private. I'm going to document what we could use and maybe submit a patch. [19:59] garyvdm: excellent idea [19:59] Try to do that sooner than later (i.e. before 1.12 is out), there is a window here before the API is freezed [20:00] Ideally bzr-gtk should do the same... I may give it a try if a find the time :-/ [20:08] moin [20:10] hey lifeless [20:12] I suspect that BB is not processing mail (maybe I upset it. sorry), or maybe it just hates & ignores me now... [20:20] jelmer: some issues were reported on the list [20:33] lifeless, thanks, I'll have a look there [20:33] lifeless, so I've pondered a bit more over rebase [20:33] lifeless: what about just adding these sorts of options to a "bzr rewrite" command (copying, or perhaps replacing replay) ? [20:34] That could be the primary interface possibly, and rebase could just be there for git refugees [20:36] jelmer: something like that, sure. But replay can't do all rebase does atm; seems to me there are three branches needed: [20:36] working [20:36] source to pull --overwrite from [20:37] source to replay onto the new tip [20:37] in rebase working is ., source to replay is ., and source to pull from is 'parent' [20:44] the ability to plan out an operation and save it is something that would be useful for replay too, IMO [20:45] Yes, I agree [20:53] I'm seeing some strange behavior with coverage tracing in bzrlib.tests.make_bzrdir and bzrlib.transport.get_transport. The tracer stops tracing when the latter returns control to the former. Anyone here who can help? [20:56] I don't have a canned answer sorry [20:58] morning lifeless [21:07] hi thumper [21:19] whoa, the bzr-svn cache seems to actually be slowing it down significantly these days [21:21] When I run bzr --coverage cover selftest -v test_push_onto_just_bzrdir , the coverage results look wrong. [21:22] cover/bzrlib.tests.__init__.cover indicates that the first several lines of make_bzrdir were covered, but the lines after get_transport were not. [21:24] do you guys advocate multiple bzr repositories or one repository? for example, I have one gigantic repository with projects and config files [21:26] matthewlmcclure: I don't have any experience using cov sorry [21:26] sohail: we advocate what works for the individual [21:27] thanks lifeless. anyone else here who does use coverage? [21:27] lifeless, yeah I'm not sure if that is working for me [21:27] bzr push takes forever [21:28] of a new branch or of a single commit? [21:29] lifeless, single commit [21:29] thats odd [21:29] it shouldn [21:29] 't really be related to tree size [21:29] yep... pretty repeatable too [21:29] what protocol are you pushing over? [21:30] I do bzr push CTRL-C bzr break-lock $LOCATION bzr push [21:30] version 2 it seems to say [21:30] well it says "upgrade server" and then reconnects using version 2 [21:30] sohail: sftp | bzr+ssh | bzr+http | ftp | webdav [21:31] sohail: which of those are you using? [21:31] bzr+ssh lifeless [21:32] what is your bzr version? [21:33] on push target, 1.3.1, source 1.9 [21:33] upgrade the target [21:35] lifeless, ok I'll do that [21:48] the last change to WhoUsesBzr is ...odd [21:49] you mean the adding the references to other DVCSes? [21:49] That one didn't make much sense to me either [21:50] http://git.or.cz/gitwiki/GitProjects?action=info [21:50] same guy [21:51] same on darvs [21:51] same on darcs [21:51] this person has whipped around a bunch of wikis cross linking [21:57] good morning [21:59] hi poolie [21:59] hi [22:00] hello jelmer, lifeless [22:00] lifeless, do you want to meet up today? [22:00] sure [22:01] I need to be back here not much after 3, or at 3 ideally [22:02] i could come there [22:11] jelmer: have you written a VersionedFiles interface to dulwich? [22:12] lifeless, not yet [22:12] it's in the pipeline though [22:13] where would it go [22:13] bzr-git? dulwich? somewhere else? [22:13] bzr-git [22:13] dulwich is just a Python implementation of the git file formats/protocols, independent of bzr [22:14] yeah [22:23] jelmer: have you upgraded bzr-git to rich roots or subtrees? [22:23] lifeless, yes, it writes rich roots [22:23] jelmer: trying to sync my branch and it barfs :P [22:23] no the repo [22:23] lifeless, oh, the repo is rich root as well [22:23] so we could "bzr join" dulwich [22:24] the two are developed in lockstep at the moment, we'll remove dulwich again once the dulwich API is more stable [22:28] jelmer: You marked bug 308353 as fixed. Are you sure? I still get the error. I tried nuking bzr-svn's cache; I'm trying a new repo now. [22:28] Launchpad bug 308353 in bzr-svn "[0.5] KeyError in old_inventory when branching Lighttpd 1.4" [Medium,Fix released] https://launchpad.net/bugs/308353 [22:28] Peng_, The fix hasn't actually been pushed yet, will do that in a minute [22:30] Peng_, pushed now [22:30] Heh, okay. [22:30] You shoulda said "Fix Committed" then. ;P [22:35] jelmer: Still got the error. Do I need to delete the cache or anything? [22:49] Peng_, where did you pull from? [22:49] revision-id: jelmer@samba.org-20090118223431-v2g3dql9rv2ikjpa ? [22:51] jelmer: 1.) http://people.samba.org/bzr/jelmer/bzr-svn/0.5/ 2.) Nope. The tip is, uh, jelmer@samba.org-20090118221826-68xux6yq6a482k2f . [22:51] Peng_, that should be sufficient; can you remove the cache and try again? [22:52] Aye. [22:53] ah, crap - it may not actually be fixed [22:53] Peng_, I only checked --stacked and lightweight co for some reason [22:53] jelmer: Ah. I'm using regular branches.. [22:53] * jelmer tries with regular [23:05] Peng_, ok, it's still there [23:05] Peng_, Sorry [23:08] :D [23:08] jelmer: Is this a one-line change to make it apply to regular branches too, or more complicated? [23:16] poolie: sorry I missed the call [23:16] my plan for today ... [23:16] np [23:19] release updated log benchmarking numbers; package usertest wrappers so others can more easily use it; reviews; reply to kfogel re doc; log --merge-revisions (i.e. make it orthogonal to formatters while keeping current behaviour) === igc1 is now known as igc [23:23] igc: I'm not sure I ever saw that reply "re doc" -- what was the subject? [23:24] Was it in the "Short, task-based bzr doclets for real-world use cases." thread? [23:32] Peng_, no, it's not a one-line change [23:32] Peng_, just added bzrlib.plugins.svn.tests.test_fetch.TestFetchWorks.test_fetch_replace_self_open that demonstrates the problem [23:39] kfogel: shrt, task-based bzr doclets [23:39] reply coming ... [23:41] jelmer: Alright. Thanks for your work. :) [23:47] * igc food