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