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