[00:01] <lifeless> I'm friendly and helpful? damn, must have had enough caffeine
[00:01] <fullermd> And you have a pleasant outlook, too.
[00:23] <abentley> jam: ping
[00:32] <smoothice> Is there any way a bazaar branch can be pushed over SSH to a folder on a web server that is being served by Apache and have coders be able to run the branch directly over Apache?
[00:32] <NfNitLoop> smoothice: Yep!
[00:32] <NfNitLoop>  it does that by default.
[00:32] <smoothice> NfNitLoop: it does? I just tried...
[00:33] <NfNitLoop> just do:   cd yourrepo; bzr push sftp://yourserver/path/to/web/dir/
[00:33] <fullermd> Yes.  You push over SSH to a folder on a web server that is being served by Apache and coders will be able to run the branch directly over Apache.
[00:33] <NfNitLoop> smoothice: then have someone bzr branch http://yourserver/path/to/that/dir
[00:33] <smoothice> ok
[00:34] <smoothice> I added index.php to the repository and then pushed... although it isn't showing up in my sftp client or apache either...
[00:34] <NfNitLoop> smoothice: by default, it only creates a .bzr directory, not a working copy.
[00:34] <NfNitLoop> and your web server may hide .hiddenDirectories
[00:34] <smoothice> So... how do I make it make a working copy?
[00:34] <fullermd> Do you mean "run the 'branch'", or "run the branch"?
[00:35] <smoothice> What's the difference?
[00:35] <NfNitLoop> executing 'bzr branch', or executing the code within that branch.
[00:35] <NfNitLoop> fullermd: I think he means run 'bzr branch'.
[00:35] <fullermd> You can use checkout to make a WT on it.  Later pushes won't update it, though.
[00:35] <fullermd> I think he actually means executing the code within the branch.
[00:35] <fullermd> e.g., bzr push as a deployment mechanism.
[00:35] <NfNitLoop> oh.   smoothice: which is it? :)
[00:36] <smoothice> I'd like to be able to run the latest revision using Apache
[00:36] <fullermd> Which it isn't.  If you actually have ssh (not sftp) access, you can use the push-and-update plugin to hack around it.
[00:36] <fullermd> There's also a bzr-upload plugin; I'm not sure of the details of how it works or what server-side support it needs.
[00:37] <smoothice> So in other words it isn't possible?
[00:38] <fullermd> Well, those are two mechanisms that can probably give you the same end result.
[00:38] <fullermd> 'push' qua 'push' won't do it, no.
[00:38] <smoothice> alright
[00:39] <smoothice> The upload plugin seems fairly straightforward to install...
[00:39] <NfNitLoop> Or, if you have ssh access, just ssh to the web server and do a 'bzr pull'.
[00:40] <fullermd> I _think_ the upload plugin does all the work client-side, and just needs a transport (like sftp) to blat the files on the server.
[00:40] <smoothice> Yeah
[00:40] <fullermd> The rest of the options (like push-and-update, what NfNitLoop just said, and various other related permutations) all rely on having bzr server-side.
[00:40] <smoothice> I have a vps... so I was just finding out the best way for me to keep track of this PHP project I'm working on while also being able to run it directly.
[00:43] <fullermd> Well, for me, my VCS basically never has anything to do with my deployment mechanism.  So, if you ask _me_ the best way, it would be "nothing to do with bzr".  That may be less helpful if you aren't me though  :p
[00:44] <smoothice> yeah... I'm not using it for deployment though... this is my private apache server and deployment is on shared hosting somewhere else..
[00:46] <fullermd> Well.  It [sounds like it's] still a deployment question, just not the ultimate deployment.
[00:46] <smoothice> yeah... ok :)
[00:46] <smoothice> well thanks for your help; I guess bazaar won't work this time around :)
[00:46] <fullermd> Or it could be just a setup/move, in which case ignore me  :)
[00:47] <fullermd> Oh, it works great for the VCS part.  With the mentioend accoutrements, it can roughly do the deployment side.
[00:47] <fullermd> Whether that roughly is apparently smooth or really rocky would depend on details of just how you end up doing things.
[00:48] <smoothice> alright
[00:48] <fullermd> (and there are better people around than me to ask about them; I just know that they exist and seem to work well for some people)
[01:28]  * nDuff wanders off to Nuclear Taco Night; will check email for any feedback on the patch now and again, but latency on revisions will be significant.
[01:31] <lifeless> nDuff: thanks for doing the patch
[01:31] <lifeless> nDuff: enjoy your tacos
[02:14]  * igc lunch
[03:56] <mwhudson> spiv: hello
[03:56] <mwhudson> spiv: this looks a little odd to me:
[03:56] <mwhudson> ^[..>>> bzrlib.branch.Branch.open('http://bzr.malept.com/bazaar-overlay')
[03:56] <mwhudson> b = _
[03:56] <mwhudson> RemoteBranch(http://bzr.malept.com/bazaar-overlay/)
[03:56] <mwhudson> >>> b = _
[03:56] <mwhudson> >>> b._ensure_real()
[03:56] <mwhudson> Traceback (most recent call last):
[03:56] <mwhudson>   File "<stdin>", line 1, in ?
[03:56] <mwhudson>   File "/usr/lib/python2.4/site-packages/bzrlib/remote.py", line 1362, in _ensure_real
[03:56] <mwhudson>     if self.repository._real_repository is None:
[03:56] <mwhudson> AttributeError: 'KnitPackRepository' object has no attribute '_real_repository'
[03:56] <mwhudson> >>>
[03:56] <mwhudson> does it look odd to you?
[04:03] <spiv> Yes.
[04:03] <spiv> Which bzr version?
[04:05]  * spiv hmms
[04:08] <spiv> RemoteBzrDir.find_repository() returns a non-RemoteRepository.
[04:08] <spiv> That seems... bad.
[04:09] <spiv> Oh, hmm!
[04:11] <mwhudson> spiv: hope you're having fun, i have to disappear :)
[04:11] <spiv> mwhudson: so I think it's a server config issue
[04:11] <spiv> (that the client doesn't handle gracefully)
[04:11] <spiv> mwhudson: there's a smart server at /bazaar-overlay but not /
[04:12] <spiv> So there is no accessible RemoteRepository for that RemoteBranch
[04:12] <spiv> mwhudson: is there a bug about this?
[04:25] <lifeless> groupcompress works again
[04:25] <lifeless> lp:~lifeless/+junk/bzr-groupcompress
[04:57] <bob2> yay
[04:59] <lifeless> wow
[05:00] <lifeless> I'm seriously inclined to just revert the "BzrVsGit" change
[05:01] <lifeless> igc: ^ what do you think
[05:02]  * igc reads it
[05:04] <mlh> That they have a use TortoiseGit is not irrelevant for lots of people
[05:05] <lifeless> thats true
[05:06] <lifeless> its not really appropriate to have a git biased page on the bzr website
[05:06] <lifeless> neutral is ideal
[05:07] <lifeless> the lp integration stuff wasn't about generic public hosting; there are other public hosting sites that lp for bzr
[05:08] <mlh> yeah the rest of the stuff seems unduly uhm
[05:08] <mlh> whats the word? contentious?
[05:08] <spiv> mlh: "citation needed", perhaps ;)
[05:08] <lifeless> biased :) that was the intent expressed by the changelog of the author
[05:13] <mlh> geez unsubscribe him/her
[05:13] <mlh> "This make the bazaar guys fall their jaws." ?!
[05:15] <lifeless> they are also wrong
[05:15] <lifeless> as what they reference has no relationship to disjoint repository merges
[05:15] <lifeless> I think this is a case of an uninformed advocate going nuts
[05:17] <igc> I agree that most the changes don't actually improve the accuracy/usefulness of the document
[05:17] <nDuff> lifeless, I don't think enjoying the tacos is quite the point at Nuclear Taco Night; I think it's more watching the new people trying to actually eat one. :)
[05:17] <mlh> fall their jaws -> sounds like an attempted translation from German maybe of 'make their jaws drop'
[05:18] <igc> For example, bound branches are more than just commit+push
[05:18] <lifeless> poolie has already done one revert
[05:19] <igc> the reference to http://cournape.wordpress.com/2008/10/30/going-away-from-bzr-toward-git/ adds value I guess
[05:21] <igc> most of the rest seems to miss the original points being made
[05:21] <lifeless> igc: I'm not sure it does; its not entirely accurate as a blog, and well there are plenty of folk posting in both directions
[05:22] <poolie> so
[05:22] <lifeless> jml: btw, 'bzr help commit' can show you stuff about commit.
[05:22] <poolie> i'm not saying it was all wrong, but i'm not interested at the moment in picking through it to correct it if he's basically trying to bias it
[05:22] <jml> lifeless: noted. :)
[05:22] <igc> lifeless: agreed on both fronts, but the blog article was pretty balanced I thought, if not fully accurate
[05:23] <igc> poolie: thanks for the revert
[05:25] <igc> nDuff: just posted a review of your patch BTW
[05:27] <nDuff> igc, thanks
[05:52] <lifeless> gnight
[06:06] <fullermd> Ouch, my jaw!
[06:08] <mwhudson> spiv: only https://answers.edge.launchpad.net/launchpad-bazaar/+question/56078
[06:10] <spiv> mwhudson: ta
[06:22]  * fullermd mutters.
[06:22] <fullermd> Does it bug anybody else that 'reconfig' isn't a builtin alias?
[06:23] <spiv> fullermd: it hasn't yet.
[06:23] <spiv> fullermd: I mean, it hasn't bugged *me* yet
[06:23] <spiv> fullermd: but now that you've planted the idea in my brain, perhaps it will ;)
[06:24] <fullermd> Hm.  Does it bug anybody else that you're not sending me certified checks?  Also a pony?   8-}
[06:25] <spiv> fullermd: ok, those definitely aren't bugging me :)
[06:25] <fullermd> What a cruel, heartless world   :(
[06:41] <fullermd> OK, let's pretend I don't know python.  What's the difference between @classmethod and @staticmethod, and why would they differ on methods that are apparently called in exactly the same way?
[06:42] <spiv> staticmethod isn't passed the class.
[06:42] <spiv> i.e. staticmethod is basically a function that exists in a class's namespace rather than a module's namespace.
[06:42] <fullermd> Ah.
[06:44] <fullermd> Got a minute to explain why the difference in a specific place to me?
[06:44] <spiv> Sure.
[06:44] <fullermd> reconfigure.py.  @static to_checkout vs. @class to_lightweight_checkout
[06:44] <fullermd> (and a number of other @static's and @classes, but those are right next to each other.
[06:44] <fullermd> I guess the klass(bzrdir) is SORTA the same as Reconfigure(bzrdir)?
[06:46] <spiv> fullermd: it's the same in the absence of subclassing, yeah.
[06:47] <fullermd> Is there some reason to prefer one over the other?  And/or do you know of a reason there's the inconsistency across the methods there?
[06:47] <spiv> And given that the Reconfigure class isn't subclassed, nor intended to be AFAICT, there's not really any reason to prefer classmethod over staticmethod (or vice versa).
[06:47] <fullermd> So it's probably just "however $WHOMEVER felt like writing it"?
[06:48] <spiv> The reason why you'd use classmethod generally is if you expect subclasses to matter.
[06:49] <spiv> E.g. a .empty_clone method might make sense as a classmethod.  It doesn't depend on instance state, but you expect a to get back an object of the same class, not the base class.
[06:49] <spiv> (But it's a shame there's no way to say "this is a method that is only on a class, not on an instance", and vice versa)
[06:49] <spiv> Well, I guess there is the latter.
[06:50] <spiv> fullermd: so yeah, I think with that code it's "whatever $AUTHOR felt like".
[06:52] <spiv> That module/class is a bit weird, IMO.
[06:53] <spiv> I'm not sure why Reconfigure.to_checkout and/or Reconfigure(...).to_checkout were chosen as APIs rather than module-globals.
[06:53] <fullermd> I'm getting that feeling.  But I figure it's more the interface between me and the code...
[06:53] <spiv> My guess is there's a minor amount of premature generalisation there.  It's not a big deal.  Just pretend the @*method functions are module globals, basically.
[07:01] <fullermd> It does seem pretty abstract.
[07:02] <vila> hi all
[07:03]  * fullermd waves at vila.
[07:05]  * vila waves back
[07:06] <igc> hi vila - some more reviews for you today. Hope they help.
[07:18] <vila> igc: They always do !
[08:22] <fullermd> Furrfu.
[08:23] <fullermd> Y'know that feeling you get, when you think "Hey, I can fiddle with reconfigure for 10 minutes before I go to bed"?
[08:23] <fullermd> Yeah.  It don't work like that.
[08:27] <igc> night al
[08:28] <igc> all, that is
[08:42]  * fullermd hopes that's right.
[08:42] <fullermd> I don't feel confident I understand all those corners in Reconfigure   :|
[11:02] <jelmer> moin
[11:18] <nDuff> hrm; Branch(local_src_path).sprout(local_tgt_path, stacked=True) is failing with TypeError: sprout_read_locked() got an unexpected keyword argument 'stacked'
[11:43] <fz> how do i add keyword support to bazaar?
[12:08]  * nDuff switches to using BzrDir.sprout(), and all is well.
[12:08] <nDuff> fz, wait a few months.
[12:09] <nDuff> fz, seriously, though, there's ongoing work that's prerequisite to keyword support which will be going in as part of the EOL translation support.
[12:10] <nDuff> fz, out of curiosity, what's your use case?
[12:11] <EarthLion> bzr st
[12:11] <EarthLion> removed:
[12:11] <EarthLion>   concrete/blocks/autonav/ added:
[12:11] <EarthLion>   blocks/autonav/
[12:11] <EarthLion>  bzr mv --after concrete/blocks/autonav/ blocks/autonav/
[12:11] <EarthLion> bzr: ERROR: Could not move autonav => autonav: concrete/blocks/autonav is not versioned.
[12:11] <EarthLion> i don't see what it means there
[12:11] <EarthLion> it is version as it shows that it has been removed
[12:12] <EarthLion> the help for bzr mv tells me that --after is used --after        Move only the bzr identifier of the file, because the file
[12:12] <EarthLion>                  has already been moved.
[12:12] <EarthLion> which is exactly this situation
[12:12] <EarthLion> anyone have any ideas why this would be saying this?
[12:14] <fz> nDuff: I'm moving from svn to bzr and just go used to having the keywords, I don't really have a need for it :)
[12:15]  * nDuff makes a much belated trek home and to bed.
[12:18] <EarthLion> doh
[13:25] <awilkins> EarthLion: The doh because you've realised that the file has been removed from the inventory so it's not versioned anymore?
[13:25] <awilkins> EarthLion: I would rather like "--after" to notice that, I ran into it yesterday
[13:27] <EarthLion> awilkins: doh because i couldn't seem to get it to work
[13:27] <EarthLion> awilkins: could you define what you mean by inventory?
[13:28] <awilkins> "The list of files that Bazaar currently cares about"
[13:28] <awilkins> Have you uncommitted to get to this point?
[13:28] <EarthLion> yes
[13:29] <awilkins> The commit has implicitly removed the file from the inventory because it was missing
[13:29] <awilkins> That implict removal is not undone by the uncommit
[13:29] <awilkins> So you have to revert the file before you move it
[13:29] <EarthLion> yep
[13:30] <awilkins> There was a plugin for auto-move-stuff somewhere
[13:52] <vila> pqm is playing with my nerves... now it seems my submissions are just ignored (at least when they were wedging it I knew they were taken into account...)
[13:53] <vila> let's summon the LOSAs...
[13:54] <vila> spm, mthaddon: Is pqm reachable by mail right now ? (and thanks for un-blocking it this night)
[13:59] <hsn_> itsnt there some work in progress for speedup bzr check operation? it is slow - about 10k revision/hour
[14:37] <awilkins> markh: Ping?
[14:44] <vila> looks like pqm is back, thanks $WHOEVER
[15:08] <jam> nDuff: ping
[15:17] <vila> :-/
[15:18] <vila> I rejoiced too early, pqm receives my submissions and... drop them on the floor ? I get no feedback, neither success nor failure :-/
[15:19] <vila> spm: ping
[15:24] <vila> jam: do you know how to contact some LOSA other than spm ?
[15:25] <jam> mthaddon is another one to contact, but they are the only 2 that I know of
[15:25] <vila> Same here ;-/
[15:26] <vila> Was I blacklisted ? :-)
[15:26] <vila> I even change my public branch from lp to http...
[15:38] <jelmer> is anybody else seeing their info() output being printed to stdout when running the testsuite?
[15:41] <jam> vila: Are you sure you aren't sending from a loom or 1.9 format branch?
[15:42] <jam> I *thought* they upgraded the PQM's bzr to support 1.9, as statik asked me if that was okay a while back
[15:43] <jam> But the times I've seen "drop on the floor" were generally because of not recognizing the source format
[15:43] <vila> jam: I'm still in pack-0.92 /branch6 for my integration branch
[15:43] <jam> jelmer: IIRC we only use "note()" in bzrlib, but I see in trace.py "info = note"
[15:43] <jam> Otherwise, no I generally don't see it.
[15:44] <vila> RHAAAAA, put my lp URL back and it's accepted 8-(
[15:44] <jam> jelmer: In bzrlib.tests.TestCase.setUp we call _startLogFile() which calls "push_log_file()" though I think those are only for mutter()
[15:45] <jam> hmm... I haven't really tracked down the code that is supposed to suppress it
[15:45] <vila> jelmer: where are these info() calls ? In the test or in the code ?
[15:45] <jelmer> even run_bzr() causes output on stdout for me
[15:46] <jelmer> jam: ah, so maybe I'm just not running that anymore
[15:46] <jam> jelmer: so part of the bzrlib.tests.TestCase setUp is supposed to suppress writing to stdout/stderr etc
[16:04] <jelmer> jam: thanks, that was indeed the problem
[16:29] <danser> I guess the answer is 'no', but does bzr have a function like 'svn propset svn:mime-type text/html' for serving a file with an html mime type on launchpad?
[16:30] <jelmer> danser: no, sorry
[16:30] <danser> jelmer: ok, no need to apologise :-)
[16:31] <jam> danser: Launchpad explicitly doesn't allow exposing a lot of file types
[16:31] <jam> because it doesn't want to be used as a generic hosting site
[16:32] <jam> eg, upload a project with all of your images, and then refer to it from your website, making LP use the bandwidth
[16:32] <danser> sounds logical to not support that indeed
[16:54] <vila> jelmer: I just landed a patch on bzr.dev that allows writing credential stores as plugins
[16:55] <jelmer> ah, cool
[16:55] <vila> an example for '.netrc' is provided, you should be able to write one for svn
[16:55] <vila> let me know if you need help
[16:55] <jelmer> thanks, will do
[16:55] <vila> We may at least be able to handle those 401 errors :)
[16:56] <LarstiQ> will this help with when authentication.conf has the right credentials, but bzr-svn tries to use the (missing) svn credentials?
[16:57] <jelmer> LarstiQ: bzr-svn should already be trying to use authentication.conf
[16:57] <LarstiQ> jelmer: then I guess I should file a bug
[16:58] <jelmer> LarstiQ: please do :-)
[17:56] <vila> LarstiQ: This will help when svn itself knows the credentials and can provide them to bzr (i.e. authentication.conf will be able to say: for these sections, ask svn)
[17:56] <LarstiQ> vila: hmm
[18:06] <jam> vila: ping
[18:07] <vila> jam: pong
[18:08] <jam> Hey vila, I'm trying to smooth out some of the rough edges of stacked branches
[18:08] <jam> mostly because I'm going to try dogfooding LP, and right now it is pretty painful to just do "bzr push"
[18:08] <jam> The first thing I was going to do is fix it from re-opening the connection multiple times
[18:08] <jam> And I wanted to check with you how you were testing that sort of thing.
[18:09] <vila> bzrlib.tests.commands (there is a TODO about renaming it)
[18:11] <jam> Is it only possible to test at that level?
[18:11] <jam> For example, I know that doing Branch.open(really_a_stacked_branch) connects 2 times
[18:12] <jam> (ATM, doing "bzr push lp:///" connects 4 times for a new branch)
[18:13] <vila> You can use the ConnectionHookedTransport in transport_util I think to test at lower levels but...
[18:14] <vila> .. no but, the idea is that it register itself as 'hooked:' so that you always get the right king of transport (and ensures you don't escape from the scheme (at least that's the idea)
[18:14] <vila> s/king/kind/
[18:14] <vila> no more king since 1789 on this side of the sea
[18:17] <vila> But if you set up a stacked branch it should be quite easy to simply do the same kind of tests that already exist
[18:17] <vila> The painful part is using pdb  since they are nearly blackbox tests the output is redirected...
[18:19] <vila> ahhh, I knew I left some instructions:
[18:19] <vila>         # Note: uncomment the following line and use 'bt' under pdb, that will
[18:19] <vila>         # identify all the connections made including the extraneous ones.
[18:19] <vila>         # import pdb; pdb.set_trace()
[18:19] <vila> at the end of transport_util
[18:20] <vila> jam: so basically you write a nearly blackbox test, set the breakpoint, find the offending connection, add possible_transport in the call chain and you're done :)
[18:21] <kfogel> Has anyone seen a bug like ths before?  http://paste.lisp.org/display/73293
[18:29] <vila> kfogel: It looks like you didn't commit the last time you merged so diff reports the pending merges
[18:30] <kfogel> vila: a-yup
[18:30] <kfogel> thx
[18:31] <kfogel> vila: still getting it through my head that "sync me up with mainline" is a commit like anything else
[18:31] <vila> kfogel: It still occurs to me from time to time :
[18:32] <vila> kfogel: It still occurs to me from time to time :)
[19:40] <jam> vila: just as an aside, you may like this command:
[19:40] <jam>         import traceback
[19:40] <jam>         traceback.print_stack()
[19:40] <jam> It is essentially "bt" from pdb, but without actually stopping for pdb
[20:15] <vila> jam: yummy ! Add that to the comment ;-)
[20:16] <jam> I never saw the comment other than what you pasted here :)
[20:18] <vila> bzrlib.tests.transport_util.py
[20:18] <kfogel> This keeps throwing me: 'bzr send -o -' shows me a bundle for the change(s) I just made, but my log messages are not (humanly) visible in the bundle.  Is this expected?
[20:20] <Peng_> kfogel: Yes.
[20:20] <kfogel> Peng_: Do you happen to know if it's a deliberate design decision or just the way things fell out?
[20:21] <kfogel> (It seems odd that bzr shows the diff but not the log message.)
[20:21] <Peng_> kfogel: Sorry, I don't know why the bundle format was designed that way. The docs might.
[20:21] <Peng_> kfogel: If you just want to diff against another branch, I'm sure there are better ways...
[20:22] <vila> kfogel: the diff is targeted at reviewers, you're supposed to add your own cover letter and that's not the same intent at the commit messages
[20:22] <kfogel> vila: *nod*
[20:22] <vila> kfogel: I share your feeling though, now that you mention  it, the commit messages may help write the cover letter
[20:22] <kfogel> Yeah, can see that one both ways.
[20:22] <kfogel> I agree a cover letter is necessary!  But once I've read the cover letter, I usually want to read the log messages.
[20:22] <kfogel> Or rather,
[20:23] <kfogel> A better way to say that is: I *never* want to read a diff without also reading its log message.  Period.
[20:23] <kfogel> :-)
[20:23] <kfogel> (Well, perhaps that's exaggerating a bit, but only a bit.  It has to be a truly trivial diff for me not to want to see the log msg along with it.)
[20:23] <vila> bunble buggy presents the commit messages: http://bundlebuggy.aaronbentley.com/project/bzr/request/<4966598F.8040109%40arbash-meinel.com> for example
[20:24] <kfogel> vila: that's good
[20:24] <kfogel> vila: but your earlier point is exactly what's happening to me right now -- my own commit message would have been helpful for writing the cover letter.
[20:24] <spm> vila, jam, there are 3 LOSAs: mthaddon, herb and myself. fwiw...
[20:26] <vila> herb ! The missing one ! :-)
[20:26] <vila> spm: what are your TZs ?
[20:27] <spm> vila: West coast USA, East cost USA, East coast Australia respectively. So pinging me at 2.30am isn't likely to get an immediate response :-)
[20:30] <vila> spm: Now I know :-)
[20:31] <spm> heh :-)
[20:37] <vila> kfogel: so try 'bzr log -rsubmit:.. --short'
[20:38] <kfogel> vila: thx
[21:09] <jam> spm: well, mthaddon wasn't directly here, and I hadn't heard of herb before. Besides, we still got a response :) (just a bit later)
[21:09] <spm> jam: heh
[21:30] <nDuff> jam, ACK
[21:31] <nDuff> ...pardon the latency, was sleeping.
[21:42] <jml> jam: thanks for the Branch.open patch!
[21:43] <jam> nDuff: sleep is for the weak :) At least, sleeping when I'm awake is.
[21:43] <jam> I was just hoping for some more background on your patch, but I worked it out. And its been merged.
[21:43] <jam> jml: Did you see the follow up? (Which fixes other cases for 'bzr push' at least?)
[21:45] <jml> jam: yeah. it's great.
[21:45] <jml> jam: one step closer to the day when pushing up no revisions takes about as long as an SSH connect :)
[22:14] <vila> jam: Looks like my review and your followup crossed on the wire, I think my vote (and remarks) still apply or you want a re-review ?
[22:15] <vila> jam: rhaa, you reply just arrived
[22:16] <vadi2> How can I convert an svn repository into a bzr one? "bzr svn-import <svn location>" does not seem to work.
[22:17] <Peng_> vadi2: Define "does not seem to work".
[22:17] <spiv> vadi2: what error does it give?  (paste it into http://rafb.net/paste)
[22:18] <vadi2> http://rafb.net/p/BCVXV790.html
[22:18] <vadi2> It performs the import successfully, without an error, however the repository created is rather empty. While the real svn one has data in it
[22:19] <Peng_> vadi2: It doesn't create working trees by default. Run "bzr co" inside a branch.
[22:19] <vadi2> aha :)
[23:04] <jml> when's 1.11 due out?
[23:04] <igc> jml: rc today
[23:04] <jml> igc: cool.
[23:32] <poolie> igc, would i be right in thinking the best hg->bzr converter is through fastimport, and that it should be pretty solid on both sides?