[00:45] <mtaylor> bzr rebase still occasionally spits this out at me: NoSuchRevision: CHKInventoryRepository('file:///home/mordred/src/drizzle/.bzr/repository/') has no revision ('mordred@inaugust.com-20100420210116-ldo67yidt8wbrs0l',)
[00:45] <mtaylor> you know, for what it's worth
[00:59] <lifeless> mtaylor: is there a bug open ?
[01:01] <mtaylor> lifeless: I feel like I filed one like a year ago
[01:03] <mtaylor> oh! I suppose I haven't
[01:03] <mtaylor> there it is
[01:03] <mtaylor> bug#446075
[01:04] <lifeless> bug 446075
[01:04] <lifeless> heh
[01:06] <lifeless> spiv: if you could review my stuff branch that would be great. Its all simple stuff. You'll need to merge locally as lp is still swamped :P
[01:06] <a212901390231901> mtaylor, in case you missed it from this morning:
 lifeless: can you think of any decent reason why I can't use bzrlib from jython? <- see https://lists.ubuntu.com/archives/bazaar/2009q4/063999.html
[01:06] <a212901390231901> and some of the rest of the log may be of interest to you.
[01:06] <lifeless> a212901390231901: that nick really breaks my mind :)
[01:07] <lifeless> can I call you ed209 ?
[01:07] <a212901390231901> I'm happy with any random string of alphanumerics
[01:09] <spiv> lifeless: Stuff branch?  Heh.  I'll take a look.
[01:09] <lifeless> yeah its just stuff
[01:09] <lifeless> anytime I need to read the bzr code to answer a question, I'm fixing docs up
[01:14] <mtaylor> a212901390231901: neat
[02:09] <lifeless> spiv: how did that review go?
[02:12] <lifeless> oh, i see, gary got to it
[02:12] <lifeless> spiv: however I've pushed more to it this morning already ;)
[02:16] <spiv> lifeless: I just hit "Save comment" as it happens!
[02:16] <lifeless> spiv: thanks!
[02:16] <spiv> lifeless: also, check this out:
[02:17] <spiv> http://paste.ubuntu.com/428000/
[02:18] <lifeless> busy busy
[04:48] <lifeless> spiv: teddy bear time ? [irc]
[04:49] <spiv> lifeless: shoot
[04:49] <lifeless> did you see my chat with james_w earlier?
[04:49] <lifeless> it provides context
[04:49] <spiv> lifeless: I skimmed it
[04:49] <lifeless> ok
[04:50] <lifeless> so, seems to me merge-upstream is /the/ place to put in detection for 'time to do something special'
[04:50] <lifeless> for joining previously unassociated upstreams
[04:50] <spiv> Sounds plausible to me :)
[04:51] <lifeless> secondly, I'm proposing to jsut discard the old file ids
[04:51] <lifeless> and not rewrite history
[04:51] <lifeless> as a first-stage 'get things connected' tool
[04:51] <lifeless> with some logic to handle variations on the theme of 'the distro content is different'
[04:52] <spiv> Fair enough.
[04:53] <lifeless> lastly
[04:53] <lifeless> as a user
[04:54] <lifeless> would you want a 'go run XXX' or a 'about to do XXX [y/n]', or a 'just did XXX' interaction with bzr
[04:55] <spiv> It depends a bit on how easy it is to undo.
[04:55] <mtaylor> lifeless:  'about to do XXX [y/n]'
[04:55] <spiv> Although if the cost of making a mistake is low, then to some extent the choice doesn't matter.
[04:55] <lifeless> spiv: uncommit; revert
[04:55] <lifeless> spiv: as usual ;)
[05:01] <spiv> In that case, 'about to do XXX [y/n]' sounds good because mtaylor likes it ;)
[05:01] <spiv> I think that's definitely nicer than 'go run XXX'
[05:02] <spiv> And probably the 'hey this is a bit unusual, you should know about this' is good.
[05:18] <lifeless> spiv: btw my branch of hydrazine uses the same message format as pqm when its doing the generation
[05:19] <lifeless> spiv: so I was confused when you said they were different the other day
[05:19] <spiv> Hmm, I didn't know that.  I'm pretty sure it's been different at some point.
[05:20] <spiv> Certainly if your branch is different to trunk, and some devs are using trunk, then that's a problem.
[05:20] <spiv> (different in how it uses the commit message field, that is)
[05:21] <lifeless> spiv: poolie was going to merge it, I thought
[05:26] <spiv> Last I looked he hadn't, but I don't know why there's a delay.
[05:29] <lifeless> spiv: ETIME probably
[06:24] <parthm> hello, I sent two proposals (lp:~jbowtie/bzr/fix-555439 and lp:~doxxx/bzr/572092-ignore-dupes ) to queue using feed-pqm.
[06:24] <parthm> is there supposed to be some time lag before they show up on http://pqm.bazaar-vcs.org/ ?
[06:25] <spiv> There isn't supposed to be, but there is ;)
[06:25] <lifeless> yes, 60 seconds
[06:25] <parthm> spiv: :) i am just try to ensure my setup is fine. ... maybe i will wait for some more time.
[06:25] <lifeless> plus mail processing time
[06:26] <spiv> It's usually only a minute or so for emails to be noticed by PQM.
[06:26] <lifeless> total time should be < 3 minutes worst case, unless your mail setup is terrible.
[06:26] <parthm> lifeless: 60 sec. hmm ... maybe something is still wrong with setup.
[06:29] <spiv> lifeless: as an example, notice the commit messages parthm has been setting -- they explicitly include the lp username of the proposer, so they aren't appropriate to use with your hydrazine branch.
[06:30] <spiv> lifeless: basically, I'd like a time machine so we can skip over these awkward transitional phases ;)
[06:32] <parthm> lifeless, spiv: i wasn't sure if i should be including lp username or if the queue adds it during commit. should i be doing that?
[06:32] <parthm> i noticed that the patch i landed yesterday didn't have it so i explicitly put it in today.
[06:34] <spiv> parthm: with current hydrazine trunk, I think you need to add that name manually.
[06:34] <parthm> spiv: will do. thanks.
[06:34] <spiv> parthm: lifeless has a branch that does it automatically
[06:35] <lifeless> parthm: if you're using my branch, you don't need to add it.
[06:35] <lifeless> but you use 'e' rather than 's' to send (e for email)
[06:35] <spiv> It will be nice when that branch is merged into trunk and everyone is using that.
[06:36] <parthm> lifeless: i am using trunk right now. yes, its sounds like a useful change to merge :)
[07:16] <parthm> so for https://code.launchpad.net/~doxxx/bzr/572092-ignore-dupes/+merge/24543 i got a mail from pqm that merge failed, conflict in NEWS.
[07:17] <parthm> its executing "star-merge". what exactly is that? any action on me from this?
[07:17] <spiv> parthm: "star-merge" just PQM-speak for "bzr merge this branch, please"
[07:18] <dash> now there's a term i haven't heard in a while
[07:18] <parthm> spiv: to the right thing to do is to merge locally and push to branch? would i have write access to ~doxxx/bzr/572...?
[07:19] <spiv> parthm: someone needs to resolve the NEWS conflict for PQM to be able to land it.
[07:19] <spiv> You can either ask the original submitter to fix the conflict, or you can just do it yourself.
[07:20] <spiv> You don't have write access to ~doxxx/..., but you can just make your own branch of that and send that to PQM.
[07:20] <parthm> spiv: thanks for clarifying. i will do it myself. shouldn't be too much work.
[07:20] <spiv> Unfortunately that's not particularly convenient using LP and hydrazine.  If I were doing it I'd resort to using 'bzr pqm-submit' from the bzr-pqm plugin.
[07:21] <spiv> You could also do it by creating a new merge proposal on LP for it, I guess.
[07:22] <parthm> spiv: yes. thats what i just though. a new lp proposal sounds like an overkill. i will try bzr pqm-submit. will the set message be retained?
[07:23] <vila> hi all
[07:23] <spiv> Hmm, I guess it would be nice if LP allowed someone from a project's review team to partially take over a merge proposal, i.e. to provide a tweaked version of the branch owned by someone else, but still considered a continuation the same proposal, with the same proposer etc.
[07:24] <spiv> parthm: no, pqm-submit unfortunately can't get any details from LP.  You have to tell it the commit message and the target branch yourself.
[07:24] <spiv> (the latter can have a default set in your config files, though)
[07:24] <parthm> spiv: that would be idea.
[07:24] <parthm> spiv: ok. thanks.
[07:25] <spiv> If you use pqm-submit, be sure to use the --dry-run option first to check the result.
[07:25] <lifeless> so the issue here is that 'review' and 'merge' are conflated.
[07:26] <lifeless> I've opened a bug in launchpad-code about separating this; adding info to that or to john's existing one about other branch landings would be good
[07:26] <parthm> spiv: will do.
[07:29] <parthm> so for 'bzr pqm-submit --dry-run [LOCATION]' should the location be lp:bzr?
[07:29] <parthm> for trunk
[07:30] <MvG> vila: good morning to you!
[07:30] <vila> MvG: _0/
[07:34] <parthm> spiv: hmm. i am getting an error saying lp:bzr isn't local. am i doing something wrong? http://pastebin.com/DDvz2Pc6
[07:35] <vila> parthm: your error error is that you don't know that the plugin doesn't allow lp: urls here, you have to use the resolved form (IIRC)
[07:35] <spiv> parthm: LOCATION is the branch to submit (defaults to the branch in the current working directory)
[07:35] <vila> s/error error/only error/
[07:35] <MvG> vila: thanks for the approval!
[07:35] <vila> MvG: thanks your work :)
[07:35] <spiv> parthm: I think there's somewhere in the bzr HACKING doc that summarises this
[07:36] <spiv> parthm: you probably want to set public_branch for your local dirs in your locations.conf.
[07:37] <spiv> (you can override that as a one-off by passing --public-location to pqm-submit)
[07:38] <spiv> parthm: e.g. when I run "bzr pqm-submit" in a directory called ~/code/bzr/foo, because of my locations.conf it will automatically know to tell PQM to merge lp:~spiv/bzr/foo, rather than file:///home/andrew/code/bzr/foo
[07:39] <spiv> (this is the same setting that the builtin "bzr send" command uses)
[07:39] <parthm> spiv: thanks. i will configure locations.conf.
[07:40] <vila> MvG: lp:~gagern/bzr/bug560030-drop-completions is superseded by https://code.edge.launchpad.net/~gagern/bzr/bug560030-include-bash-completion-plugin/+merge/23912 right ?
[07:40] <MvG> vila: right.
[07:40] <parthm> spiv: so the public branch with be the trunk i.e. bzr+ssh://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev ?
[07:41] <vila> MvG: ok, so can you mark the first rejected and fix the NEWS conflict in the second ? The later will allow anybody to land it (instead of fixing it locally)
[07:43] <MvG> vila: Done.
[07:43] <vila> MvG: Yeah ! Thanks !
[07:46]  * parthm reading releasing.html for configuring pqm-submit
[07:50] <parthm> vila: sorry to trouble you with so many questions. does this locations.conf seem right for this merge? http://pastebin.com/0Fg2FJPi
[07:51] <vila> parthm: no trouble, thanks to you for landing stuff !
[07:52]  * vila checks his own setup for trailing '/'
[07:53] <vila> parthm: s/parent_branch/parent_location/
[07:53] <vila> parthm: use http: not bzr+ssh for submit_branch (don't ask)
[07:53] <parthm> vila: will do. thanks. the dry run seems to have gone through ok.  http://pastebin.com/fB3BkEeF
[07:54] <vila> parthm: submit_to ? Did you mean post_commit_to ? Anyway it's irrelevant for pqm-submit I think
[07:55] <parthm> vila: looks like it requires public_branch and not public_location. "bzr: ERROR: There is no public branch set for "/storage/parth/src/bzr.dev/572092-ignore-dupes/"
[07:55] <parthm> vila: i took the config from http://doc.bazaar.canonical.com/bzr.dev/developers/releasing.html#starting-a-cycle step 10
[07:56] <vila> parthm: I said parent_location, public_branch is correct
[07:56] <vila> parthm: this needs fixing then
[07:56] <spiv> poolie: how's the other side of the world?
[07:56] <poolie> lovely
[07:57] <poolie> crisp and moderately clear
[07:57] <vila> poolie: hey ! Welcome to my continent :)
[07:58] <parthm> vila: this looks fine. time to do without the --dry-run.
[07:58] <vila> winter is making its last attempt, there was snow in the south of France, not seen for... decades
[07:58] <spiv> Ooh!  Hope it stays that way :)
[07:58] <vila> spiv: taling to poolie or me ? :-P
[07:58] <poolie> it was 3C when we landed
[07:58] <vila> s/taling/talking/
[08:00] <parthm> vila: nice. it showed up on http://pqm.bazaar-vcs.org/ ... thanks.
[08:00] <vila> parthm: significant step !
[08:00] <parthm> vila: :)
[08:00] <vila> parthm: and compiling already ! Even better !
[08:01] <MvG> vila: Do you have anyone to suggest as likely second approver of the bash completion plugin merge?
[08:01] <vila> MvG: lifeless commented on the related one, but his pile is already huge... poolie maybe ? :->
[08:02] <poolie> i might but i'm not going to be only online briefly/intermittently this wek
[08:04] <vila> lifeless: can you give a shot at your review queue if only to abstain or nominate some other reviewer ?
[08:04] <MvG> Because the bzr-bash-completion branch is already 3 revisions ahead of the merge request. Among them a generic ExecutableFeature class taking path into account, which I'd like to submit in a separate merge request once the first one has been landed.
[08:06] <vila> MvG: You can use the pre-requisite branch attribute on the mp for that (there is a slight risk of divergence if you need to fix some issues on the pre-requisite itself though)
[08:07] <MvG> vila: I know, but I fear that having too many interdependent merge requests open at the same time might cause confusion and result in all of them getting merged later than if I serialize them.
[08:07] <vila> MvG: But generally starting new feature branches for stuff like that works better as you can then merge them into your other branches
[08:08] <vila> MvG: yeah, YMMV :)
[08:08] <MvG> YMMV?
[08:11] <vila> MvG: Your Mileage May Vary
[08:14] <lifeless> vila: my queue?
[08:14] <lifeless> vila: I think there is only one waiting on me; more-colo
[08:15] <vila> lifeless: far more
[08:15] <lifeless> vila: what ?!
[08:15]  * vila searches the simplest way to find the relevant mps
[08:17] <GaryvdM> lifeless, vila: https://code.edge.launchpad.net/~lifeless/+activereviews
[08:18] <lifeless> no, thats bogus
[08:18]  * vila scratches head.... where are they gone...
[08:19] <lifeless> I mean, I can abstain.
[08:19] <lifeless> but in general I'll say if I want things to block, the default should be not to
[08:20] <GaryvdM> lifeless: https://code.edge.launchpad.net/~amanica/bzr-notification/with_commit_hook/+merge/8166
[08:21] <lifeless> GaryvdM: yes ?
[08:21] <vila> lifeless: https://code.edge.launchpad.net/~gagern/bzr/bug513322-authors/+merge/23122 you voted needs_fixing, I think it's good now
[08:21] <lifeless> GaryvdM: I did a review on a project I'm tangetially interested in, to help out.
[08:21] <lifeless> GaryvdM: I can't land stuff there
[08:22] <lifeless> vila: then land it; if you agreed with my review *and* think the points are addressed.
[08:22] <lifeless> i wish we still had tweak
[08:22] <vila> https://code.edge.launchpad.net/~jelmer/bzr/split-subsegment/+merge/23611
[08:22] <GaryvdM> lifeless: oh sorry. Thats the wrong one. I ment this one: https://code.edge.launchpad.net/~amanica/bzr/rm_dir_with_changed_emigrated_file-129880/+merge/23528
[08:23] <GaryvdM> lifeless: I think that is ready, but someone has requested your review.
[08:24] <lifeless> GaryvdM: no they haven't
[08:24] <lifeless> GaryvdM: I *did* a review, and its been addressed.
[08:25] <lifeless> vila: I need to look at jelmers updated one; or someone else could look at it.
[08:26] <lifeless> vila: if you're patch pilot, do feel free to do reviews in such cases ;)
[08:26] <vila> lifeless: that's the point, I've been piloting for the last two weeks and I'm not doing it this week
[08:26] <lifeless> vila: ok
[08:26] <lifeless> vila: anyhow, I don't think saying 'this needs fixing' makes you required to sign off on the final patch
[08:27] <GaryvdM> lifeless: The reason I though that, is that there is still a date in the Date Requested col, but I now see that the date is before your last review. Sorry.
[08:27] <GaryvdM> I'll land it :-)
[08:27] <lifeless> GaryvdM: perhaps file a bug on launchpad-code, clearly that is confusing.
[08:27] <vila> lifeless: well, voting Needs_fixing means you've invested time to do some analysis, no need to duplicate that effort
[08:27] <lifeless> vila: but also no need to block
[08:28] <lifeless> vila: and more eyeballs are good
[08:28] <vila> lifeless: more eyeballs are good but upcasting a needs_fixing to approve is... subject to too many interpretations and possible abuses, that's why I'm very uncomfortable doing it
[08:29] <jelmer> lifeless: SRU should probably be possible somewhere before the weekend
[08:29] <lifeless> jelmer: oh, if you can that would rock; I did move the info around to be more accessible
[08:29] <jelmer> lifeless: thanks
[08:30] <vila> lifeless: anyhow, it looks like many reviews I thought were on your queue are not anymore, so I suspect they have been landed and I didn't realize it
[08:30] <jelmer> in other news, roundtripping support in bzr-git is around the corner
[08:30] <spiv> I've taken to saying explicitly "this is Needs Fixing, but once you address these issues consider my vote upgraded to Approved."
[08:31] <vila> lifeless: I had ~8/10 in mind which was obviously wrong
[08:31] <vila> spiv: yup, I've noticed that and do the same now
[08:31] <vila> spiv: but it seems that people are still expecting an explicit approve :)
[08:32] <vila> lifeless: which in turns shows that explicit is better than implicit for reviews too ;)
[08:33] <lifeless> vila: thus why I want tweak.
[08:34] <spiv> lifeless: "me too"
[08:34] <lifeless> spiv: 'affects me' on the bug ?
[08:34] <vila> lifeless, spiv: metoo, bug # ?
[08:35] <lifeless> NFI
[08:35] <lifeless> pretty sure there was one
[08:36] <vila> MFI ?
[08:36] <vila> NFI ?
[08:36] <lifeless> no f* idea ;)
[08:36] <vila> LOL, I found National Forest Inventory (Australia)
[08:36] <spiv> vila: https://bugs.edge.launchpad.net/launchpad-code/+bug/373078
[08:38] <lifeless> vila: from that bug, quoting abentley: 'I'll give you one guess what *I* suggested we call "needs fixing" :-)'
[08:39] <vila> lifeless: I was *just* reading that :)
[08:39] <chx> hi. i would like to remove the changes introduced by revisions 15476-15479 inclusive both ends
[08:41] <GaryvdM> chx: bzr merge . -r 15479..15476
[08:43] <lifeless> GaryvdM: not quite - thats half-open
[08:45] <GaryvdM> lifeless: ? The reverse merge?
[08:45] <chx> 15475 isnt it
[08:45] <chx> this does not seem to roll back 15476
[08:45] <chx> (i will fire someone tomorrow for that commit but for now let's just roll it back)
[08:45] <GaryvdM> chx: oh - right - sorry
[08:45] <GaryvdM> lifeless: got it.
[08:47] <lifeless> -> dinner
[08:53] <GaryvdM> vila: Active review count = 16 :-)
[08:54] <vila> GaryvdM: thanks !
[08:55] <GaryvdM> vila: https://code.edge.launchpad.net/~bialix/bzr/2.1-clean-tree-bzrdir/+merge/24669 has allready been reviewed, and just needs approval for 2.1. I'd rather abstain. Can you make a call.
[08:59] <vila> GaryvdM: done
[09:00] <GaryvdM> vila: Cool. There are some unlanded approved branches. I'm going to tackel that.
[09:01] <vila> GaryvdM: excellent ! Stay in touch with parthm, I think he's doing the same
[09:02] <bialix> heya
[09:02] <GaryvdM> Hi
[09:02] <parthm> GaryvdM: I have already landed the ones I was involved with. http://pqm.bazaar-vcs.org/ For https://code.launchpad.net/~parthm/bzr/563646-commit-unicode-message/+merge/23752
[09:03] <parthm> i am waiting to hear for poolie as he has requested a review.
[09:03] <GaryvdM> pathm: Ok, cool. I can also see on http://pqm.bazaar-vcs.org/ which ones have allready been submitted.
[09:04] <spiv> parthm, GaryvdM: thanks!
[09:04] <parthm> GaryvdM: i don't plan to submit anything today so i think we are good :)
[09:05] <parthm> spiv: np :) its nice to see the queue become shorter ... thanks for your help getting pqm setup here.
[09:06] <bialix> hi GaryvdM
[09:11] <vila> bialix: \o_
[09:11] <bialix> vila: \o/
[09:12]  * spiv imagines TCP-over-semaphore-over-IRC
[09:12] <bialix> what's "all stars party"?
[09:13] <vila> spiv: :-P
[09:13] <vila> bialix: at the end of the party, you see all stars
[09:13] <vila> or something like that :)
[09:13] <bialix> stars?
[09:14] <vila> bialix: kidding, music event where all UDS members can play some instrument or another, or just watch, optionally dring some beer
[09:14] <GaryvdM> bialix: http://daniel.holba.ch/blog/?p=633
[09:14] <vila> well, drink first, then dring after a few ones
[09:15] <GaryvdM> bialix: as in rock stars.
[09:20] <bialix> will abentley rocks?
[09:21] <jelmer> abentley already rocks
[09:27] <bialix> сщщд
[09:27] <bialix> cool
[09:36] <chx> gnight, thanks
[09:51] <GaryvdM> bialix: Would you like me to submit your clean-tree  branches ?
[09:52] <bialix> GaryvdM: many thanks!
[09:52] <GaryvdM> Ok
[10:06] <GaryvdM> Dose anyone have a script that deletes merged branches in a share repo?
[10:07] <a212901390231901> I just do it manually ;)
[10:08] <a212901390231901> I guess as you've been on a landing spree you might have a few more than me
[10:09] <GaryvdM> Yip. Might try write a plugin later.
[10:10] <bialix> bzr-colo ftw!
[10:13] <parthm> GaryvdM: I just noticed that ~jbowtie/bzr/fix-555439 is in the queue twice. I am assuming the changes would already be merged after the first time so that 2nd time would be a no op. right?
[10:13] <a212901390231901> yeah, might get a complaining email though
[10:14]  * GaryvdM looks
[10:14] <jelmer> lifeless: btw, I pushed a newer version of my segment url patch a couple of days ago
[10:15] <GaryvdM> parthm: Thanks for catching that
[10:15] <GaryvdM> I've got some time to try figure out how to cancel it.
[10:17] <parthm> GaryvdM: is it required to be cancelled or its just a no op. i would guess bzr should say 'nothing to merge' the second time. but maybe someone who has used the queue more than me can comment.
[10:17] <sproaty> is there a way to insert revision ID/last modified details etc to a file like svn rev ids?
[10:17] <parthm> sproaty: bzr help version-info
[10:18] <GaryvdM> parthm: I would prefer to try cancel it.
[10:18] <sproaty> cheers, wasn't sure what term to be searching for
[10:19] <parthm> GaryvdM: yup. even for a no op ... the tests might take time to run ;) ... unless there is a check for that.
[10:19]  * parthm is interested in how to cancel too ... hasn't done that before.
[10:24] <GaryvdM> vila: Is it possible to cancel a pqm submission?
[10:25] <sproaty> parthm, but is there a way to insert the version-info into a file on commit?
[10:29] <parthm> sproaty: maybe the keywords plugin will be helpful, though i haven't used it myself http://doc.bazaar.canonical.com/plugins/en/keywords-plugin.html
[10:31] <sproaty> thanks :)
[10:32] <parthm> sproaty: alternatively, 'bzr help hooks'
[10:32] <parthm> sproaty: http://doc.bazaar.canonical.com/latest/en/admin-guide/hooks-plugins.html
[10:37] <bialix> sproaty: no
[10:46] <parthm> sproaty: just wondering. what are you trying to do. keywords is generally not considered to be a good idea.
[10:51] <vila> GaryvdM: no you can't, the dirty trick, if you're fast enough is to push some garbage
[10:51] <GaryvdM> vila: or delete the branch :-)
[10:51] <vila> GaryvdM: right :)
[10:52] <GaryvdM> Oh
[10:52] <GaryvdM> Not my branch, so I can't :-(
[10:53] <parthm> vila: what will happen if we just let the second request be? will it be a no-op .. because the changes are already in?
[10:54] <vila> http://pqm.bazaar-vcs.org/ says Request for non-PQM managed branch.
[10:54] <vila> GaryvdM: is that the one ?
[10:54] <GaryvdM> vila: No Num 3
[10:54] <vila> parthm: if you  try to merge the same branch twice, pqm will say: 'Nothing to merge'
[10:54] <parthm> vila: will the tests be run?
[10:54] <vila> GaryvdM: what's the problem there ?
[10:54] <parthm> again.
[10:54] <vila> parthm: no
[10:55] <GaryvdM> vila: duplicate.
[10:55] <parthm> vila: nice.
[10:55] <vila> GaryvdM: as in 'sent twice' ?
[10:55] <GaryvdM> vila: yes
[10:55] <vila> GaryvdM: no worries then
[10:56] <GaryvdM> vila: number 6 (Request for non-PQM managed branch) was for --submit-branch=lp:bzr/2.1
[10:56] <vila> GaryvdM: you may get confusing mails about it, just update your bzr.dev branch to check
[10:56] <vila> GaryvdM: weird, may be you don't have rights there ?
[10:57] <GaryvdM> vila: Does pqm understand lp: urls?
[10:57] <vila> GaryvdM: I don't remember the exact status here, it used to understand them but there were also bugs
[10:58] <vila> I think that's why I use http: urls now
[10:58] <GaryvdM> vila: Ok, i'll see what happens, and resubmit if it fails.
[10:58] <vila> GaryvdM: ok, thanks again
[10:59] <GaryvdM> vila: sure, np.
[11:00] <GaryvdM> vila: thanks for the help
[12:02] <sproaty> just thought it'd be nice to have my files auto have their last revision date stored
[12:03] <quicksilver> I don't think bzr does RCS/CVS substs
[12:08] <maxb> sproaty: ooi, why is that useful?
[12:09] <sproaty> to other developers I guess
[12:09] <maxb> I'm curious because some people at my work seem to think the same, but they've never really come up with a convincing argument why :-)
[12:09] <quicksilver> well, it's quite nice to have last modification dates visible on documentation / on web pages
[12:09] <sproaty> seen some code under svn that does it
[12:10] <sproaty> or in the code itself :p
[12:10] <maxb> The problem is that keywords only help you there if it's meaningful to consider the individual file in isolation
[12:12] <sproaty> it's no big deal, really
[12:12] <maxb> https://launchpad.net/bzr-keywords exists, but I still maintain that it's a feature people use because CVS had it, not because it's actually useful
[12:12]  * jelmer thinks maxb has a point
[12:13] <sproaty> probably not worth the effort
[12:14] <LeoNerd> If you want to see the last mod. date on a web page, you'll be wanting some kind of web frontend to your VCS, which puts that information around it
[12:14] <maxb> And moreover, you'll want info about the tree, not about a particular file
[12:14] <sproaty> my code's only displayed in loggerhead
[12:15] <maxb> heh, then you don't need keywords at all
[12:15] <quicksilver> LeoNerd: that's not what I meant.
[12:15] <sproaty> that damn css bugs where long commit messages overflow into the file list stops me from writing long (i.e meaningful)  commit messages
[12:16] <quicksilver> LeoNerd: I meant some file or files from a tree might end up being deployed to a visible web page.
[12:16] <quicksilver> for example, you might use bzr as the versioning system for your personal website, etc.
[12:17] <Peng_> sproaty: I don't see that issue, but maybe it's just cuz I have a wide monitor.
[12:18] <LeoNerd> quicksilver: Oh, I see.. Well, again, that's an issue for the surrounding context. My website engine puts last mod date in the page template. :)
[12:18] <quicksilver> LeoNerd: sure, that's a valid solution but it doesn't mean it's the only solution.
[12:18] <quicksilver> LeoNerd: there is no law again a plain static HTML websit eyou know
[12:19] <LeoNerd> No, indeed.. but now you're heading down into really special-cased scenarios
[12:19] <LeoNerd> It's already handled by a plugin in those corner-cases you need it
[12:19] <Peng_> sproaty: I know I've read something about that bug, but I don't know if it's been fixed. And I'm officially AFK, so I don't want to check now. :P
[12:19] <Peng_> sproaty: If you're not running Loggerhead's trunk (lp:loggerhead), it may have been fixed.
[12:19]  * Peng_ shrugs
[12:20] <sproaty> http://bazaar.launchpad.net/~sproaty/whyteboard/development/revision/253
[12:21] <Peng_> Ooh, on the revision page.
[12:21] <sproaty> sorry
[12:21] <Peng_> Pah, I'm AFK, I'm AFK! I refuse to get drawn into work. Especially web design, yuck! :P
[12:25] <sproaty> yeah :(
[12:25] <sproaty> im pair programming with my boss
[12:43] <Peng_> Wait...now I'm recompiling software for fun. I don't think this is working out how I intended. :P
[13:20] <sproaty> so much for AFK :)
[15:02] <GaryvdM> Hi amanica.
[15:02] <amanica> Hi GaryvdM
[15:03] <GaryvdM> amanica: I've finished that fix that I started at the release party.
[15:03] <amanica> sweet
[15:03] <GaryvdM> where if you run bzr qcommit . nothing is selected.
[15:07] <amanica> GaryvdM: I pulled it now, and it seems to work perfectly now. Thanks!
[15:07] <GaryvdM> amanica: Tell me again about that checkbox that you wanted to add to qcommit. What command line option should it add?
[15:07] <amanica> its an option I add with my plugin
[15:08] <amanica> but I've been wondering if commit can support a pre-commit registry
[15:08] <amanica> then we can have a single --force
[15:08] <amanica> which will work for all of these types of pre-commit checks
[15:09] <GaryvdM> amanica:  Does the plugin raise an error if the option is maybe needed?
[15:09] <amanica> yes if my validations fail, I raise an error
[15:09] <amanica> thats how you can stop the commit from going through
[15:10] <GaryvdM> amanica: Ok - I have an idea. Is it a public plugin?
[15:10] <amanica> So I was thinking we can add a --force which will ignore errs thrown by the pre-commit-hook
[15:10] <amanica> yes
[15:11] <GaryvdM> Url?
[15:11] <amanica> bzr+ssh://bazaar.launchpad.net/%7Eamanica/bzr-text-checker/trunk/
[15:11] <GaryvdM> amanica: Cool - I'll take a look.
[15:12] <GaryvdM> amanica: Bye - I'm off to coach at the rink.
[15:12] <amanica> cool thanks, don't worry too much
[15:13] <amanica> I think if the core can support it better, we can know better what I need in qbzr
[15:13] <amanica> bye GaryvdM
[15:13] <amanica> better url: https://edge.launchpad.net/bzr-text-checker
[15:45] <Guest36545> i want to remove a subdir from bzr version control.  'bzr rm (.../subdir)' actually deletes the target.  not what i wanted :-/  how do i do it without deleting it?
[15:46] <dash> bzr rm --keep
[15:47] <Guest36545> same cmd, bur DELETE is the default?  dangerous ...
[15:49] <amanica> Guest36545: it only deletes it if it can be done safely, i.e. it can be recoverd from the revision history
[15:51] <Zathras> hi. what is best (and why): on a shared hosting server with ssh, python, no gcc: virtual python or the system's python? I want bazaar+webfrontend and preferably trac if possible
[15:51] <Zathras> (hoster is awardspace.com (paid))
[15:55] <Peng_> Zathras: Best is if you can convince your host to install all that stuff for you -- and keep it up-to-date.
[15:56] <Peng_> Zathras: Bazaar and Loggerhead (not that it's easy to run in a shared hosting situation, but...) may be a moving target, but at the least they can install all the dependencies, Paste and simplejson and whatnot.
[16:00] <Zathras> like 0 change a hoster will do that and take responsibility....
[16:01] <Zathras> I looked at Git and Mercurial before. Although perl and python based I ran into trouble by not having a C compiler available
[16:01] <Peng_> Git is mostly C,
[16:01] <Peng_> Neither Bazaar and Mercurial require a C compiler; there are Python versions of all of the C bits.
[16:02] <Zathras> Mercurial installer insisted on having a C compiler
[16:03] <Zathras> I was a bit surprised
[16:03] <Peng_> Zathras: You can pass an option so it doesn't.
[16:03] <Peng_> Anyway this ain't #mercurial.
[16:04] <Zathras> yup. Because it did not work for me I started looking at Bazaar. That's why I am asking
[16:08] <Peng_> Heh, well, it should work in Mercurial. make local --pure or somesuch.
[16:08] <Peng_> Although that requires make... Hm. setup.py can do it too.
[16:12] <Zathras> ty
[16:13] <Peng_> Note that Mercurial hasn't supported this forever, but it's been at least a few releases.
[16:59] <NET||abuse> arrrg,,, can't remember how to push a new project up to my webserver
[17:00] <NET||abuse> bzr push bzr+ssh://me@mydomain.com:/var/www/website/src/bzrdir/       does that not do it?
[17:02] <bialix> where is pqm web-front page?
[17:02] <bialix> NET||abuse: ater my.domain should be /
[17:03] <bialix> no :
[17:03] <Peng_> bialix: http://pqm.bazaar-vcs.org/ ?
[17:03] <bialix> Peng_: yep,
[17:03] <Peng_> NET||abuse: Bazaar uses HTTP-style URIs, not SSH or rsync or whatever.
[17:03] <NET||abuse> aoh
[17:04] <bialix> it's strange but pqm.bazaar.canonical.com does not work. yet?
[17:04] <Peng_> Oh, I forgot about the "bazaar.canonical.com" thing.
[17:04] <NET||abuse> yay, worked,, now how long will this take to push.......
[17:04] <bialix> GaryvdM: can you send merge request for my 2.1 clean tree patch?
[17:05] <Peng_> NET||abuse: Depends on your Internet connection, Bazaar version, repo format, and the size of the repo.
[17:05] <NET||abuse> indeed.
[17:05] <NET||abuse> slow enough connection. : )
[17:05] <Peng_> :D
[17:07] <NET||abuse> borrowed wifi from local cafe :)
[17:07] <NET||abuse> 2Mbit if i'm lucky
[17:08] <NET||abuse> hmm, Fetching revisions:Get stream source.... what does that mean?
[17:10] <NET||abuse> it's been sitting on the above message for a good long while.
[17:10] <NET||abuse> the .bzr directory is 58MB
[17:11] <NET||abuse> should it take that long.
[17:11] <NET||abuse> 37 MB of that is in 58 assets files, big gimp and inkscape drawings
[17:12] <NET||abuse> large png's
[17:13] <Peng_> Ah...
[17:13] <Peng_> Yeah, I think that's been fixed.
[17:15] <NET||abuse> arrg,, it just sat there for ages,,
[17:15] <NET||abuse> done nothing
[17:15] <NET||abuse> i canceld out of it, now it says it locked
[17:17] <Peng_> NET||abuse: It wasn't doing nothing. It was waiting for the server to do a bunch of stuff and then start transferring data.
[17:17] <Peng_> NET||abuse: bzr break-lock $the_url
[17:17] <Peng_> NET||abuse: IIRC this has been improved, maybe just in lp:bzr.
[17:17] <NET||abuse> yeh, that worked.
[17:18] <NET||abuse> ah, no, it was actually just doing nothing before, now the push is working
[17:18] <NET||abuse> it's actually Inserting.
[17:18] <NET||abuse> or i hope it is :P
[17:19] <NET||abuse> need a better connection :P
[17:19] <NET||abuse> held up again, probably the assets this time.. it is alphabetical isn't it
[17:20] <NET||abuse> oh shoot,, i have the cakephp docs pdf in there.. what was I doin with that.
[17:20] <NET||abuse> maybe i should ignore assets
[17:20] <Peng_> NET||abuse: How do you know it was doing nothing? Like I said, the server was doing stuff, and the client was waiting for it.
[17:20] <Peng_> That's highly distinct from nothing.
[17:21] <NET||abuse> the server wasn't likely responding as it shot past the same phase it was in last time.
[17:21] <NET||abuse> now it's stuck saying       /     81KB   157KB/s | Fetching revisions:Inserting stream
[17:21]  * Peng_ shrugs.
[17:22] <NET||abuse> i'm on bzr 2.1.1   is that version ok in terms of weirdness?
[17:22] <NET||abuse> stupid me, uploading 14MB pdf.
[17:22] <Peng_> Dunno.
[17:23] <NET||abuse> server is only on 2.0.3
[17:24] <Peng_> 2.0.3 is definitely too old.
[17:25] <NET||abuse> it's also an old ubuntu hardy server
[17:26] <NET||abuse> there we are, got 2.1.0 from update
[17:27] <NET||abuse> ahh, actually .2.1.1.1
[17:31] <NET||abuse> ok, now it's taking ages to get through   "Fetching Revisions:Get Stream Source"   but the remote repo is a bare empty standalone repo
[17:32] <NET||abuse> on the server i just ran bzr init   on a directory, did nothing else.
[17:32] <NET||abuse> now just running bzr push bzr+ssh://me@host/path/to/bzrdir
[17:38] <NET||abuse> nah this is silly, i removed the 14MB file from the assets, and checked in the local bzr repo again.
[17:39] <NET||abuse> running push and it is just sitting on   " \      2KB     0KB/s | Fetching revisions:Get stream source"   for ever, i went off and changed clothes and came back,
[17:42] <NET||abuse> ok, blew away the old bzr dir on the remote server, and re-created it, i've in the interim updated the server bzr from 2.0.3 to 2.1.1,, now when i push to the new bzr directory from my laptop's repo, it is sitting on  /     72KB   140KB/s | Fetching revisions:Inserting stream
[17:42] <NET||abuse> right, i have to go to the shop,,
[17:42] <NET||abuse> it's almost dinner time.
[17:44] <NET||abuse> ok, still no change, exact same readout.
[17:45] <Peng_> I wonder if something is horribly wrong with the server? Like, it starts swapping or something?
[17:45] <Peng_> Do htop or ~/.bzr.log say anything interesting?
[17:45] <Peng_> What about pushing over sftp (or nosmart+bzr+ssh)?
[17:47] <NET||abuse> htop on the remote server?
[17:48] <NET||abuse> hehe, no htop command on my server
[17:48] <Peng_> Install it. It rocks. :D
[17:50] <NET||abuse> Peng_,  ahhhhhhhhhhh it's started doing stuff,,
[17:50] <NET||abuse> veeeeery slowly.
[17:51] <NET||abuse> htop says memory is onlyl 430 of 2011MB
[17:52] <NET||abuse> ok, 17690KB done on the Inserting stream phase,,,,, i'm goin to the shop to get stuff for dinner :)
[17:52] <NET||abuse> Peng_, cheers for that,, htop rules
[17:52] <Peng_> :D
[17:52] <NET||abuse> CPU load is down at 0.7%
[17:52] <NET||abuse> this server has 23 sites on it though
[17:52] <NET||abuse> running quiet
[17:52] <NET||abuse> Swp is 0
[17:54] <NET||abuse> bzr only using 3.1MB
[17:54] <NET||abuse> nice,, love being able to scroll through the processes :)
[17:55] <NET||abuse> and  tree view,, nice
[17:55] <NET||abuse> ooh, f10 doesn't work to exit as it's a shortcut in gnome
[17:55] <Peng_> q exits, IIRC
[17:57] <mtaylor> you guys are generalizing lp-submit from pipelines and putting it in to core, right?
[18:05] <james_w> mtaylor: it's already in the launchpad plugin in the version I have
[18:05] <mtaylor> james_w: ooh neat
[18:05] <mtaylor> james_w: what's the command called now? is it still lp-submit or did it change?
[18:05] <james_w> that's now an alias, along with lp-propose, for lp-propose-merge
[18:06] <mtaylor> omg. that's the best thing I've ever heard
[18:06]  * mtaylor needs to upgrade to new v of bzr
[18:06] <mtaylor> when is 2.2 coming out?
[18:06] <mtaylor> :)
[18:07] <james_w> not sure actually
[18:07] <mtaylor> heh.
[18:07] <mtaylor> well, while I'm bugging you (I'm doing a thing in just a bit showing bzr/launchpad integration...)
[18:07] <mtaylor> is there any way to associate a branch with a blueprint on the cmd line?
[18:08] <Peng_> "python -c 'import launchpadlib; ...'" ? :D
[18:09] <james_w> I don't know of one
[18:12] <mtaylor> hehe
[18:12] <mtaylor> ok. just checking
[18:17] <bialix> mtaylor: august
[18:17] <mtaylor> bialix: sweet. thanks
[18:49] <thrope> is there a download tarball feature for loggerhead yet?
[18:50] <beuno> thrope, no, but there's a branch up for review that I need to get to
[18:50] <thrope> ah ok - it would be really cool!
[18:50] <beuno> it will  :)
[18:50] <beuno> probably not enabled on Launchpad
[18:50] <thrope> has the loggerhead repo moved again? I dont have any updates since nov
[18:50] <beuno> but for other people...
[18:50] <beuno> no, lp:loggerhead
[18:50] <thrope> i am using  http://bazaar.launchpad.net/%7Eloggerhead-team/loggerhead/trunk-rich/
[18:50] <beuno> that should be it
[18:50] <beuno> and there should be updates
[18:51] <thrope> oh wait pull instead of update - too used to using checkouts :|
[18:51] <kojiro> I kinda fail at using bzr+svn. So to pull new stuff from svn, I have to merge, and then commit?
[18:53] <thrope> beuno: my branch has diverged - i have a commit i pulled from michael hudson to fix relative links - is that in main now?
[18:53] <dash> kojiro: if your branch has diverged from the svn branch, yeah
[18:53] <beuno> thrope, I don't know, to be honest
[18:54] <dash> kojiro: it's the same as getting changes from a remote bzr branch. either you pull or you merge.
[18:54] <kojiro> dash: how can I say, "give my working branch the exact same layout as the remote svn repo and nuke all the differences on my side?"
[18:54] <kojiro> I'm just not used to DVCS semantics yet.
[18:55] <dash> kojiro: 'bzr pull --overwrite'
[18:55] <kojiro> aha
[18:55] <kojiro> thanks :)
[18:58] <Peng_> thrope: If Bazaar warns you that it diverged, it means you have revisions that aren't in the branch you're trying to pull.
[18:58] <Peng_> thrope: There's some ancient branch entitled relative-links rotting in the review queue, so I imagine it has not landed.
[18:58] <thrope> yeah it hasnt
[18:58] <Peng_> thrope: Um. There are other neat things, though. And you can probably merge the relative-links branch again.
[18:58] <thrope> its a shame because its quite important
[18:59] <Peng_> Might be conflicts, but..
[18:59] <thrope> im trying to run loggerhead behind ssh
[18:59] <thrope> sorry i mean https
[18:59] <thrope> without relative links everything breaks
[19:00] <Peng_> thrope: I wonder if it would be saner if you ran it through FastCGI instead of a proxy.
[19:00] <Peng_> https://code.edge.launchpad.net/~mwhudson/loggerhead/relative-links/+merge/15298 <-- Oh, look, I reviewed it.
[19:01] <Peng_> And then it sat and rotted.
[19:01] <thrope> yeah I am using proxypass in apache
[19:06] <thrope> it seemed to merge ok into a fresh branch so its working fine for now - thanks
[19:07] <thrope> ill keep an eye out for the tarball update
[19:20] <Peng_> thrope: Thanks for the prod. I'm working on relative-links right now. I think it might actually be trivial to fix the review issues, in which case it might actually get merged someday. :D
[19:21] <beuno> Peng_, you fix it and I'll merge
[19:27] <thrope> cool thanks
[19:32] <Peng_> Fixing the review was easy enough; it's the other potential issues I noticed that are the problem. :-\
[19:52] <Peng_> beuno & thrope: https://code.edge.launchpad.net/~mnordhoff/loggerhead/relative-links/+merge/24767
[19:53] <beuno> Peng_, looking
[19:53] <Peng_> thrope: Y'know, even with the relative-links branch, Loggerhead will still generate absolute links for HTTP redirects and some bits of the feed.
[19:54] <thrope> feed means rss? Im not so worried about that
[19:55] <thrope> i want to run loggerhead behind https with apache user auth... in one case I want https://bzr.domain.com/ and in another i want https://domain.com/bzr
[19:55] <thrope> if theres another way to do it relatively easily I would be happy to try
[19:55] <Peng_> thrope: I wonder if running Loggerhead over FastCGI would behave better.
[19:55] <beuno> Peng_, looks good, land!
[19:56] <thrope> i dont think that was available when I set it up but i will check it now
[19:56] <thrope> going to eat actually but be back in a bit
[19:57] <Peng_> beuno: Alright.
[19:57] <Peng_> thrope: Yeah, FastCGI (and SCGI and mod_wsgi and ...) are a recent addition.
[20:16] <cobalt_mike> is there any document/page besides http://doc.bazaar.canonical.com/bzr.2.1/downloads/pdf-developers/bzr-en-architecture-overview.pdf that describes the bzr architecture?
[20:18] <Peng_> thrope: Anyway, relative-links has landed in lp:loggerhead, so you don't need to go "bzr merge"ing anymore.
[20:28] <kkaefer> hi
[20:28] <kkaefer> is it possible to rename a tag?
[20:28] <kkaefer> To rename a tag (change the name but keep it on the same revsion), run ``bzr
[20:28] <kkaefer>   tag new-name -r tag:old-name`` and then ``bzr tag --delete oldname``.
[20:29] <GaryvdM> kkaefer: yes
[20:29] <kkaefer> ok ;)
[20:29] <kkaefer> answered my own question
[20:29] <Peng_> kkaefer: The old tag won't be deleted when you push to other branches, though.
[20:29] <GaryvdM> kkaefer: :-)
[20:36] <dutchie> is there a way to make a repo smaller? clean up old unused stuff etc
[20:37] <dutchie> ah, bzr pack
[20:52] <Peng_> dutchie: "bzr pack" doesn't "clean up old unused stuff", it just reorganizes (and, in 2a, recompresses) the existing data.
[20:52] <Peng_> dutchie: In fact, since it makes a backup first, you usually end up with twice as much disk space being used.
[20:52] <dutchie> oh
[20:52] <dutchie> how handy
[20:52] <dutchie> though it seems to have made it about 8MB smaller
[20:53] <Peng_> Bazaar doesn't have an equivalent of "git gc".
[20:53] <Peng_> Well, the removing-unused-stuff aspect.
[21:05] <mtaylor> abentley: any chance bzr sync-pipeline could eventually support pushing all of the pipeline branches to launchpad in one command?
[21:05] <abentley> mtaylor, how would that be different from what it does now?
[21:05] <mtaylor> like, bzr sync-pipeline lp:~mordred/drizzle - and it would just push to lp:~mordred/drizzle/${pipe-nick}
[21:05] <mtaylor> abentley: oh - does that work?
[21:05] <mtaylor> wow
[21:06] <mtaylor> the docs didn't make it sound like it would - lemme go try it out :)
[21:08] <abentley> mtaylor, the one difference is that you specify the push location of your current pipe, and it works out the rest.
[21:09] <mtaylor> abentley: neat!
[21:09] <Peng_> "Transferring revisions 0/3029" That can't be good...
[21:09] <mtaylor> abentley: do I still have to lp-submit them individually?
[21:09] <abentley> mtaylor, yes.
[21:10] <abentley> mtaylor, actually lp-submit is now in bzr core, renamed to lp-propose.
[21:11] <mtaylor> abentley: I've heard about that! but that's not going to be released until august I hear
[21:11] <mtaylor> so I can't talk about it in the context of core in the current presentation I'm working on
[21:13] <mtaylor> but I'm quite excited about it
[21:14] <abentley> Hmm.  I guess this is the downside of calling our monthly releases 'betas'.
[21:18] <Phoenixz> Problem: Somebody deleted some files that should not have been deleted. He pushed those changes to my repo, now I dont have those files either. I can see the files with bzr ls -r revision-before-deleting, bzr cat even shows content, but how can I recover those files directly withouth having to copy content one by one using bzr cat? svn has a cp that can do this, but bzr doesnt.. anybody?
[21:19] <Peng_> Phoenixz: "bzr revert"...?
[21:20] <dash> Phoenixz: you can do 'bzr revert -r good-revision', which will change your working copy to match that revision
[21:20] <Phoenixz> dash: ah, that sounds like what I need.. thanks!
[22:00] <lifeless> james_w: AROUND ?
[22:00] <lifeless> bah
[22:00] <lifeless> around ?
[22:00] <jelmer> 'morning lifeless
[22:01] <james_w> lifeless: YES
[22:01] <lifeless> :P
[22:02] <lifeless> how would you feel if I added a dep on testresources to bzr-builddeb?
[22:02] <james_w> it's packaged?
[22:02] <lifeless> (rmadison python-testresources for availability info)
[22:02] <lifeless> build-dep only
[22:02] <james_w> my fingers are already in the IRC window :-)
[22:03] <james_w> yep, I'm ok with that
[22:03] <lifeless> cool, thanks
[23:12] <jelmer> lifeless: if you have a chance, any review of my updated segment-url patch would be much appreciated :-)
[23:12] <lifeless> ok
[23:15] <mwhudson> Peng_: thanks for poking at the relative links thing
[23:23] <Peng_> :)
[23:23]  * Peng_ goes AFK again
[23:26] <thrope> Peng_: thanks... I think maybe it closes this bug https://bugs.launchpad.net/loggerhead/+bug/527330
[23:26] <thrope> I'd also be interested if there is any wsgi /fastcgi info
[23:26] <thrope> or documentation
[23:27] <thrope> I used mod_wsgi at some point and I think it was quite easy to set up... but I can still run 2 seperate loggerhead instances from the same apache
[23:40] <Peng_> Oh, has the mod_wsgi stuff landed yet?
[23:40] <Peng_> Anyway I'm AFK! :P
[23:42] <Guest53807> Is there anyway I can have the actual folder stored in lets say /misc/bazaar/<projectname> but have the branch look like /<projectname> so that I can do bzr push ssh+bzr://myserver.com/projectname ?
[23:45] <Peng_> TuxIce: Yes, but I'm not sure how easy it would be.
[23:45] <TuxIce> Hmm
[23:45] <Peng_> TuxIce: Umm. One of the scripts in contrib/ should help. I think.
[23:45] <Peng_> I swear I'm really AFK! :(
[23:46] <TuxIce> contrib/ in bzr's source?
[23:46] <Peng_> Yeah
[23:47] <TuxIce> Launchpad uses /~ubuntu-art-pkg/+branch/<package>/ubuntu does that mean the home directory ubuntu-art-pkg, folder +branch, folder <package>, folder ubuntu, or are they using clever rewriting or something?
[23:48] <TresEquis> TuxIce: ~ubuntu-art-pkg is the homedir of the team
[23:49] <TresEquis> +branch is a "view" identifier
[23:49] <TresEquis> so it is the "branch" view on that homedir
[23:49] <TuxIce> Yes. But I can't see ~ubuntu-art-pkg/+branch/<package>/... being a file system directory, so I'd assume launchpad somehow rewrites the url?
[23:49] <TresEquis> with '<package>/ubuntu" as the subpath passed to the view
[23:49] <TresEquis> its not on the filesystem
[23:50] <TresEquis> its in an appserver
[23:50] <Peng_> TuxIce: Launchpad uses a custom SSH server.
[23:50] <TuxIce> Oh
[23:50] <Peng_> TuxIce: (Using twisted.conch.)
[23:50]  * Peng_ really goes AFK!
[23:50] <TuxIce> Whats an appserver?
[23:51] <TresEquis> hmm, I thought we were talking about the webserver
[23:51] <TresEquis> the '+branch' bit is a Zope3-ism
[23:51] <TuxIce> Whats a Zope3-ism?
[23:51] <TuxIce> :P
[23:51] <thumper> you don't need +branch
[23:52] <thumper> in fact I'm tempted to remove   the redirect that we have in the code
[23:52] <thumper> it should be issuing permanent redirects
[23:52] <TuxIce> How about +source?
[23:53] <TuxIce> Such as https://launchpad.net/ubuntu/lucid/+source/bzr/ ?
[23:53] <TresEquis> I knew we were talking about a webserver here
[23:53] <TuxIce> Does the bzr command just make an http request?
[23:54] <thumper> TuxIce: that url points to the source package, not a branch
[23:54] <TuxIce> Mmhmm
[23:54] <TuxIce> So launchpad serves up URL's of their own scheme by using a custom ssh server?
[23:55] <TresEquis> bzr+ssh:// URLs would use the twisted.conch things
[23:55] <thumper> TuxIce: yes
[23:55] <thumper> TuxIce: the layout on disk is completely different
[23:55] <TuxIce> Of course
[23:55] <TresEquis> but http:// or https:// are going through an HTTP server, not an SSH server, right?
[23:55] <TuxIce> Thats what I'm attempting to do.
[23:55] <thumper> TresEquis: we have a complex rewrite map program
[23:56] <thumper> TuxIce: jml started to extract the core custom ssh server stuff into a new project
[23:56] <thumper> TuxIce: but I think it stalled
[23:56] <TuxIce> So, If I'm correct, you can branch using an http:// or https:// url, which would pull from a webserver?
[23:56] <TuxIce> I see.
[23:57] <thumper> I think for bazaar.launchpad.net https issues a redirect to http
[23:57] <TresEquis> TuxIce: yes, you can serve branches as static pages via apache
[23:57] <TuxIce> And then to commit+push, you have to communicate with an ssh (sftp to be more correct) server?
[23:57] <thumper> but yes, served by apache with a rewrite
[23:57] <thumper> TuxIce: well, we use bzr+ssh
[23:57] <TuxIce> I see.
[23:57] <TresEquis> TuxIce: it is possible to push over HTTP, if auth is set up
[23:57] <TresEquis> I don't think LP does that, though
[23:58] <thumper> no
[23:58] <thumper> we don't
[23:58] <TresEquis> but loggerhead can be configured to allow it
[23:58] <thumper> configured to allow what?
[23:58] <TuxIce> ANd bzr+ssh is an alternative to sftp, correct?
[23:58] <thumper> pushes?
[23:58] <TresEquis> push over HTTP
[23:58] <thumper> TuxIce: sftp is a dumb file level transport, whereas bzr is the smart server protocol
[23:59]  * TuxIce nods
[23:59] <thumper> TuxIce: bzr can operate directly or over ssh
[23:59] <TuxIce> What do you mean directly?
[23:59] <thumper> TuxIce: as in listening on a particular port (not sure which one)
[23:59] <TresEquis> thumper: bzr:// URLs require running the BZR server process, or putting it in inetd
[23:59] <thumper> TresEquis: yes