[00:15] <fullermd> Does the WebDAV plugin actually work?  I thought it rotted a bit...
[00:16] <lifeless> some yes
[00:18] <fullermd> How much is "some"?
[00:18] <fullermd> Or more contextually; does it still work well enough that we should be talking about it in the User Guide?
[00:19] <lifeless> AIUI the only ting it doesn't do is list_dir
[00:19] <lifeless> of course, packs need that to write :>
[00:19] <lifeless> vila intends to fix that
[00:20] <fullermd> I was sorta under the impression that at its best, it was still unpolished enough to really be "experimental", which makes having it in the Guide we're pointing novices at kinda questionable.
[00:26] <jml> lifeless: is there a way I can get the loom without having to patch bzr?
[00:27] <lifeless> jml: bzr isn't the problem, bzr-loom is, because I haven't pushed the last-loom, because of that bug
[00:28] <jml> lifeless:  is there a way I can get the loom without having to patch bzr-loom?
[00:29] <lifeless> jml: you could use heads() to find the loom tip revision, fetch that, and usethe loom revert api call to do a local loom revert
[00:29] <lifeless> to that specific revision
[00:29] <jml> ok
[00:30] <lifeless> but
[00:30] <lifeless> as I don't know if I've recorded recently
[00:30] <lifeless> and there is a bug here to fix for looms - its marked critical
[00:31] <lifeless> if this is to give me my test
[00:31] <lifeless> just pull the branch, use log to find the last commit on the thread you want to edit, and uncommit to that
[00:35] <jml> lifeless: and pull will get me all of the latest changes, right?
[00:35] <jml> it will get me the top thread?
[00:36] <lifeless> yes
[00:37] <jml> ok. that's probably the most important thing for now.
[00:38] <spiv> lifeless: hmm, PQM seems to have received and then not merged a change from me (it was visible in the web interface, and now it's not there), but I haven't received any email about it.  Are you the right person to ask about what's happened?
[00:39] <spiv> lifeless: (or should I be asking IS?)
[00:40] <lifeless> I get cc'd on cron mail from pqm
[00:40] <lifeless> and the answer is
[00:40] <lifeless> don't submit from a loom
[00:41] <spiv> Ah, d'oh.
[00:41] <spiv> I didn't realise this branch was a loom.
[00:41] <spiv> Thanks.
[00:42] <poolie> lifeless, maybe "partially fused with infinity" would be a good release codename? :)
[00:43] <poolie> night kiko-zzz
[00:44] <kiko-zzz> nite poolie -- take care of the sun for me
[00:44] <kiko-zzz> poolie, btw, https://staging.launchpad.net/bzr -- do you like the latest downloads bit bac just added this release?
[00:50] <lifeless> kiko-zzz: I wonder about having everything split out; it makes the page quite long
[00:50] <kiko-zzz> lifeless, split out?
[00:50] <lifeless> spiv: care to review my revision graph patch ?
[00:50] <kiko-zzz> everything? :)
[00:51] <lifeless> kiko-zzz: have you seen trac's timeline, where everything gets interleaved by time rather than grouped by type
[00:51] <spiv> lifeless: is that the "More deprecations..." one?
[00:51] <kiko-zzz> lifeless, yeah, I think you're thinking what I want to do with that, which is merge those sections and have the timeline include actual stuff that happened and dates
[00:52] <lifeless> spiv: yes
[01:08] <fullermd> igc: ping
[01:08] <jelmer> lifeless: removing get_revision_graph() would be awesome
[01:13] <igc> hi fullermd
[01:13] <fullermd> igc: Hey there.  Got a minute or two to yack about the Guide?
[01:13] <igc> fire away
[01:14] <fullermd> I was looking at the example commands etc, and the conventions used therein.
[01:15] <fullermd> I wondered about the reasoning behind using parenthesized asides to describe things you're doing that aren't directly typing commands, rather than representing them as #'d comments, as is a somewhat standard idiom in such things.
[01:15] <fullermd> Also, the presence (or lack thereof) of prompts before the lines, which is inconsistent; mostly there aren't any, but in some places there are.
[01:15] <ubotu> New bug: #207493 in bzr "bzr crashes during update" [Undecided,New] https://launchpad.net/bugs/207493
[01:16] <igc> fullermd: the lack of prompts is to make the docs less Unix-centric, more friendly to Windows readers
[01:16] <igc> the inconsistency is just slackness
[01:17] <igc> (blah) vs # blah is easy to change and I don't mind either way
[01:18] <fullermd> Hm.  I guess the # convention is a little *nix-y too...
[01:18] <fullermd> I find the lack of prompt a bit disconcerting to read; it's harder to distinguish "I'm supposed to type this" from "bzr will output this".
[01:18] <igc> fullermd: I don't disagree
[01:20] <fullermd> Well, shucks.  You're supposed to provide an "Oh, this is obviously the Right Answer and will solve everything" here.
[01:20] <igc> fullermd: Hmm - hand on while I switch my personality ...
[01:21] <igc> fullermd: I'll solve everything ...
[01:21] <igc> we'll make the tool so obvious that doc isn't required at all :-)
[01:21] <igc> or ...
[01:22] <igc> I can just put prompts in everywhere (and Windows users can feel better by occasionally seeing a Windows one instead of $)
[01:22] <igc> how's that?
[01:23] <fullermd> Well, as a tcsh user, I felt good seeing one '%' prompt in there  ;)
[01:24] <igc> see - it's easier to not have prompts than argue about which one to use :-)
[01:24] <fullermd> Maybe a '>'; it would be more familiarish to Windows users, and *nix people could figure it out.
[01:25] <igc> except that > is continuation in *nix so that does confuse unfortunately
[01:25] <fullermd> Anyway.  Main reason I started thinking about it was on 3.8.9 (correcting a tag), it's not obvious that you're making more revisions before you [re]tag the rev.
[01:26] <fullermd> Maybe we should rewrite that example to use 'tag -r' in both cases, to make it clear that you're changing the rev the tag points at?
[01:28] <igc> or I could add another comment like ... (make more commits to include more fixes)
[01:29] <igc> fullermd: would that do? ^^^
[01:29] <igc> adding -r adds more complexity than needed I feel
[01:29] <fullermd> Hm.  Would be better, I'd say.
[01:30] <fullermd> It still feels a little like it might be unclear unless you already know what it does.  But neither of us is in a very good position to evaluate that, I guess.
[01:31] <igc> fullermd: were there other places where lack of prompts are an issue?
[01:31] <igc> in 99% of cases, having bzr at the start of line is enough clue I think
[01:32] <fullermd> Well, a lot of the earlier stuff which has a lot of output (diff/stat frex) has the prompts.
[01:32] <fullermd> I don't think there was anywhere it really threw me; just that I was already thrown by the tag example seeming to move the tag to where it already was, that I noticed the lack.
[01:33] <fullermd> Should find some Windows people and pin them down in a corner with "Is this confusing?  What would be better" maybe.
[01:34] <igc> yes I should. I just checked some books here on my bookshelf and struggled to find one with a prompt :-)
[01:34] <fullermd> Most of my books don't have very good interpreters anyway   ;)
[01:50] <ubotu> New bug: #207507 in bzr ""bzr commit" empty message error comes too late" [Undecided,New] https://launchpad.net/bugs/207507
[01:55] <spiv> lifeless: I'm reviewing your branch btw, but I'll finish it after lunch.
[01:58] <lifeless> ok
[02:00] <lifeless> spiv: I'm 2 ahead now :>
[02:00] <ubotu> New bug: #207512 in bzr "bzr merge --preview fails when uncommitted changes" [Undecided,New] https://launchpad.net/bugs/207512
[02:33] <abentley> poolie: what's the state of the PPA?
[02:34] <poolie> abentley: still on 1.2 i believe
[02:36] <abentley> I'm concerned about the delay getting 1.3 up there.  I wish I knew enough about debian packaging to help out.
[02:37] <poolie> i'll ask if someone else will help
[02:38] <abentley> Good idea.
[04:54] <lifeless> k, done
[04:57] <jdong> lifeless: cool! with bzr? It's finished? ;-)
[04:59]  * TFKyle would hope not, a project being finished is like a death sentence
[05:02] <jdong> lol I was just joking. It's just that was a really out-of-context "k, done" :)
[05:04] <TFKyle> true
[05:36] <bob2> can someone try 'bzr branch http://bazaar.launchpad.net/~rmurri/vc-bzr/trunk/ b' with head?
[05:45] <spiv> bob2: Yeah, I seem to have broken it.
[05:46] <spiv> bob2: I'm looking at the problem right now.
[05:47] <spiv> bob2: a temporary workaround is to delete the get_shared_method method from bzrlib/transport/http/__init__.py (e.g. by renaming it to XXXget_shared_medium).
[05:47] <luislavena> hello guys
[06:40] <ubotu> New bug: #207557 in bzr "Print versions of manuals requested" [Wishlist,Triaged] https://launchpad.net/bugs/207557
[06:45] <ubotu> New bug: #207558 in bzr ""bzr branch http://bazaar.launchpad.net/...." fails with bzr.dev >= r3309" [Critical,In progress] https://launchpad.net/bugs/207558
[06:59] <Peng> Oh, good, I'm on r3308.
[07:03] <Peng> Ooh, bzr+http auto-detecting?
[07:03] <Peng> Huh.
[07:04] <Peng> It takes bzr+http like 500 requests to find out there's nothing new to pull, vs. about 6 for http.
[07:09] <Peng> Ok, 9 for http vs. 25 for bzr+http.
[08:13] <jrydberg__> it's amazing how infected the choice of version control system has become.
[08:13] <jrydberg__> it's like mac vs pc vs amiga vs atari all over again.
[08:14] <igc> night all
[08:18] <TFKyle> jrydberg__: referring to the OS or hardware?
[08:19] <TFKyle> hardware-wise I wonder what bzr would be equiv to, isn't too minimal so not really a RISC, x86 is probably subversion or cvs though
[08:21] <TFKyle> hmm, ruling out all of RISC might not be fair
[09:03] <Kinnison> Morning
[10:54] <fbond> Hi, I'm committing a large file (500MB or so) and bzr is taking up plenty of memory but is using minimal CPU.  It's been doing this for 8 hours or so.  Should I kill it?
[10:59] <Peng> fbond: Why did you do that?
[10:59] <Peng> fbond: You do have 10 or 15 GB of RAM, right? Otherwise... :P
[11:24] <chadmiller> Gods, pulling the last three weeks of bzr.dev using http is slow.
[11:25] <chadmiller> I can't believe that the developers use this same method, or this would be fixed by now.
[11:28] <Odd_Bloke> chadmiller: I suspect the majority of the developers don't leave three weeks between their bzr.dev updates. :p
[11:30] <chadmiller> Agreed.  This is a common case for casual developers, though.  /Somebody/ should.
[11:36] <mr-russ> hi, I have a bzr local branch.  I want to make it not a branch so I can start the commit history again.  is that done by rm -r .bzr ?
[11:37] <spiv> chadmiller: 1m 39s here, and I'm on the other side of the planet to the HTTP server.  Only 51s if I use bzr+ssh://bazaar.launchpad.net/~bzr/bzr/trunk instead of http://bazaar-vcs.org/bzr/bzr.dev/.  That's fetching 309 revisions.
[11:38] <james_w> mr-russ: yes, that will remove all of the bzr metadata from the branch. Be sure that is what you want to do first thoug
[11:38] <james_w> for instance that will mean that you can no longer merge any other branches of that code that exist
[11:39] <mr-russ> james_w: that's fine.
[11:39] <mr-russ> I have a CVS checkout from another project.  I want a local bzr branch on top for my own development.
[11:39] <mr-russ> I messed up the import by building for and having binaries and stuff I didn't want.
[11:39] <mr-russ> s/for/first/
[11:40] <mr-russ> so thanks for the information.
[11:40] <james_w> chadmiller: are you pulling from launchpad or bazaar-vcs.org?
[11:41] <james_w> mr-russ: no problem
[11:41] <chadmiller> spiv: That was, according to my .bzr.log, 21 minutes .
[11:41] <spiv> chadmiller: that's not normal, then.
[11:41] <spiv> chadmiller: is your local branch in pack-0.92 format?
[11:41] <mr-russ> james_w: Is that question documented somewhere?
[11:42] <chadmiller> james_w:  [u'pull', u'http://bazaar-vcs.org/bzr/bzr.dev/']
[11:44] <james_w> yeah, that's probably re-annotating isn't it?
[11:44] <chadmiller> spiv: My local branch is in whatever format you get when you follow the directions on the web site.
[11:45] <Odd_Bloke> chadmiller: When did you follow those instructions? :)
[11:45] <spiv> chadmiller: "bzr info" should tell you
[11:45] <chadmiller> It's dirstate
[11:45] <spiv> chadmiller: ah, yep, that's the problem
[11:45] <chadmiller> Odd_Bloke: ~3 months ago, I think.
[11:45] <spiv> chadmiller: you need to bzr upgrade your local branch.
[11:45] <james_w> should we print a warning to users when this happens?
[11:46] <james_w> perhaps there should be a message on autopack as well?
[11:46] <spiv> chadmiller: it's taking so long because bzr is converting revisions between formats, and converting from packs to knits is particularly slow as it has to calculate annotations for every line changed in every revision.
[11:46] <james_w> chadmiller: bzr upgrade --pack-0.92 in your local branch
[11:46] <spiv> james_w: yeah, I think a message when using a particularly expensive InterRepo is probably a good idea.
[11:47] <spiv> chadmiller: so you're right, the developers don't put up with this :)
[11:48] <james_w> spiv: I'll mail the list
[11:48] <chadmiller> Yeah, I don't really need help, personally.  I'm acting as the average user gadfly, and pointing out problems, as most people who are interested in trying Bazaar aren't going to come to the IRC channel.
[11:50] <spiv> chadmiller: makes sense.  Thanks for the report.
[11:50] <mr-russ> in bzr status, what does the @ symbol at the end of the filename mean?
[11:50] <james_w> symlink
[11:50] <mr-russ> ah
[11:51] <spiv> Hmm, neither "bzr help status" nor "bzr help status-flags" mentions that.
[11:52] <james_w> There's * for executable as well I think
[11:52] <mr-russ> that is why I'm asking :)
[11:52] <james_w> spiv: shall I file a bug, or are you already writing the patch? :-)
[11:52] <fullermd> Well, it doesn't mention / for dirs either.  I figured it was just assumed.
[11:53] <mr-russ>  / is normal for dirs, is it modelled from bash, does it use @ and *?
[11:53] <spiv> james_w: it's late here, please file a bug for me :)
[11:53] <fullermd> It's been SOP in ls since, like...   I don't know.  The 70's, maybe?
[11:54] <james_w> spiv: sure
[11:54] <mr-russ> well, ubuntu uses colors by default, so I understand those, not @ and *.
[11:55] <james_w> I still need to add -F here
[11:56] <mr-russ> that implies you know bash fugu and how it applies to bzr to understand it :)
[11:57] <spiv> mr-russ: technically, it's nothing to do with bash, just /bin/ls
[11:57]  * fullermd doesn't use bash at all   :p
[11:57] <mr-russ> I can't say I would have ever made the link.
[11:57] <mr-russ> I can file a bug in launchpad if nobody else is able.
[11:59] <james_w> mr-russ: I'm on it, thanks
[12:00]  * mr-russ can't believe an annoying question resulted in a bug.
[12:01] <TFKyle> spiv: hmm, thought bash could optionally builtin ls, doesn't look like it from man bash here though
[12:02] <TFKyle> (think busybox does though)
[12:07] <spiv> james_w: thanks for being my bug filing machine for the evening :)
[12:07]  * spiv -> bed
[12:07] <james_w> night spiv
[12:10] <ubotu> New bug: #207687 in bzr "bzr help status-flags should list * @ and / as well" [Undecided,New] https://launchpad.net/bugs/207687
[13:10] <ignas> how do I list all the changes (like missing does) since some tag or between 2 tags instead of 2 branches
[13:11] <luks> bzr diff -r tag:tag1..tag:tag2 ?
[13:11] <luks> or bzr st if you only want a list of changed files
[13:11] <bob2> "bzr help revisionspec" lists all the ways to specify revisions
[13:12] <ignas> luks: i htink missing only gives me "log like" summary
[13:12] <ignas> as in - commit messages
[13:12] <luks> bzr log then
[13:13] <ignas> oh
[13:13] <ignas> cool
[13:13] <ignas> thanks
[13:24] <unenough> l'question
[13:25] <unenough> I have a repository, and I worked on it in another computer but without the .bzr, so I created a new repository there using files from some revision of the first repo.
[13:26] <unenough> how can I merge these two (the second repo is really a continuation of the first, and only has 2 revisions in it)
[13:28] <Peng> bzr merge? bzr pull?
[13:28] <unenough> well I could have guessed it involves one of those....but i want to be sure i'm not messing up
[13:29] <bob2> if you created a new branch without using bzr (i.e. re-bzr-add'd the files), then they'
[13:29] <bob2> 're not related and merge/pull won't work
[13:31] <unenough> what's worse, i've opened the .tar.gz of the new repo (and cd'd into it) and bzr info says that there is no repo in the current directory.
[13:31] <unenough> even though there IS a .bzr directory
[13:31] <unenough> nvm, i'll try upgrading bzr, i think it's an old version.
[13:32] <Peng> It's possible the .bzr directory doesn't include a repo.
[13:32] <bob2> did you reimport the files into a freshly created branch?
[13:32] <Peng> Um, tar is not really the correct way to transfer bzr data around..
[13:32] <bob2> and does bzr say only that, or does it think the dir is a checkout?
[13:32] <unenough> bzr: ERROR: No repository present:
[13:32] <unenough> ...
[13:33] <unenough> (... = path)
[13:33] <unenough> Peng so how should I do that?
[13:33] <luks> unenough: you are confusing the terms branch and repository
[13:34] <unenough> uh, right! that's the problem
[13:34] <unenough> I forgot that in the other computer it's under a shared repository
[13:34] <luks> it's hard to tell what's actually repository and what is a branch from your question
[13:35] <unenough> ok, thanks. it's not such a big deal in this case (i knew it wouldn't really matter that's why i messed around so much)
[13:35] <Peng> unenough: Use pushing and pulling.
[13:35] <Peng> unenough: You have ssh on the machines, right?
[13:35] <unenough> Peng: It's the same computer, it has linux-windows schizophernia
[13:35] <Peng> Oh.
[13:36] <unenough> i'm creating now a FAT32 (oh dear) partition so I can share data safely
[13:39] <chadmiller> I was shocked recently to discover that the best filesystem to use on a USB key for my linux and OSX machines was NTFS.
[13:39] <unenough> wtf?!
[13:39] <bob2> the ntfs fuse stuff is pretty good
[13:39] <Peng> That reminds me, I've been meaning to ask someone what file system to use on a (Linux-only) USB stick.
[13:40] <Peng> (Hint hint? :P )
[13:40] <bob2> ext2
[13:41] <chadmiller> Linux doesn't grok OSX ufs, and OSX doesn't grok EXT2.  I don't trust FAT.  Neither claims to support NTFS, but it worked.
[13:43] <Toksyuryel> it is just plain stupid not to support ext file systems, since they are freely available to impliment by anyone =/
[13:44] <Toksyuryel> but hey, that's apple for you
[13:44] <Toksyuryel> they don't support vorbis on the ipod either x.x
[13:45] <ubotu> New bug: #207730 in bzr "SFTP access fails on MacPorts/Leopard installation (SSHSubprocess object has no attribute get_name)" [Undecided,New] https://launchpad.net/bugs/207730
[13:48] <mw-home> yeah, i don't think i'll ever buy a mac.
[13:56] <ubotu> New bug: #207734 in bzr "push on bzr+http, pycurl fails with: necessary data rewind wasn't possible" [Undecided,New] https://launchpad.net/bugs/207734
[14:03] <Peng> Yeah, but aren't there file systems better designed for how USB sticks work?
[14:03] <Peng> Wear-levelling, the lack of seek latency, whatever.
[14:03] <fullermd> Eh.  USB flash sticks are like CF; they implement wear-levelling internally.
[14:07] <Pengwn> I have been using bzr on windows and very much impressed with the bzr serve and bzr pull options. any thing latest happening with bzr serve ?
[14:08] <Pengwn> like plain text password login something like bzr pull  bzr:://remotehost:4155:<password>/myhome/mybranch
[14:10] <Pengwn> I am also trying to find a linux32 runnable version without all the python etc, etc install process like an .exe on windows. Is it out there somewhere?
[14:11] <james_w> Pengwn: sorry, I don't quite get what you are after.
[14:11] <Pengwn> Actually Two things.
[14:11] <Peng> Pengwn: If you have Paramiko and whatnot installed, all you have to do is download the tarball.
[14:12] <james_w> is the first question whether there are plans to add authentication to the bzr:// server?
[14:12] <Pengwn> yep.
[14:12] <james_w> it's been discussed, but there's no work on it yet.
[14:12] <Pengwn> I had a discussion before with some one but I am not looking into ssh and other setup methods.
[14:12] <james_w> some people aren't too keen, but as it is requested a lot it may well happen eventually
[14:12] <Pengwn> some the simple.
[14:13] <Pengwn> something simple.
[14:13] <james_w> and as Peng says you just need the tarball if you already have python installed.
[14:13] <Peng> fdisk says my USB stick is formatted as FAT16. Nice.
[14:13] <Pengwn> just so that some second person cannot just pull from by bzr serve.
[14:13] <Pengwn> I have python 2.4 on the server installed and I cannot mess that up.
[14:13] <james_w> I'm starting to think that merge sort may not be harder than topo sort:
[14:13] <james_w> bzr mlog  0.89s user 0.04s system 100% cpu 0.924 total
[14:14] <bob2> Pengwn: you won't mess it up, you can run bzr from the directory the tarball unpacks to
[14:14] <james_w> that's the time to display the first merge sorted revision
[14:14] <Pengwn> oh really. cool.
[14:15] <fullermd> In what tree?
[14:16] <james_w> bzr.dev
[14:17] <james_w> it can probably be speeded up, but it doesn't do revision numbers yet
[14:17] <james_w> and the indentation is slightly different, as I can't work out the exact rule the original uses.
[14:17] <james_w> it doesn't indent merged revisions on some occasions
[14:18] <Pengwn> is this the tar ball : bzr-1.2.tar.gz from bazaar-vcs.org ?
[14:18] <james_w> there's 1.3 now, you should use that.
[14:18] <james_w> http://bazaar-vcs.org/releases/src/bzr-1.3.tar.gz
[14:19] <Pengwn> but by windows is on 1.2 is that ok ?
[14:21] <Pengwn> $ pwd
[14:21] <Pengwn> /home/duper/bzr-1.2
[14:21] <Pengwn> bash-3.00$ find . -name python
[14:21] <Pengwn> bash-3.00$
[14:21] <Pengwn> no python in that tar ball ?
[14:21] <Pengwn> python installed on server is 2.3.4
[14:21] <bob2> no, it does not include python
[14:22] <bob2> you said you had "python 2.4" installed, above
[14:22] <Pengwn> yep sorry my mistake.
[14:22] <james_w> Pengwn: do you have /usr/bin/python2.4?
[14:22] <Pengwn> I actually need a tar ball with everthing in it then :)
[14:22] <Pengwn> nope.
[14:23] <bob2> 2.3 is ooooold
[14:23] <james_w> I don't think one of those tarballs exists for linux
[14:24] <Pengwn> any links on how to install bzr as user then ?
[14:24] <bob2> that's not your problem
[14:24] <bob2> you need to install /python/
[14:24] <Pengwn> that's the problem I cannot mess up the server .
[14:25] <Pengwn> I have only user access on the linux box.
[14:25] <Pengwn> hmm git got setup well. so something like that for bzr ?
[14:26] <bob2> ask whoever installed or compiled git to install python2.4
[14:27] <Pengwn> me compiled git and install to ~/bin :-)
[14:28] <james_w> why don't you do that with python?
[14:29] <Pengwn> yep have to I guess. just thought I might get the procedure layed out here for :)
[14:29] <Pengwn> me.
[14:33] <Peng> FWIW, compling Python in your homedir is pretty easy.
[14:33] <Peng> compiling*
[14:34] <Pengwn> Really?
[14:34] <Pengwn> I just checking it out.
[14:34] <Peng> Except, it often wound up without support for things like bzip2 and readline, thanks to the system not having the proper headers installed.
[14:34] <Peng> But it still mostly worked.
[14:36] <Pengwn> http://docs.python.org/inst/search-path.html
[14:36] <Pengwn> looks like ti.
bzr "-d path_to_branch", "path_to_branch" and "you must cd to path_to_branch" inconsistency is bugging me</rant>
[14:39] <ignas> bzr missing and bzr nick want you to be in the directory, a lot of commands want -d before directory you want the operation to be performed on (tags, push, tag)
[14:40] <ignas> and some commands can handle the path given as a plain parameter
[14:40] <Pengwn> Peng did you install it or just set you path to the the untarred location ?
[14:40] <Peng> Pengwn: Installed it.
[14:40] <Pengwn> oh ok.
[14:40] <james_w> ignas: it used to be that nothing had -d, and so all but a few commands required you to be in the directory.
[14:40] <ignas> like co and ci for example
[14:40] <Pengwn> have you tried with settting just the path ?
[14:40] <Peng> Pengwn: If you've compiled Python in your homedir and use that version of Python to run setup.py, it'll go in the right place automagically.
[14:41] <Peng> Pengwn: Yes.
[14:41] <james_w> ignas: if there are commands that don't have it and you want it then please file bugs
[14:42] <ignas> james_w: filing a good bug report is a lot more difficult than ranting :/ i don't have a bzr checkout of both bzr tools and bzr to check if the bug is still there in the newest version, and don't have the time now to checkout and build them
[14:43] <Pengwn> oh ok. where are the .c file for python ?
[14:43] <Pengwn> and makefile dist?
[14:43] <Pengwn> ok I will check it out.
[14:44] <james_w> ignas: if you list the commands I can check for you
[14:45] <ignas> missing and nick
[14:45] <james_w> but if you just want to rant, go ahead :-p
[14:45] <Pengwn> Peng: will the module search path get updated or is there an option during make of the python binary?
[14:46] <james_w> there was a bug filed on nick the other day asking for setting remotely, so that will probably cover it
[14:46] <Peng> Pengwn: What?
[14:46] <james_w> missing still doesn't have it
[14:46] <Peng> Pengwn: Just install Python and then use "python setup.py install" (assuming "python" is your installation).
[14:46] <Pengwn> for the import command usually there's predefined paths like /usr/local/bin or /usr/local/lib/python2.3.4. etc ?
[14:46] <james_w> ignas: so add a comment to https://bugs.launchpad.net/bzr/+bug/180297 for nick
[14:46] <ubotu> Launchpad bug 180297 in bzr "no way to read the nick of a remote branch" [Low,Confirmed]
[14:47] <Pengwn> import keyword i.e.
[14:47] <Peng> Pengwn: Yes, they're relative to the installation. If you install it in ~/local, they'll be ~/local/lib/python2.5 etc.
[14:47] <ignas> james_w: cool, thanks
[14:47] <Pengwn> oh cool.
[14:48] <james_w> ignas: I can't find one for missing, so go ahead and file one
[15:00] <hsn_> are there plans to make versioned properties? We need some way how to edit commit messages
[15:01] <ignas> james_w: ok, reported
[15:01] <james_w> thanks
[15:01] <james_w> hsn_: I think it's been discussed, but I don't know what was decided
[15:06] <ubotu> New bug: #207762 in bzr "missing does not accept "-d" parameter" [Undecided,New] https://launchpad.net/bugs/207762
[15:40] <ignas> hmm, bzr log -r tag:some_tag gives me a list of changes including the change that added the tag
[15:40] <ignas> how do i list only changes that happened after it
[15:40] <ignas> thus would be missing if i would checkout the tag
[15:41] <dato> ignas: try -r tag:foo..
[15:41] <ignas> it includes the revision foo was added
[15:42] <dato> try -r after:tag:foo..
[15:42] <ignas> bzr: ERROR: No namespace registered for string: u'after:tag:0.0.1'
[15:43] <dato> bah
[15:43] <dato> I thought that existed
[15:43] <ignas> i thought so too, it works in my tests
[15:43] <ignas> when executed from python
[15:44] <ignas> ok, it does not
[15:44] <ignas> just that i was ignoring errors
[15:44] <dato> right
[15:44] <dato> ignas: so
[15:44] <dato> ignas: what's so bad about -r tag:foo.. ?
[15:45] <ignas> it works but it includes the tag:foo revision
[15:46] <ignas> the point is listing all the new things since the last release
[15:46] <ignas> it always shows at least one change with tag:foo
[15:46] <ignas> and that change is included in the release that was made from that tag
[15:50] <fullermd> I don't think after: has ever existed; it's ill-definable...
[15:50] <james_w> I think there is a case for excluding the lower bound though
[15:50] <james_w> then if you wanted it you could use before:
[15:51] <ignas> i kind of understand the technical issues with after:
[15:52] <ignas> otoh - i still have to think of how to list all the changes made to a branch the way missing does
[15:52] <fullermd> Mmm.  This is where git's XOR-ish syntax is handier than bzr's range syntax....
[15:52] <ignas> without checking out the tag
[15:52] <ignas> and doing bzr missing
[15:55] <Peng> Hmm.
[15:56] <abentley> I don't think there's a technical reason why missing can't support -r specifiers.  But no one's done it yet.
[15:56] <fullermd> Syntax gets sticky.
[15:57] <fullermd> Seems to be a recurring burr...
[15:57] <ignas> abentley: with bzr log i can do that without a checkout even i think
[15:59] <abentley> I'm pretty sure log just requires a branch, not a checkout.
[15:59] <abentley> And similarly with missing.
[15:59] <ignas> you have to have a checkout to do missing
[15:59] <ignas> you do missing on a branch
[15:59] <ignas> but to use missing you have to cd into a checkout you are comparing the branch with
[16:00] <ignas> so to do what i need i had to - bzr co -r tag:foo some_branch some_dir && cd some_dir && bzr missing some_branch
[16:01] <ignas> becauze bzr log -r tag:foo.. gives me the foo revision while missing tells me that nothing has changed, or just lists all the new things that have been commited after the release
[16:02] <fullermd> Well, the simplest thing is a way to differentiate inclusive and exclusive bounds.
[16:02] <fullermd> (conceptually simplest, that is)
[16:02] <ignas> yep
[16:03] <ignas> i kind of expected some manual about ".." things
[16:03] <ignas> that would include other kinds of dots ;)
[16:03] <ignas> like :. and .: ;)
[16:06] <abentley> ignas: No, you don't.  You need a local branch.  It doesn't have to be a checkout.
[16:07] <ignas> abentley: something you can "chdir" to from what I understand
[16:08] <ignas> and even so: if i want to check versus a tag - i have to checkout that tag
[16:08] <abentley> ignas: Right.  Local, but not necessarily a checkout.
[16:08] <abentley> You don't have to checkout that tag.  You can make a branch of that tag.
[16:10] <ignas> abentley: is there a big difference ? like in time/space as i am deleting it immediatelly after i do the missing thing
[16:10] <abentley> Yes.  Creating a treeless branch in a shared repository is virtually instant.
[16:11] <abentley> Creating a checkout necessarily requires building a working tree.
[16:11] <ignas> abentley: i wouldn
[16:11] <ignas> i wouldn
[16:11] <ignas> i wouldn't want to create stuff in the repository
[16:11] <ignas> when running the release scripts
[16:12] <jelmer> abentley: hi
[16:12] <ignas> and especially when I am not running them
[16:12] <abentley> ignas: Well, that's your own lookout.
[16:12] <abentley> jelmer: Hi.
[16:12] <ignas> and just querying for "something has changed?"
[16:12] <jelmer> abentley: I'm trying to get merge_sort() to work with multiple branch tips - is there some easy workaround for that?
[16:13] <abentley> jelmer: If you create a fake revision that merges the tips, you should be able to merge sort that.
[16:13] <ignas> abentley: i feel safer when queries are not be creating anything in the central repository
[16:13] <james_w> ignas: it would probably be relatively straightforward to do in python
[16:14] <abentley> ignas: Well, if you're that paranoid about creating branches in your central repository, you can use a different repository.
[16:15] <ignas> abentley: it's not paranoia, i mean - you wouldn't like bzr log creating branches in the central repository ...
[16:16] <abentley> But we're not talking about log, we seem to be talking about release scripts.
[16:17] <ignas> well - we were, up until the point where I understood that while scripts do add branches the "check for missing revisions part" is for the UI
[16:17] <ignas> and is not related to the release process
[16:18] <ignas> i was too ambiguous about it when i wrote the "when I am not running release scripts" part
[16:18] <ignas> sorry
[16:18] <abentley> Well, whatever your reasons, you *can* use a separate repository for the purpose.  Our you can submit a small patch to bzr.  Or write a plugin.  The choice is yours.
[17:02] <james_w> hmm, I was wrong, I do need to make the algorithm whole history.
[17:11] <brandon_rhodes> I'm trying to use bzr-svn to check out from a Subversion repository that's over https: and protected by kerberos tickets
[17:11] <brandon_rhodes> I've run kinit to my user successfully, and "svn ls" can see the branch just fine
[17:12] <brandon_rhodes> But "bzr co ..." of the same URL returns: bzr: ERROR: Invalid http response for https://svn.oit.gatech.edu/base/mage/trunk/.bzr/branch-format: Unable to handle http code 401: Authorization Required
[17:12] <jelmer> brandon_rhodes: see the faq
[17:12] <brandon_rhodes>  
[17:12] <jelmer> brandon_rhodes: prefix the URL with svn+
[17:13] <brandon_rhodes> jelmer: Thank you!  That worked!!!  ... The FAQ at http://bazaar-vcs.org/BzrForeignBranches/Subversion/FAQ ?  I read the whole thing :-/
[17:17] <dasch_> schierbeck: hey
[17:18] <schierbeck> dasch_: hello
[17:19] <jelmer> brandon_rhodes: no, the one in the soruce tarball
[17:19] <jelmer> brandon_rhodes: I'll remove the one on the wiki, it's out of date
[17:19] <brandon_rhodes> jelmer: Well, drat!  Why are there two?  And I tried to be such a good citizen :-)
[17:29] <jelmer> hmm
[17:29] <jelmer> schierbeck is talking to himself over IRC ? :-)
[17:39] <schierbeck> jelmer: hehe
[17:39] <schierbeck> just testing out pidgin's support of irc
[17:45] <ubotu> New bug: #207858 in bzr "bzr status dumps errors" [Undecided,New] https://launchpad.net/bugs/207858
[18:14] <clarby> hmm, I'm having a lot of toruble with bzr 1.3, right now I'm getting "PathNotChild: Path "/home/<user>/featured/Untitled-5.gif" is not a child of path "/home/code/<project>" when trying to update my project. What can I derive from that?
[18:18] <Odd_Bloke> clarby: Is there anything further in ~/.bzr.log?
[18:18] <clarby> nope
[18:26] <rexbron> I am having an intereting problem with bzr-svn. when I try and checkout or branch from a svn repo via http:// or http://, I get a "Not a branch" error but the repo is setup so that svn:// is for commit access. Is there a way I can force bzr to use bzr-svn on this specific url?
[18:30] <james_w> svn+http://
[18:31] <rexbron> james_w: Tried that, same error messagebzr: ERROR: Not a branch: "svn+https://svn.blender.org/svnroot/bf-blender/trunk/blender".
[18:33] <rexbron> could be an actual issue with the svn repo
[18:34] <rexbron> nope, I can access the branch fine via the web
[18:38] <rexbron> james_w: I think it might have something to do with blender.org using ssl certs
[18:38] <james_w> rexbron: I think you should file a bug.
[18:38] <james_w> that may be it, is there http:// access?
[18:39] <james_w> nope
[18:39] <rexbron> james_w: http:// redirects to https://
[18:40] <rexbron> when I do a co with svn directly, it asks me to reject accept temp or accept permanently the cert
[18:42] <james_w> every time?
[18:46] <rexbron> james_w: Just the first time IIRC
[18:47] <james_w> well if you accept permanantly the idea is that bzr-svn will then be able to use that.
[18:48] <james_w> or perhaps that's a bug in some versions of svn
[18:48] <james_w> what version are you using?
[19:12] <yacc> rexbron: what URL are you using for https?
[19:13] <yacc> rexbron: straight https or svn+https with bzr?
[19:13] <yacc> rexbron: hint: if you use the straight version without prefixing it with svn+, bzr itself does access the URL via pycurl, which does it's own certificate validation.
[19:15] <Odd_Bloke> If that is the case, then urllib+https:// might work.
[19:22] <yacc> Odd_Bloke: it's not necessary. svn+https signals that it's work for bzr-svn, and that means that it goes they => svn => Neon path.
[19:27] <brandon_rhodes> Does the GTK browser have a way to do a blame, or to look at the change history of just one file?
[19:28] <brandon_rhodes> A friend wants an alternative to Trac for browsing repositories, but I haven't found anything else that makes it as easy to hop between a file's history and its content and the full change history
[19:29] <jelmer> "bzr gannotate"
[19:31] <brandon_rhodes> jelmer: Neat!  Now once I've brought up a changeset, and it shows three files, how do I jump back "into" one of the other files?
[19:32] <jelmer> brandon_rhodes: there's no way to do that yet at the moment
[19:32] <brandon_rhodes> Well, drat, maybe I'll be installing Trac for him anyway :-)
[20:46] <deepjoy> is http_smart_server.txt in the userguide the correct place to look for configuring a bzr+http server?
[20:46] <deepjoy> it seems to refer to things that I can't find
[20:46] <deepjoy> for example bzr-smart.py
[20:46] <deepjoy> where  is this file?
[20:47] <jelmer> there is a bzr http smart server?
[20:49] <deepjoy> Hi there. if you are asking that the text file exists. yes it does in 1.2 at least.
[20:50] <deepjoy> jelmer:  I didn't understand you question.
[20:50] <jelmer> deepjoy: I was just surprised to hear there is something like a http smart server
[20:51] <deepjoy> ok
[20:51] <jelmer> ah, it's still experimental, etc
[20:52] <deepjoy> yes
[20:52]  * fullermd blinks.
[20:52] <fullermd> There's been a http smart server as long as there's been any other smart server...
[20:53] <fullermd> It's just that setting it up is apparently an exercise in mass aggravation, and it seems too inflexible to be used any way I'd particularly want to.
[20:53] <deepjoy> basically authentication via ssh is a problem for most people trying this out
[20:53] <deepjoy> mod_auth is much more flexible in what it talks to
[20:55] <jelmer> fullermd: well, it's also still insecure
[20:55] <jelmer> as opposed to the "normal" smart server
[20:55] <fullermd> I don't think it's any more insecure than any other SS.
[20:56] <Peng> AFAIK, that "insecure" and "experimental" comment is really out-of-date.
[20:56] <Peng> And it's less of an exercise in mass aggravation since the path bug was mostly fixed.
[20:56] <deepjoy> 1.2 and 1.3 had noted speed improvements in bzr+http
[20:56] <Peng> Well, fixed some amount.
[20:56] <Peng> Enough for it to work for me. :D
[20:56] <fullermd> I still can't config it   :p
[20:56] <Peng> Oh?
[20:57] <Peng> What's wrong?
[20:57] <deepjoy> the path bug that was 1.1 right?
[20:57] <fullermd> All the hardcoded paths.
[20:58] <deepjoy> Peng: so where did you get bzr-smart.py?
[20:58] <Peng> deepjoy: Yuhh, http_smart_server.txt I think.
[20:59] <deepjoy> ah
[20:59] <deepjoy> Peng: thanks
[21:00] <Peng> Also, I named it "bzr-smart.cgi", but I'm a bad person.
[21:00] <fullermd> You did WHAT?!
[21:00] <deepjoy> so you are using fast cgi and not mod_python
[21:00]  * fullermd calls in the SWAT team.
[21:01] <Peng> Yeah, FastCGI.
[21:01] <Peng> I'm on shared web hosting with no mod_python.
[21:01] <Peng> (Now *that's* an exercise in aggravation.)
[21:02] <Peng> (I used to use regular CGI for it. It's not like my bzr+http ever gets any hits, so FastCGI would just be wasting RAM.)
[21:03] <deepjoy> next question : http://trac.pocoo.org/wiki/ModPyWsgi does not exist as before
[21:03] <Peng> ModPyWsgi?
[21:03] <deepjoy> which project from http://dev.pocoo.org/ do I need to install?
[21:03] <Peng> Not mod_wsgi?
[21:04] <deepjoy> so http://code.google.com/p/modwsgi/ then?
[21:05] <deepjoy> the text file in the release still says http://trac.pocoo.org/wiki/ModPyWsgi
[21:05] <Peng> Yeah, ModPyWsgi seems to be a different thing, related to mod_python.
[21:05] <Peng> You should check out mod_wsgi though.
[21:05] <ubotu> New bug: #207959 in bzr "Assertion error after a case sensitivity clash" [Undecided,New] https://launchpad.net/bugs/207959
[21:06] <deepjoy> it seems to be 2 implementations of the same thing
[21:06]  * Peng shrugs.
[21:07] <Peng> mod_fastcgi, mod_python, mod_wsgi... Is there a mod_scgi?
[21:07] <Peng> They're all different.
[21:07]  * fullermd uses mod_wtfe.
[21:07] <Peng> Heh.
[21:07] <Peng> Insert Lighttpd or Nginx comment?
[21:09]  * Peng wanders off.
[21:57] <deepjoy> Peng: could you share your bzr-smart.cgi script?
[22:01] <poolie> hello
[22:01] <deepjoy> poolie: Hi
[22:02] <deepjoy> I'm trying to get a http+bzr server up and running
[22:11] <Peng> deepjoy: http://paste.pocoo.org/show/35997/
[22:11] <Peng> deepjoy: Also, in .bzr/.htaccess, I have "RewriteRule ^(.*/)?\.bzr/smart$ /bzr-smart.fcgi [L]".
[22:12]  * Peng changes the regex.
[22:19] <lifeless> poolie: how did your one-file-library-test-go?
[22:27] <deepjoy> Peng: thanks for that. I'v got it running on mod_python with modpywsgi from http://ice.usq.edu.au/trac/browser/ice/trunk/apps/ice-server/modpywsgi.py?rev=6940
[22:27] <deepjoy> now for authentication :-)
[22:28] <Peng> I never tried auth.
[22:28] <Peng> ssh++
[22:28] <bob2> ssh lets both you and bzr punt it on to something else (pam), and that something else has had years of other people looking for bugs
[22:29] <deepjoy> yup if only I could get ssh to run standalone with pam
[22:29] <deepjoy> :-(
[22:29] <bob2> standalone?
[22:29] <bob2> or does your os not use pam?
[22:30] <deepjoy> as in a chrooted sshd+pam
[22:30] <deepjoy> my userbase is in ldap
[22:30] <deepjoy> auth comes from there
[22:30] <deepjoy> ssh refuses to talk noce to ldap
[22:30] <deepjoy> /noce/nice/
[22:31] <deepjoy> it wants pam
[22:31] <bob2> and pam isn't working in the chroot?
[22:31] <i386> lifeless: ping
[22:31] <lifeless> pong
[22:31] <i386> Are you coming along tonight?
[22:31] <i386> Its a celebration of me getting off the hook
[22:32] <lifeless> which hook ?
[22:32] <poolie> lifeless: not resolved yet, i might go back to that today after clearing some todo items
[22:33] <poolie> lifeless: my net connection seems very flaky recently
[22:33] <deepjoy> all the tutorials for sshd in chroot talk about the sshd process being started in a chroot jail but authenticating from outside
[22:33] <poolie> if i die, tell canonical i loved her :)
[22:33] <deepjoy> poolie: :-)
[22:33] <bob2> deepjoy: if you're using ldap, that doesn't sound too hard...just install pam-ldap and nss-ldap in the chroot..
[22:35] <poolie> (in a bug) > Martin Pool's suggestion makes more sense to me, but I guess sabdfl
[22:35] <poolie> knows better.
[22:35] <poolie> pah!
[22:35] <lifeless> which bug ?
[22:35] <poolie> https://bugs.edge.launchpad.net/launchpad/+bug/84332
[22:35] <ubotu> Launchpad bug 84332 in launchpad "Scope of global search field isn't clear" [Undecided,Confirmed]
[22:36] <poolie> just what he is referring to there is unclear to me though
[22:36] <poolie> i'm pretty sure the proposed fix will please both mark and me
[22:49] <igc> morning all
[22:53] <lifeless> yo
[22:54] <lifeless> abentley: ping
[22:54] <lifeless> spiv: ping
[23:00] <poolie> (back)
[23:00] <poolie> igc, spiv: call now
[23:02] <spiv> https://bugs.edge.launchpad.net/bzr/+bug/207558 us the bug
[23:02] <ubotu> Launchpad bug 207558 in bzr ""bzr branch http://bazaar.launchpad.net/...." fails with bzr.dev >= r3309" [Critical,In progress]
[23:06] <abentley> lifeless: pong
[23:07] <spiv> lifeless: pong (also, you have mail from me)
[23:09] <lifeless> hoping  to have a three-way irc chat on this duplicate code
[23:09] <abentley> Sure.
[23:10] <lifeless> so I can probably create a function for this
[23:10] <lifeless> I really don't want to have an api folk use, with tested defined behaviour
[23:11] <lifeless> the functional areas using my quite-similar code fragments are already tested
[23:11] <lifeless> it can't be deprecated spiv, because these areas are not deprecated
[23:11] <abentley> Well, I can see how this might be one of those halfway-private things we discussed.
[23:12] <luislavena> hello guys, where I could find more about the trunk layouts used by bzr-svn?
[23:12] <abentley> The big win is getting everything going through Graph, because we think that API's got legs.
[23:13] <lifeless> yes; which this does though with redundant filtering to take it back to a ghost-ignorant api
[23:13] <lifeless> which sucks, but I figure i have time to fix that, or get stacking working, but not both
[23:15] <lifeless> SO
[23:15] <lifeless> I can create an untested helper function somewhere like repository.py
[23:15] <lifeless> plastered with 'do not use' stickers
[23:17] <spiv> So, my concerns about code that is temporarily duplicated and a bit ugly are: "temporary" has a habit of being less temporary than we expect; people will look at this code and copy-and-paste it as if it is the best way to do things; if something does need changing at one site (e.g. adding ghost filtering where currently there is none, or a bug) then duplication makes it unlikely that code gets re-used, wasting effort.
[23:17] <spiv> An untested helper function plastered with 'do not use' stickers deals adequately with all those concerns.
[23:18] <lifeless> ok
[23:18] <lifeless> abentley: makes you happy?
[23:18] <abentley> Yes, that's okay with me.
[23:18] <lifeless> ok, I'll do that. I've sent a couple of subsequent patches
[23:18] <lifeless> easiest for me would be to make this change and merge the whole lot.
[23:19] <lifeless> do I have a victim^Wvolunteer to review them ?
[23:19] <james_w> luislavena: hi, I don't quite understand what you mean, could you explain please?
[23:20] <spiv> lifeless: I can take a look at that, but I want to fix 207558 first, so it might be much later today.
[23:20] <bob2> jelmer: is bzr-svndev's README still correct wrt gutsy's p-subversion being recent enough (I have it installed, but bzr-svn claims it is not)
[23:20] <bob2> luislavena: 'bzr help svn-branching-schemes', I think
[23:20] <lifeless> bug 207558
[23:20] <ubotu> Launchpad bug 207558 in bzr ""bzr branch http://bazaar.launchpad.net/...." fails with bzr.dev >= r3309" [Critical,In progress] https://launchpad.net/bugs/207558
[23:21] <lifeless> spiv: if you think it will be after 2pm, say so now, other wise deal ( except I will keep churning out patches, so the size may be >> when you get to it)
[23:21] <luislavena> bob2: too vague reference, but thank you.
[23:22] <luislavena> bob2: I'm dealing with a repo that uses a automated tool to manage merges between branches.
[23:22] <spiv> lifeless: I think there's a good chance it'll be after 2pm.
[23:22] <bob2> luislavena: too vague?
[23:22] <lifeless> ok
[23:22] <lifeless> igc: poolie: desperately seeking reviewer
[23:23] <igc> lifeless: which patch
[23:23] <luislavena> bob2: yep, that don't explain trunk0, trunk1, or which other schemes and how they match to your repo...
[23:23] <igc> I'm happy to help
[23:23] <lifeless> http://bundlebuggy.aaronbentley.com/?selected=mine -> 500 error
[23:23] <lifeless> AttributeError: ("'NoneType' object has no attribute 'submitters'", <bound method Root.index of <bundlebuggy.controllers.Root object at 0x8e4f94c>>)
[23:24] <abentley> Ooh.
[23:24] <lifeless> I think my session had timed out
[23:24] <igc> lifeless: an email title will do me
[23:25] <abentley> lifeless: confirmed-- it happens when I'm logged out and access that URL.
[23:25] <lifeless> http://bundlebuggy.aaronbentley.com/request/%3C1206593719.7512.459.camel@lifeless-64%3E
[23:25] <lifeless> http://bundlebuggy.aaronbentley.com/request/%3C1206591531.7512.456.camel@lifeless-64%3E
[23:25] <luislavena> bob2: example, I don't know if bzr-svn will take the following as a branch:
[23:26] <igc> lifeless: ok
[23:26] <luislavena> svn://host/repository/project/branches/exp/enhanced-img-processor
[23:26] <bob2> luislavena: ok
[23:26] <lifeless> hmm, switch-relative failed to land in london
[23:26] <lifeless> thank you bb
[23:27] <bob2> luislavena: note that you can use 'bzr branch' without caring about branching layouts
[23:27] <bob2> luislavena: hope that automated tool is compatible with svk
[23:29] <luislavena> bob2: I was worried of pushing the changes back to the repo :-)
[23:29] <luislavena> bob2: no, no svk, just svn.
[23:29] <lifeless> spiv: for http://, I think the default in bzr.dev should be to try for smart server facilities
[23:29] <bob2> luislavena: afaik if you just branch/push/pull, you don't need to worry about branching layouts
[23:29] <luislavena> bob2: it create tags between up and down operations between branches and trunk to keep reference when merging back
[23:30] <lifeless> spiv: but if we know of places that this doesn't degrade well, we could have some means to explicitly disable it in the client
[23:30] <spiv> lifeless: "nobzr+http:" ;)
[23:30] <luislavena> bob2: thank you :-)
[23:30] <lifeless> spiv: http-bzr:// ?
[23:30] <abentley> lifeless: btw, BB now uses launchpad for bug tracking.
[23:30] <spiv> Heh.
[23:30] <fullermd> http&~bzr://
[23:30] <spiv> I don't like how it will degrade, though.  You get unfortunate errors along the lines of "No branch at http://..."
[23:31] <spiv> Which won't hint to the user what's going on.
[23:31] <lifeless> spiv: can we tell what servers are fixed?
[23:31] <spiv> lifeless: not without a protocol bump, I think
[23:32] <lifeless> so this problem won't go away ever, potentially :>
[23:32] <spiv> Co-incidentally, we have one of those coming up fairly soon ;)
[23:32] <lifeless> Does lp's http server run the smart server?
[23:32] <spiv> lifeless: yes, hence "bzr branch http://bazaar.launchpad.net/~bzr/bzr/trunk" is currently broken if you have bzr.dev on the client.
[23:33] <lifeless> so
[23:33] <spiv> (which is bug 207558)
[23:33] <ubotu> Launchpad bug 207558 in bzr ""bzr branch http://bazaar.launchpad.net/...." fails with bzr.dev >= r3309" [Critical,In progress] https://launchpad.net/bugs/207558
[23:33] <lifeless> I propose: disable that on launchpad
[23:33] <lifeless> because elmo will probably have a hernia about memory use; and it will be slower than http with packs :>
[23:34] <spiv> lifeless: (incidentally, bzr+ssh beats plain http for pulling the last three weeks of bzr.dev, 52s vs. 1m 21s IIRC)
[23:34] <lifeless> and for other servers; can we not recommend that they upgrade / :>
[23:34] <lifeless> spiv: ok, thats good to know
[23:35] <lifeless> I think initial pull is still slower though
[23:36] <abentley> Huh.  I would have thought bzr+ssh would tend to win on large amounts of data.  On small amounts, SSH connection time has a notable impact.
[23:37] <spiv> abentley: I was pleasantly surprised, I must admit.  I assume the graph RPC stuff is beating the index-bisection-over-HTTP.  Or maybe my intercepting squid proxy is influencing the HTTP results...
[23:37] <lifeless> spiv: incidentally, I suspect packing bzr.dev would reverse the figures
[23:37] <lifeless> spiv: oh yeah, you see hno's comments on the http bug ?
[23:38] <spiv> lifeless: no?
[23:38] <lifeless> spiv: turn of the ******g evil interception and I suspect it will be a lot faster
[23:38] <spiv> Oh, right :)
[23:38] <lifeless> spiv: you're triggering squids pre-load the whole file behaviour
[23:38] <lifeless> which is a bug in your version of squid
[23:38] <spiv> lifeless: yeah, I remember that bug now.
[23:39] <spiv> lifeless: we just need to hack our range requests ;)
[23:40] <spiv> lifeless: so, I'm uncomfortable with introducing a regression, even if buggy servers are technically the cause.
[23:41] <spiv> I don't think keeping the status quo (you need to explicitly use bzr+http to use smart http) for one more release is bad idea.
[23:51] <jdong> hey folks, I've filed a FFe for bzr 1.3 at bug 208039
[23:51] <ubotu> Launchpad bug 208039 in bzrtools "Feature Freeze Exception: bzr 1.3" [Undecided,New] https://launchpad.net/bugs/208039
[23:51] <jdong> let me know if I've missed a package
[23:52] <lifeless> spiv: ok, though it seems a shame
[23:52] <lifeless> spiv: because, for broken servers, bzr+http is already not working
[23:52] <spiv> lifeless: right, but http *is*.
[23:53] <lifeless> what I mean is that its unlikely the operator is ignorant of the fact
[23:53] <lifeless> they will, like AfC, have either setup bzr+http so it works, or tried and failed and left it not working
[23:54] <lifeless> release notes that say 'bzr+http is no longer needed unless you want to disable plain http use' are IMO going to be enough for those admins
[23:54] <spiv> Well, I guess there is a general issue here, which is that bzr+http can be misconfigured, even if we have all our bugfixes in place.
[23:54] <spiv> But reporting a "sorry, no branch here" error in that case as if it were plain HTTP is needlessly confusing.
[23:55] <lifeless> spiv: we don't seem to have any answer to that though
[23:55] <lifeless> spiv: I don't see how waiting a release makes it better
[23:56] <lifeless> i386: what hook
[23:57] <spiv> I think we probably need an answer to that problem, because it'll be useful for admins if users know which method is actually involved when things fail.
[23:57] <markh> ramdon question: if launchpad shows me a date as '05/01/2007', is it US or european?
[23:57] <spiv> Perhaps just a message along the lines of "Detected smart server" if the probe over HTTP succeeds.
[23:57] <markh> roger ramdom :)
[23:58] <lifeless> markh: if you are not logged in , its UTC
[23:58] <lifeless> markh: if you are logged in, its as per your TZ config for launchpad
[23:58] <markh> but is it d/m/y or m/d/y?
[23:58] <lifeless> markh: oh, its always sane.
[23:58] <lifeless> :>
[23:58] <markh> heh - cool :)
[23:59] <lifeless> spiv: so, I think that if we need an answer to this diagnostic problem anyhow, that effort during 1.4 dev should be on that answer, not on disabling and renabling autodetection.
[23:59] <lifeless> spiv: there is every chance that by the time we release 1.4 all users will have fixed their servers anyway :)