[00:05] <poolie> i'm going to merge Proposal to merge branch <https://code.edge.launchpad.net/~mbp/bzr/doc/+merge/4088> as trivial
[00:09] <lifeless> poolie: +1
[00:09] <lifeless> poolie: are you starting to use merge proposals rather than BB ?
[00:09] <poolie> i'm in kind of toe in the water mode
[00:10] <poolie> having two todo lists is obviously not so desirable
[00:10] <lifeless> indeed
[00:10] <lifeless> I think lp is close
[00:10] <poolie> yeah i'd say they have roughly equal good and bad points atm
[00:11] <lifeless> lp crashes less :P BB is way faster
[00:13] <poolie> lp lets people comment without prior permission
[00:13] <poolie> and kindof has the proposals linked to bugs etc
[00:13] <lifeless> BB has bug links
[00:14] <poolie> do you know this snoxracer337 guy?
[00:14] <poolie> that's true but only unidirectionally unless you manually create them
[00:14] <poolie> as i generally do
[00:14] <lifeless> the nick isn't known to me; context?
[00:14] <poolie> wants to join bzr-core
[00:15] <lifeless> looking
[00:15] <lifeless> not clearly bzr related
[00:15] <lifeless> https://edge.launchpad.net/%7Emike337/+participation
[00:16] <lifeless> I'd say your normal 'please get involved in the community first' message is appropriate
[00:16] <lifeless> It might be nice to have that as a template somewhere :P
[00:17] <poolie> yeah
[00:17] <poolie> i just wondered if it was a case like johnf
[00:18] <poolie> cf bug 4976
[00:18] <poolie> speaking of slow i think i saw the subscriber portlet load asynchronously
[00:19] <poolie> that's nice
[00:19] <lifeless> well
[00:20] <bob2> lifeless: be nice
[00:20] <lifeless> bob2: awwww
[00:20] <luke-jr> jelmer: is it known problem that you can't branch a svn repo root?
[00:20] <igc> lifeless,poolie: Are we expecting chk formats to have both an inventories index and a chk_bytes one? Long term?
[00:21] <igc> I'm tracking down why send is slower on chk formats
[00:21] <lifeless> igc: either they will, or we'll inline  the inventory root into the inventory
[00:21] <luke-jr> actually, might just be this repo: http://repos.labjack.com/public/
[00:21] <igc> and it seems get_parent_map() has more indices to walk
[00:21] <lifeless> s/inventory$/revision/
[00:22] <igc> lifeless: do we have a nice way now of finding uncommon history?
[00:22] <igc> the send code does 2 X repo.get_ancestory() and then diffs the answers
[00:23] <lifeless> igc: get_parent_map should have identical index behaviour because parents of chk nodes are not asked for - or shouldn't be during bzr send
[00:23] <lifeless> yes, there is stuff in graph
[00:23] <lifeless> but it may still have a bug
[00:27] <igc> lifeless: can you take a look at BundleWriteOperation.__init__() - line 267 of bzrlib/bundle/serializer/v4.py?
[00:27] <igc> abentley: ^^^
[00:28] <lifeless> igc: as you say it does a full graph op
[00:28] <lifeless> igc: but thats on the revision graph, chk doesn't alter this
[00:28] <lifeless> igc: its more likely, IMO, that the gc cache is being thrashed
[00:29] <igc> lifeless: if I'm reading the profiling info right, get_parent_map is running on a combined index?
[00:29] <lifeless> yes, always
[00:30] <igc> in 1.9 format, index.iter_entries() gets called 25K times while it's 49K under brisbane-core
[00:30] <lifeless> .revisions is a KnitVersionedFiles, which has a KnitGraphIndex which holds a single GraphIndex, and that GraphIndex is a CombinedIndex with a list of the backing BTreeGraphIndices from the repo
[00:31] <lifeless> igc: from get_parent_map? or overall
[00:31] <igc> from get_parent_map()
[00:31] <lifeless> thats...odd
[00:31] <igc> I thought so too
[00:31] <lifeless> I suspect a hidden cause
[00:32] <igc> you explanations makes me even more curious
[00:32] <igc> I'll go digging a bit more now I understand what's happening better
[00:33] <lifeless> ok
[00:33] <igc> lifeless: but before I do, what graph calls should I look at to improve BundleWriteOperation.__init__()?
[00:33] <lifeless> something on Graph, I don't recall the names
[00:34] <lifeless> there is one that looks perfect but is buggy. Beware.
[00:34] <igc> ok
[00:34] <lifeless> anyhow, I'd expect send to be slower due to inventory stuff, not index load from ancestry checks :P
[00:36] <igc> lifeless: right. I've never looked hard at the send code before so I'm just going from what the profiling data is telling me
[00:41] <igc> lifeless: graph.find_difference() looks like the obvious method?
[00:41] <igc> lifeless: can you recall how it's buggy?
[00:44] <lifeless> igc: it doesn't return accurate results under some cases
[00:44] <lifeless> its documented in tests and the docs I think
[00:44] <lifeless> igc: in short - you're welcome to fix it :P
[00:44] <igc> lifeless: thanks :-)
[00:54] <jfroy> hey
[00:54] <jfroy> Is it just me or the 1.13 distribution archive doesn't have the pre-generated .c extension modules?
[00:55] <jfroy> INSTALL clearly states that they should be bundled.
[01:07] <jelmer> luke-jr: you can branch a svn root
[01:07] <jelmer> luke-jr: how is it failing?
[01:09] <luke-jr> jelmer: nm, they rearranged stuff
[01:14] <lifeless> jfroy: I haven't checked, if they are missing then thats more serious than the wrong NEWS entry, so we may want to spin a 1.13.1 with the .c files and the NEWS teaks
[01:20] <jfroy> lifeless: they are missing, except _patiencediff_c.c
[01:21] <jfroy> just checked the tar.gz and the zip
[01:30] <wbyoung> hey, i was wondering if there was anyone who could help with trying to set something up similar to svn:externals
[01:33] <tedg> So, I really want this bug fixed, bug 336749.  How do I run with BZR_PDB ?
[01:35] <wbyoung> it seems i can get join --refernece to work with a pack-0.92-subtree, but when trying to commit the join, I get the following error: bzr: ERROR: already in a write group
[01:39] <spiv> Hooray, all Inter*Remote* are now gone, and so repository.py no longer imports bzrlib.remote :)
[01:39] <spiv> (Well, once my next patch is accepted by PQM.)
[01:40] <poolie> spiv way to go
[01:40] <poolie> tedg, do
[01:40] <poolie> export BZR_PDB=1
[01:40] <poolie> then run it
[01:40] <spiv> It's nice to be deleting >100 lines of code for once...
[01:40] <poolie> pah
[01:40] <poolie> i've just sent a deletion of many more :)
[01:40] <poolie> but yes i agree
[01:41] <poolie> https://code.edge.launchpad.net/~mbp/bzr/deprecation/+merge/4432 -- look at all that red
[01:41] <poolie> tedg: i guess actually you need to get lifeless's attention
[01:45] <tedg> poolie: Thanks, I realized I deleted the data, so I'm regrabbing it for the PDB.
[01:45] <spiv> poolie: that is pretty nice :)
[01:46] <tedg> Also, I'll note that it's quite annoying to get a crash dialog everytime I log in from bug 283294
[01:51] <lifeless> jfroy: please file a bug
[01:51] <lifeless> tedg: BZR_PDB=1 bzr foo
[01:52] <lifeless> tedg: then you use your knowledge of bzr internals to explore
[01:53] <tedg> lifeless: Does this dump something, or give me a command line?
[01:55] <SamB> lifeless: where do you get one of those?
[01:55] <SamB> is there one I can download somewhere?
[01:58] <lifeless> SamB: one of what?
[01:58] <lifeless> tedg: it drops you into pdb, the python debugger
[01:58] <SamB> lifeless: knowledge of bzr internals
[01:58] <lifeless> tedg: its almost certainly a waste of time for you to do this; jelmer needs to, or I need a test repo that has the issue I can do it on
[01:59] <lifeless> SamB: reading the internals :P
[01:59] <SamB> hmm.
[02:01] <tedg> lifeless: It happens on the Inkscape repository.  Basically check it out and then do any action on it.  You can see the commands and the log file in the duplicate bug 332582.
[02:01] <SamB> there isn't some kind of direct NNTP-feed-to-my-brain or something?
[02:02] <tedg> Unfortunately the log isn't that clear as I was doing several things in different instances of Bazaar while it was running.
[02:02] <lifeless> tedg: I want a copy of the failing data, for various reasons
[02:02] <lifeless> SamB: sorry no :(
[02:02] <lifeless> tedg: rather than instructions for possibly recreating it anew
[02:02] <tedg> lifeless: I'm downloading it now, I'll make a tarball and attach it to the bug.  Will that work?
[02:03] <lifeless> tedg: yes
[02:03] <SamB> lifeless: I suppose that's just as well, as I lack the necessary hookups in any case
[02:03] <lifeless> tedg: note that its not high on my stack at the moment; AFAIK jelmer is looking at it
[02:03] <tedg> lifeless: Oh, it was my understanding from the comments that he'd given up.
[02:04] <lifeless> jelmer: ^
[02:05] <tedg> Ah, getting that data together is going to take a bit... I deleted the branch, and the old SVN branches don't seem to be compatible with the new ones.
[02:07] <jelmer> lifeless, tedg: I'm not working on that bug at the moment
[02:09] <jelmer> lifeless: I tried storing only the parents that were present
[02:09] <jelmer> but that caused bzrlib to blow up when I fetched again with more parents
[02:16] <lifeless> jelmer: hmm
[02:20] <lifeless> lunching
[02:25] <gotgenes> bzr doesn't have to be installed on a server to host the repository, does it?
[02:25] <jam> lifeless: .children() is slow because the lookup key by prefix code has to walk the entire _items dict for every lookup
[02:25] <jam> so if you have 1 prefix
[02:25] <jam> put another way
[02:25] <jam> looking up 100 children 1 at a time takes forever
[02:25] <jam> as it is 100x100 prefix comparisons
[02:26] <jam> At least,from what I could tell from 'iteritems()' returning 20k entries
[02:26] <jam> but having 600k calls to set()
[02:26] <jam> igc ^^
[02:26] <SamB> lifeless: you eat lunch at odd times!
[02:33] <lifeless> jam: that sounds like a bug to me
[02:34] <lifeless> jam: its meant to be stored by hash(item[0]) + hash(item[1])
[02:34] <lifeless> SamB: not odd for me :P
[02:34] <lifeless> gotgenes: no, it doesn't. If it is you can get better performance though
[02:35] <jam> lifeless: iteritems(key_filter=[file_id1]), iter_items(key_filter=[file_id2])
[02:35] <jam> has to do iteritems N times for N file ids
[02:35] <jam> and inside it iterates over the full items dict
[02:35] <jam> so N^2 behavior
[02:36] <jam> I didn't see an obvious reason why in  def children()
[02:36] <gotgenes> lifeless: Thanks.
[02:36] <jam> since it does seem to grab all the child_keys based on a single parent_id prefix in the container
[02:36] <lifeless> jam: huh, should be one iteritems per directory entry
[02:37] <jam> Well, I see 20k calls to iteritems() (as a generator it yeilds 20k entries)
[02:37] <jam> and I see 654,845 calls to set()
[02:37] <lifeless> jam: (to get the children ids), and one to populate the children entries, or perhaps one per child, which is still only 2N
[02:37] <jam> so that is about 32:1
[02:37] <lifeless> jam: so, see under bug
[02:37] <jam> which is probably the 32 keys in each leaf node
[02:38] <jam> 255 leaf nodes to check
[02:38] <jam> not sure
[02:38] <lifeless> I should rephrase I guess
[02:38] <jam> 6k calls to items(), + 6k calls to iteritems...
[02:38] <lifeless> we have a datastructure which should allow children to be cheap, if its not there is definitely an issue
[02:39] <lifeless> I agree that it may not 'be cheap'
[02:39] <lifeless> I'm asserting that it should be possible for it to be cheap
[02:39] <jam> I do see "718" calls to LeafNode.deserialise, which is a bit more than I think we should see....
[02:39] <jam> hmm... maybe with p_id + id_to_entry?
[02:44] <jam> lifeless: so if you have hash(file_id), and a given directory has 43 items, isn't that likely to go to 43 different pages?
[02:44] <jam> which means that we have a 43*num_entries_on_leaf
[02:44] <lifeless> jam: no, because its a tuple key - its pid + basename
[02:45] <jam> lifeless: not in that one
[02:45] <jam> in the one that gets the bytes for the entry
[02:45] <jam> the parent_id_basename_to_file_id is cheap, yes
[02:45] <jam> it is about 3x faster than the id_to_entry lookupps
[02:45] <lifeless> oh yes, but because we're using the main object, it should be parsing and caching all of those pages
[02:45] <jam> lifeless: I would guess the pages themselves are cached
[02:45] <jam> but it still is a double loop
[02:46] <jam> of for key, bytes in items: for lookup in lookups:
[02:46] <jam> where the outer is N entries on a page
[02:46] <jam> and the inner is the M children of a directory
[02:46] <lifeless> possibly iterentries isn't skipping enough pages?
[02:46] <jam> now... maybe we are making the mistake of not filtering our keyfilter
[02:46] <jam> as in
[02:46] <jam> we find the N pages underneath that match
[02:46] <jam> but we don't know which keyfilter matched which  subpage
[02:47] <jam> so for all M children of a directory that match in one of M leaf nodes
[02:47] <lifeless> right, we should only be inspecting the filter items that matched
[02:47] <jam> we then compare all N leaf entries against all M keys
[02:47] <jam> when we should be only matching against the one of M keys that hits that leaf node
[02:49] <jam> I still feel like we are doing a prefix match against all items in a dict
[02:49] <jam> when we *should* be doing a simple self._items[key] lookup
[02:49] <jam> but I'm not sure if that can be adequately expressed yet
[02:49] <jam> lifeless: Am I wrong in saying that id_to_entry.iteritems([(file_id,)]) should always match exactly 1 entry?
[02:50] <jam> (consider you could have file_id1 = 'foo', and file_id2 = 'foo-bar')
[02:51] <jam> hmm... the code really isn't set up for what I want to do... which is to split up the key_filter based on which part of the filter matched which child page
[02:52] <jam> iter_nodes is done very independently of iteritems(), not to mention it shortcuts the comparison, so we wouldn't know all the keys which would have matched. Though we could remove that shortcut
[02:53] <lifeless> jam: tuple keys should only ever match once in id_to_entry
[02:54] <lifeless> jam: parent_to_basename they can multimatch - [('parent',)] -> list of children
[02:54] <jam> I'm pretty sure with the current construct that doesn't end up holding true
[02:54] <jam> as you just look at 'prefix[:length]'of the serialized from
[02:54] <jam> form
[02:55] <lifeless> perhaps this just needs updating like you did the rest to handle hashed keys better?
[02:55] <jam> we can certainly change that
[02:55] <jam> well, it sounds like prefix[:] should only really be splitting on end-of-internal width or NULL
[03:20] <lifeless> poolie: so progress
[03:20] <lifeless> poolie: I filed a bug today/yesterday about it showing inappropriately
[03:20] <lifeless> andrew and I have ensured that setUp() is being called everywhere and it still shows during selftest.
[03:21]  * igc lunch
[04:55] <mattdoran> Typically, how long after a release do the windows builds get posted?
[04:57] <BasicOSX> The generic answer (not to be rude) is when the windows people have time :-)
[04:58] <mattdoran> I understand completely ... I didn't mean to sound impatient either.
[04:59] <mattdoran> was just wondering whether there was a ballpark.  e.g. typically within a week.   No big deal though
[05:03] <lifeless> mattdoran: within a week yes
[05:03] <lifeless> its sometimes longer, the windows build process is ... fragile
[05:03] <mattdoran> :) gotcha ... thanks
[05:42] <igc> poolie: if you have time soon, can you please re-review the dirstate patch jam & I worked on last week?
[06:11] <lifeless> spiv has headed off, I'm going to land one more branch [I hope] and be gone myself
[06:20] <fullermd> Hm.
[06:20] <fullermd> bzr-1.13.tar.gz doesn't include the pyrexified .c files.
[06:23]  * fullermd frowns.
[06:23] <fullermd> Or a couple others either.
[06:23] <fullermd> The only one in it is _patiencediff_c.c.
[06:25] <lifeless> ok, streaming pull from stacked branches submitted
[06:25] <lifeless> -> done, modulo sheparding it though
[06:25] <lifeless> *through*
[06:29] <bob2> spiffy
[06:29] <lifeless> and I'm done for the day
[06:31] <igc> seeya lifeless
 ok, streaming pull from stacked branches submitted
[07:00] <mwhudson> yay!
[07:23] <poolie> igc, i'll read it now, promise
[07:23] <poolie> lifeless: if you're talking about activity coming up during selftest
[07:23] <poolie> then yes, i've seen it and i know why it's happening
[07:24] <poolie> basically because nothing turns it off :)
[07:27] <lifeless> poolie: but it should be controlled by the SilentUI surely
[07:27] <lifeless> poolie: and that is installed by setUp
[07:27] <lifeless> poolie: also, streaming-from-stacked has landed
[07:27] <lifeless> say 'hallelujah'
[07:28] <lifeless> anyhoo, gone
[07:30] <vila> hi all
[07:30] <igc> hi vila
[07:30] <vila> Hi Ian :)
[07:34] <poolie> lifeless: the problem is that the overall testrunner uses a progress bar
[07:34] <poolie> at least in non-verbose mode
[07:34] <poolie> actually it is a bit interesting that the lower level transports aren't talking to the silentui
[07:34] <Peng_> With the streaming-from-stacked stuff, is it just me, or is is_empty's docstring wrong? It says it returns true if it's *not* empty.
[07:34] <poolie> hi vila
[07:35] <vila> hi poolie !
[08:00]  * igc dinner
[08:16] <lifeless> poolie: the silent ui should have its own pb stack, so they should not interact
[08:16] <lifeless> Peng_: probably :P
[08:16] <poolie> so that suggests either the silent ui is passing notifications through to the higher level progress view
[08:16] <poolie> or, the transports are somehow talking to the real ui object
[08:16] <poolie> either is possibly
[08:16] <poolie> possible*
[08:16] <poolie> should not be very hard
[08:18] <lifeless> sure;I'm hoping you'll find time to track it down, asyou know the new stuff best :)
[08:18] <lifeless> the test improvements today should make it easier; test_remote is a small test regex that will trigger the behaviour
[08:18]  * lifeless goes again
[08:18] <lifeless> chat with you tomorrow
[08:31] <poolie> oh thanks for the tip
[08:46] <sabdfl1> hi folks
[08:46] <sabdfl> anybody building bzr.dev on jaunty?
[08:55] <RAOF> sabdfl: Isn't there a bzr nightly PPA?
[08:55] <RAOF> https://edge.launchpad.net/~bzr-nightly-ppa/+archive/ppa would be it, yes.
[09:06]  * eMBee needs to find out where it is
[09:06] <eMBee> ooops
[09:22] <stub> Does the smartserver benefit from running over a compressed link, or should I disable SSH compression to bazaar.launchpad.net?
[09:27] <stub> Hmm... 1.13 released but no packages in either https://launchpad.net/~bzr/+archive/ppa or https://launchpad.net/~bzr-beta-ppa/+archive/ppa
[09:39] <poolie> stub:  it will benefit a bit
[09:39] <poolie> sabdfl: i use it on jaunty all the time
[09:40] <poolie> to the vast amusement of those with working laptops :)
[09:41]  * AfC assumes poolie is referring to some kind of inside joke
[09:42] <poolie> just that people who install alpha releases get what they expect/deserve :)
[09:42] <poolie> it's all part of the fun
[09:42] <poolie> and the point of testing it
[09:42] <stub> poolie: I wonder. I just checked the CPU utilization graphs and CPU is running at capacity.
[09:43] <stub> poolie: Oops... misread
[09:43] <poolie> in that case compression may be slowing you down
[09:43] <stub> Lots of capacity :-)
[09:44] <poolie> it's probably within \epsilon either way: it won't compress much, probably, but zlib is cheap too
[09:44] <poolie> stub there should be rc1 packages and the final should be up in a bit
[09:45] <stub> Yer - had to downgrade from rc1 due to being unable to my push not using stacking.
[09:46] <poolie> and you're told this is fixed in final?
[09:47] <stub> Yes - lifeless said it had been fixed and would be in final.
[09:57] <Lieven1> hi
[09:57] <Lieven1> I'm trying to pull from an svn repo, that requires authorization, and that gives an error that authorization is required (obviously:))
[09:58] <Lieven1> but I tried to google on how to specify your authorization, but couldn't find anything
[09:58] <Lieven1> so does anyone know how to do that/
[09:58] <bob2> include the username in the url
[10:01] <Lieven1> thx, trying it out now:)
[10:06] <Lieven1> hmm.. my original url is sth like:   http://subversion.company.local/svn/HEAD
[10:06] <Lieven1> so then it should become this, right: http://username@subversion.company.local/svn/HEAD
[10:07] <igc> poolie: did you want the class or methods renamed to use SHA? I'm pretty sure the methods in osutils are 'sha' - all in lowercase
[10:08] <igc> s/methods/functions/
[10:14] <sabdfl> poolie: i'm getting an error on make:
[10:14] <sabdfl>   Cannot build extension "bzrlib._groupcompress_pyx".
[10:14] <sabdfl>   Use "build_ext --allow-python-fallback" to use slower python implementations instead.
[10:14] <sabdfl> not sure what's causing that
[11:50] <fullermd> Oh, nice.
[11:50]  * fullermd does his first push to a 1.13 smart server.
[12:07] <bob2> nice progress dealy
[12:11] <Tak> vila: reping
[13:17] <vila> Tak: pong
[13:19] <Tak> hi! is there any way to get the sftp transport to use authentication.conf for user/pass credentials?
[13:19] <vila> Tak: only for user, trying to use it for passwords should issue a warning
[13:20] <vila> Tak: the rationale being that ssh provides better means for passwords/keys and is more secure than whatever we can come with
[13:20] <Tak> ok
[13:20] <Tak> it doesn't seem to be issuing a warning for me on 1.13rc1
[13:20] <vila> Tak: and also .ssh/config is already more powerful
[13:21] <vila> Tak: try using -Dauth and look into .bzr.log
[13:21] <vila> there should be messages regarding which sections are used (or not)
[13:21] <Tak> -Dauth as a bzr arg?
[13:22] <vila> Tak: yup. as in 'bzr push -Dauth'
[13:22] <vila> or whatever command needing credentials from authentication.conf
[13:24] <Tak> hmm, it tries public key, then it prompts for password on stdout, but no warning on stdout or in log
[13:31] <jam> sabdfl: if you are still around, it might be an issue with pyrex versions. We might be doing something like "+=" which isn't supported by pyrex 0.9.6 (you need 0.9.8+, IIRC).
[13:31] <jam> I'll try to check
[13:31] <jam> vila: good morning
[13:31] <vila> Tak: who is prompting for password ?
[13:31] <vila> jam: hi !
[13:32] <jam> sabdfl: alternatively, you may need to install 'zlib1g-dev' since we now directly access some zlib functions.
[13:32] <jam> vila: my guess is openssh
[13:34] <sabdfl> thanks jam
[13:41] <Tak> it's paramiko
[13:43] <vila> Tak: what is your problem exactly ?
[13:43] <jam> vila: he's trying to use authentication.conf for sftp
[13:43] <vila> jam: I got that, but for which part ? user (should work) ? password (will never work) ?
[13:44] <Tak> ok
[13:44] <Tak> I /was/ asking if/how it worked for password
[13:44] <jam> vila: I thought password might work with paramiko, since we were controlling things there
[13:44] <Tak> you told me it won't, ok
[13:44] <jam> it certainly would never work for openssh
[13:45] <Tak> you also said it would print a warning, which it is not
[13:45] <vila> Tak: if it doesn't show a warning, most probably the section doesn't match
[13:45] <Tak> so then you asked me to run with -Dauth and look at the log, which still doesn't
[13:45] <vila> scheme should be 'ssh' not 'sftp' ?
[13:46] <Tak> what does it...ahh
[13:46] <Tak> ok, with 'ssh' scheme, the warning prints
[13:47] <vila> Tak: http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#authentication-settings
[13:48] <Tak> yeah, I was parsing the url and dumping the transport in as the scheme
[13:48] <vila> Tak: both caveats are documented there (use 'ssh' as scheme, no password handling for ssh)
[13:49] <Tak> ok
[13:49] <Tak> now I need to set up a different scheme for testing
[13:50] <vila> Tak: testing as in 'writing unit tests' or as in 'setting up some bzr server' ?
[13:54] <Tak> heh, testing as in 'connecting using my auth-populating mechanism to make sure I'm doing it right'
[13:57] <vila> Tak: if you populate authentication.conf by programmatic means, I'd very interested as the actual mechanism will certainly evolve in the future.
[14:00] <Tak> right now, I'm using AuthenticationConfig.set_credentials()
[14:08] <thrope> hi - how can I add a filename with spaces to .bzrignore? I tried quoting or backslash escape but it doesnt seem to work
[14:09] <thrope> ah nothing
[14:09] <thrope> no quotes, escape... guess I should hav etried that first
[14:27] <phinze> okay so i have a coworker who did Something Bad to one of our shared project branches .. and the Bad Thing is in one of his subcommits
[14:27] <phinze> do i have the information to revert a subcommit from the shared branch or does the delta only reside on his local work branch
[14:28] <fullermd> The rev is there.
[14:28] <fullermd> "subcommit" is a UI fiction; a revision is a revision underneath.
[14:29] <phinze> ahh good
[14:29] <beuno> user interface fiction?
[14:29] <phinze> but... $ bzr diff -r2320.1.12..2120.1.13
[14:29] <phinze> bzr: ERROR: Requested revision: u'2120.1.13' does not exist in branch:
[14:29] <phinze> oh jeez
[14:29] <phinze> it was just a typo
[14:29] <fullermd> You sure you don't mean 2130.1.13?  ;)
[14:29] <phinze> there it is
[14:29] <fullermd> `bzr diff -c2130.1.13` is shorter to type.
[14:30] <fullermd> Wow, 2320.  Obviously neither of us can type   8-}
[14:30] <phinze> hehe
[14:30] <phinze> ah that -c is nice
[14:30] <phinze> so i can reverse merge that guy with no problems then
[14:30] <phinze> cool
[14:31] <fullermd> Note that you can use 'merge' for that too, though it doesn't do anything you can't do with diff.
[14:31] <fullermd> Though it's easier than manually handling renames etc if there are any in that particular rev.
[14:31] <phinze> yeah i was just doing diff to see what i would be doing with merge
[14:31] <phinze> i always think of it as bzr merge *does* what bzr diff *shows*
[14:32] <fullermd> Me, I often just diff | patch -R.  I usually don't undo things far enough back that patch's fuzz-handling won't keep up.
[14:32] <fullermd> And I'm lazy.
[14:33] <phinze> that works too :)
[14:44] <phinze> fullermd: so do you have a fancy short way to reverse the merge or am i doing bzr merge -r 1234..1233
[14:44] <phinze> ahh nm
[14:44] <phinze> you use patch -R
[14:47] <Odd_Bloke> phinze: You can 'bzr merge -r 1234..1233 .'.
[14:47] <phinze> Odd_Bloke: yeah that's what i'm doing... didn't know if there was a shorthand for that
[14:48] <phinze> like bzr merge -R1234 . or something... the other way is short enough though :)
[14:54] <fullermd> Well, -c123 does it 'forward'.  So if you type in -c123 upside-down, it does it backward.
[14:54] <fullermd> Most keyboards don't handle that, though...
[15:01] <Odd_Bloke> "bzr ɯǝɹƃǝ -c123"
[15:01] <gnomefreak> what does the following error mean and how to i get past it when trying to pull a branch? bzr: ERROR: Server sent an unexpected error: ('error', 'iteration over non-sequence')
[15:02] <jelmer> gnomefreak: sounds like an exception happened in the server
[15:02] <jelmer> gnomefreak: most likely a bug
[15:02] <gnomefreak> jelmer: so its not me
[15:03] <jelmer> gnomefreak: no, it really is something wrong happening server-side
[15:03] <jelmer> gnomefreak: using sftp:// should fix it, if you're able to (but it'll be slower, obviously)
[15:03] <jelmer> gnomefreak: a bug report would be much appreciated, particularly if this can be reproduced with public branchres
[15:04] <gnomefreak> jelmer: jelmer ok will test more and file one or find one
[15:08] <flacoste> i upgraded bzr-svn and now i'm having problems with my existing branches
[15:08] <jelmer> flacoste: see UPGRADING
[15:09] <flacoste> jelmer: i did and I ran bzr svn-upgrade
[15:09] <flacoste> but after that, i had to use a push --overwrite to update the LP version of the branch
[15:09] <flacoste> and now all branch that were merging that one cannot merge anymore
[15:09] <flacoste> and I don't know how to fix these, since bzr svn-upgrade doesn't do anything on them
[15:09] <jelmer> flacoste: yes, you'd have to upgrade those other branches as well
[15:10] <flacoste> how?
[15:10] <jelmer> running bzr svn-upgrade in those branches
[15:10] <flacoste> bzr: ERROR: Repository at bzr+ssh://bazaar.launchpad.net/%7Eflacoste/windmill/windmill-launchpad/.bzr/ is not a foreign repository.a
[15:11] <jelmer> flacoste: you have to specify the URL of the svn repository
[15:11] <flacoste> ok
[15:11] <flacoste> bzr: ERROR: No repository present: "http://svn.getwindmill.com/trunk/"
[15:12] <flacoste> but this is the URL used on the main branch
[15:12] <jelmer> flacoste: the repository root, so probably http://svn.getwindmill.com/
[15:12] <flacoste> ok, seems to work :-)
[15:12] <flacoste> jelmer: all good, thanks a lot!
[15:13] <flacoste> i was able to merge now!
[15:13] <jelmer> flacoste: np
[15:23] <fm_> how is user managment done with a bazaar server?
[15:25] <vila> fm_: so far with what the protocol after the '+' offers, be it ssh or http
[15:28] <fm_> vila: ok, so suppose i am running "bzr serve --port=localhost:1234 --directory=/srv/bzr/repo" on server example.com, how do i access this by bzr+ssh?
[15:29] <vila> fm_: you don't, you're using the only form of bzr server that doesn't have user management so far :)
[15:29] <fm_> hm that's sad
[15:29] <fm_> so what is the suggested configration, i did not want to create shell accounts for the users ...
[15:30] <vila> there is a bug filed for that, but I can't find it right now
[15:30] <vila> fm_: you can either use ssh keys and bzr+ssh or bzr+http and use whatever authentication your web server already propose
[15:32] <fm_> but bzr+http is readonly i suppose, and for bzr+ssh i need to create system accounts ...
[15:32] <vila> bzr+http is not read-only it can perfectly do write operations
[15:33] <vila> fm_: subscribe to bug #126911 in the long term
[15:34] <vila> fm_: And you don't need to create system accountS, you can create a single one for bzr usage and add whatever keys you want in its .ssh/authorized_keys
[15:37] <fm_> vila: and how do i identify the commiter?
[15:38] <fm_> i guess bzr whoami is used, but then every name could be set there ...
[15:39] <fullermd> The commit process sets that; the bzr+ssh or whatever account is just used for the uploading.
[15:39] <fm_> and i'd like to give special pernmission for dfferent directories. i.e some people have just read access and others are allowed to write ...
[15:40] <vila> fm_: You can server via pure http for read-only access and use bzr+ssh for write access
[15:40] <vila> fm_: You can serve via pure http for read-only access and use bzr+ssh for write access
[15:41] <fm_> but not on per directory basis ;)
[15:42] <vila> fm_: you may also have a look in the contrib directory where various attempts have produced various scripts
[15:43]  * vila handwaves a bit to mask its incomplete knowledge of contrib content :-)
[15:43] <vila> fm_: bzr_access may be what you're after
[15:44] <vila> fm_: yup, sounds like a solution with a single system account and rights defined based on authorized keys
[15:45] <fm_> vila: https://bugs.launchpad.net/bzr/+bug/290887
[15:46] <fm_> that is exacly my bug i guess
[15:46] <vila> fm_: ? Did you *read* the doc string ?
[15:46] <vila> fm_: sorry, I thought you just filed the bug
[15:47] <vila> you're perfectly right, we still miss the link that should help you find that script
[15:48] <fm_> and may ask where to find the documentation? ;)
[15:49] <vila> The script itself contains some, if you're able to address your needs with it, feedback on how you did that on what could have made it easier will be greatly appreciated ;-)
[15:50] <vila> s/on/and/
[15:50] <vila> s/on what/and what/ grr
[16:16] <cody-somerville> Is it possible to merge in a single revision from another branch?
[16:17] <fullermd> Yes and no.
[16:19] <fullermd> Which is to say, merge will do the work of merging that single rev in.
[16:19] <fullermd> But it doesn't do any recording of what you do (presuming the rev doesn't fully connect in anyway), so historically speaking it's no different than diff | patch.
[16:22] <zooko> Hey folks: a project of mine is applying for Google Summer of Code, and one of our ideas for what a student could do this summer is to integrate with a distributed revision control too: http://allmydata.org/trac/tahoe/wiki/GSoCIdeas
[16:26] <Tak> hm, that's pretty cool
[16:26] <luke-jr> "No module named foreign"  "Unable to load plugin 'svn' from '/usr/lib/python2.5/site-packages/bzrlib/plugins'"
[16:27] <zooko> Tak: you mean bzr on top of a secure, distributed p2p disk-sharing thing?  :-)
[16:28] <Tak> well, both the secure, distributed p2p disk-sharing thing; and bzr on top of it
[16:29] <Tak> of course, if somebody implemented the FUSE integration, that would kind of make it a moot point wrt linux ;-)
[16:31] <Odd_Bloke> luke-jr: Sounds like you're using an old version of bzr.
[16:31] <luke-jr> Odd_Bloke: I'm using probabyl the minimum version bzr-svn depends on
[16:32] <Odd_Bloke> luke-jr: What version of bzr and what version of bzr-svn?
[16:33] <luke-jr> bzr 1.10
[16:33] <luke-jr> 1.9, sorry
[16:33] <luke-jr> bzr-svn 0.5.3
[16:34] <jelmer> luke-jr: you need bzr 1.13 for bzr-svn 0.5.3
[16:35] <jelmer> it will give a proper error message as long as you're running 1.10 or higher I think
[16:35] <luke-jr> jelmer: it should depend on that
[16:35]  * Odd_Bloke just made the mistake of trying to answer a bzr-svn question without just pinging jelmer. :p
[16:35] <jelmer> luke-jr: it depends on that
[16:36] <Odd_Bloke> luke-jr: How did you install it?
[16:36] <jelmer> luke-jr: well, the Debian/Ubuntu package does at least
[16:36] <luke-jr> Odd_Bloke: emerge -vauDN world
[16:37] <Odd_Bloke> Who does the Gentoo packaging?
[16:38] <luke-jr> whoever maintains the bazaar overlay?
[16:39] <Odd_Bloke> luke-jr: https://edge.launchpad.net/bzr-gentoo-overlay ?
[16:40] <Tak> anyone seen segfault when interacting with a svn repo using bzrlib via libpython?
[16:40] <luke-jr> I think
[16:44] <zooko> Tak: I'm not sure about that.  I'll think about it while writing some notes about the project ideas.
[16:45] <Tak> well, if you get a fuse frontend, then to bzr (or anything using it), it'll just look like a filesystem ...
[16:48] <jelmer> Tak: do you have a (C) backtrace with debugging symbols?
[16:49] <zooko> That is true, but there might be advantages in terms of distributed security if the revision control tool is more aware of the Tahoe namespace.  I'm not sure yet.
[16:50] <Tak> I have a mono backtrace with no debugging symbols... ;-)
[17:06] <zooko> Tak: writing this Project Idea, I realized that Tahoe already has a working command-line which accomplishes the same thing, in batch mode.
[17:13] <zooko> Tak: http://allmydata.org/trac/tahoe/ticket/663 # integrate a distributed revision control tool with Tahoe
[19:04] <dash> hi. trying to understand version dependencies for bzr-svn -- i've created a repo from the Twisted svn repo using the latest revisions of bzr and bzr-svn (using svn-import); will this interoperate ok with clients using bzr 1.12 and bzr-svn 0.5?
[19:05] <jelmer> dash: yes
[19:06] <jelmer> dash: 0.5.x interoperates with 0.5.x
[19:06] <dash> ok, great.
[19:13] <mwhudson> Peng_: ping?
[19:18] <jfroy> lifeless: https://bugs.launchpad.net/bzr/+bug/344465
[19:45] <jfroy> jelmer: any idea about https://bugs.launchpad.net/bzr-svn/+bug/342065/? It's kind of crippling not being able to get diffs :/
[20:03] <mwhudson> abentley: hi
[20:03] <abentley> mwhudson: hi
[20:03] <jelmer> jfroy: no, not yet
[20:04] <mwhudson> abentley: i have this memory that ages and ages ago you complained about not liking the way loggerhead split the list of files changed in a revision into added/renamed/removed/modified
[20:04] <scgtrp> i'd like to have my own branch of my project, available on the same server as the main branch, but i'd also like to be able to commit to it when i'm offline. is there any way to do that besides branching to another dir on the server then branching again locally?
[20:04] <jelmer> jfroy: It'd require some analysis of the repository again, and I don't have time for that atm
[20:04] <jelmer> jfroy: maybe later this week, sorry
[20:04] <abentley> mwhudson: Yes, I prefer status --short output.
[20:04] <jfroy> jelmer: interestingly, I just updated bzr-svn, wiped the svn cache, re-checked out from svn, and I haven't hit the exception again. Will continue testing...
[20:04] <mwhudson> abentley: what i don't remember is what you would have preferred to see
[20:04] <jfroy> jelmer: no worries
[20:04] <abentley> mwhudson: ^^
[20:04] <mwhudson> ah
[20:05]  * mwhudson doesn't know what status --short looks like
[20:05] <mwhudson> oh
[20:05] <mwhudson> M file
[20:05] <abentley> Yes, that kind of thing.
[20:05] <mwhudson> RM old_path => new_path
[20:05] <abentley> In loggerhead, it could be graphical of course.
[20:05] <mwhudson> yeah
[20:06]  * mwhudson does wonder slightly how loggerhead would cope with e.g. a kind change at the moment
[20:06] <mwhudson> not well, i suspect
[20:08] <mwhudson> abentley: i'm not really sure what 'being graphical' would mean here
[20:09] <mwhudson> if you could come up with nice icons for each of the letters status can spit out that would be cool
[20:09] <mwhudson> but i'm not even sure what icon "M" would need
[20:09] <abentley> mwhudson: That's what I meant by being graphical.
[20:10] <mwhudson> abentley: in other news, i'm thinking of moving away from tree.changes_from and so TreeDelta
[20:10] <abentley> mwhudson: I don't know what all the icons would be, but tools such as Meld have tried to show this kind of thing-- might be interesting to investigate.
[20:10] <mwhudson> abentley: probably to iter_changes() -- does that sound sane?
[20:10] <abentley> mwhudson: Yes, and very amenable to status --short output.
[20:11] <abentley> I think "new" is usually signified by a gleam, and deleted by an X or trash can.
[20:11] <mwhudson> abentley: cool
[20:12] <mwhudson> the fact that TreeDelta has an "unchanged" attribute just seems gratuitously silly for my usage
[20:12] <abentley> mwhudson: I wrote the original iter_changes, so I'm all about that.
[20:17] <abentley> mwhudson: You'll probably want to just implement your own ChangeReporter, which is a pretty simple interface.
[20:18] <mwhudson> ok, i was wondering if there was something like that
[20:19] <Peng_> mwhudson: Pong, if it's quick.
[20:20] <mwhudson> Peng_: just wondering if you wanted me to land your branch or if you would
[20:21] <Peng_> mwhudson: Which one?
[20:21] <Peng_> Oh.
[20:21] <mwhudson> get_apparent_authors
[20:24] <Peng_> mwhudson: I dunno. I can do it right now.
[20:24] <mwhudson> Peng_: go for it
[20:24] <Peng_> mwhudson: Alright. Thanks for the review. :)
[20:25] <mwhudson> abentley: the _ChangeReporter.report interface looks pretty nice, thanks for the hint
[20:25] <abentley> mwhudson: np
[20:25] <mwhudson> Peng_: np, it took me a while to get to it
[20:34] <Peng_> mwhudson: Done.
[20:34] <Peng_> Boy, pushing to an old pack repo feels slow. Btrees have really spoiled me.
[20:41] <mwhudson> i guess we should update to 1.9 at some point
[20:42] <beuno> that would be nice
[20:42] <beuno> I'm a big fan of 1.9
[20:46] <mwhudson> Peng_, beuno: done
[20:46] <beuno> awesome
[20:53] <exarkun> `bzr svn-import --incremental´ takes 8 or 9 seconds on this repository.  Any chance it will be faster soon?
[20:54] <mwhudson> i wonder if the # of branches in the twisted repo is the problem
[20:55] <exarkun> Do you think it would be the number of branches at HEAD or the number of branches ever?
[20:56] <mwhudson> at HEAD i hope
[20:56] <exarkun> There's 541 branches at head
[20:56] <exarkun> I could probably delete a few hundred of them :)
[20:56] <mwhudson> just wildly speculating of course
[20:56] <mwhudson> that's probably more than jelmer expected :)
[20:56]  * exarkun nods
[20:56] <exarkun> I haven't written the program that automatically finds branches associated with closed tickets and deletes them, yet, though.
[20:56] <exarkun> Maybe I'll try that now.
[20:57] <exarkun> And then compare the times
[21:00] <Peng_> mwhudson: Oh, cool.
[21:01] <Peng_> mwhudson: Thanks. :)
[21:01] <mwhudson> np
[21:03] <mwhudson> there certainly is some O(branch count) stuff in svn-import
[21:04] <mwhudson> no idea how expensive it is for the no-change case
[21:07] <Peng_> mwhudson: You said the pretty-url branch is ready to land, aside from the merge conflicts, right? I just fixed them. What do you want me to do?
[21:07] <mwhudson> Peng_: where is your branch?
[21:08] <Peng_> mwhudson: Ehh, didn't register it on LP yet, but http://bzr.mattnordhoff.com/loggerhead/loggerhead/pretty-url/
[21:15] <bignose> where do I set a user-specific ignore pattern that should apply for every branch that user works in?
[21:15] <bignose> I expected to find this in the documentation for “configuration” and “ignore”, but it's not in either of those.
[21:16] <LarstiQ> bignose: ~/.bazaar/ignore
[21:16] <bignose> LarstiQ: thanks. Where would I have found that documented?
[21:17] <LarstiQ> bignose: I agree those two should mention it.
[21:17] <LarstiQ> bignose: unfortunately, I know too much.
[21:18] <LarstiQ> bignose: I was curious, how did you write the rst for the builddeb Debian manpage, entirely from scratch?
[21:19] <Peng_> mwhudson: Hmm, pretty-url seems to break +revlog. Hold on.
[21:20] <bignose> LarstiQ: no, I wrote it in reStructuredText
[21:20] <bignose> LarstiQ: or do you mean, how did I write the reST?
[21:20] <bignose> the reST I wrote mainly by copy-and-paste.
[21:21] <LarstiQ> bignose: that's what I meant
[21:21] <mwhudson> Peng_: it seems to break rather a lot
[21:21] <LarstiQ> bignose: ah :)
[21:21] <LarstiQ> bignose: I'm still impressed though ;)
[21:21] <Peng_> mwhudson: Indeed.
[21:21] <mwhudson> Peng_: like "all links"
[21:21] <mwhudson> http://localhost:8080/http%3A//localhost%3A8080/revision/1243 don't look right to me
[21:22] <bignose> LarstiQ: but generating reST would be (I presume, with the confidence of the ignorant) simple for someone who understands the Bazaar help system
[21:22] <Peng_> mwhudson: Yeah.
[21:22] <Peng_> Um.
[21:22] <LarstiQ> bignose: reST itself is no problem.
[21:23] <bignose> (just realised that your original question did ask about the reST and I missed it)
[21:23]  * LarstiQ looks at it again to recall what he was impressed about
[21:23] <bignose> yay for IRC encouraging rapid response over careful reading :-)
[21:24]  * LarstiQ grins
[21:24] <mwhudson> Peng_: has the branch always done this, i wonder?
[21:25] <LarstiQ> bignose: I think it's a combination of it seeming like a clear document to me, and clearing my backlog making it appear like it appeared instantly.
[21:25] <Peng_> mwhudson: Dunno.
[21:25] <bignose> :-)
[21:25] <Peng_> mwhudson: Yes, it has.
[21:25] <bignose> I'm happy to leave that illusion unchallenged
[21:25] <mwhudson> Peng_: oops
[21:26] <LarstiQ> bignose: thank you :)
[21:26] <Peng_> mwhudson: Stupid question: What's static_url used for?
[21:26] <Peng_> Oh, duh.
[21:26] <mwhudson> Peng_: images, css, javascript
[21:28] <Peng_> mwhudson: OK, if you stop it from escaping BranchWSGIApp.url, it seems to work, but I don't know if all of the other changes make sense, or if I'm just lucky because I have simple URLs.
[21:29] <trondn> I have heard that the bzr revno may go up and down.. is there another id i can get and use to get a log of everything I just pulled?
[21:29] <mwhudson> Peng_: i think perhaps rejection is in order
[21:29] <LarstiQ> trondn: revision ids are stable, revnos are indeed derived.
[21:29] <mwhudson> i don't hate %7E in urls _that_ much
[21:30] <trondn> (ex. I just pulled lp:drizzle/mordred and had rev 942.. after a pull I got revno 939.. the bzr log -v -r 942..939 fails)
[21:30] <LarstiQ> trondn: for looking at what I just pulled, I usually use `bzr pull -v`, does that help?
[21:30] <trondn> LarstiQ: how do I get the revision id?
[21:30] <LarstiQ> trondn: bzr log --show-ids outputs them for example
[21:31] <mwhudson> trondn: ugh, tell people to not do things like that do their branches :)
[21:31] <mwhudson> if it's an 'integration branch' you should integrate by merging in new things and committing
[21:31] <trondn> is there a shorthand for the latest revision??? on mercurial I may use -r tip ???
[21:31] <mwhudson> trondn: -r -1
[21:32] <Peng_> mwhudson: I think at least some of the changes are probably a good idea -- like using urlutils instead of urllib, and maybe running unescape_for_display over served_url.
[21:32] <trondn> mwhudson: I'm modifying a hudson plugin ;)
[21:32] <mwhudson> trondn: haha
[21:32] <Peng_> trondn: Alternately -r head:
[21:32] <mwhudson> threads about hudson always weird me out
[21:33] <trondn> mwhudson: well, the bazaar plugin for hudson didn't work in a "master-slave" configuration, so I'm rewriting it... right now I'm trying to get the log there...
[21:36] <mwhudson> Peng_: if you say so :-p
[21:36] <Peng_> mwhudson: I'm just saying, if it didn't completely break everything, this branch might be worth merging. :D
[21:37] <phinze> sigh, so i just had the bazaar-hookless-email script bring one of my group's dev servers to its knees
[21:37] <LarstiQ> phinze: eek
[21:37] <LarstiQ> phinze: how so?
[21:38] <phinze> i had foolishly set it to crontab every 5 minutes
[21:38] <LarstiQ> and it didn't complete within 5 minutes?
[21:38] <phinze> and apparently an instance of it started spinning off longer than 5
[21:38] <phinze> and the next one started
[21:38] <LarstiQ> right
[21:38] <phinze> and the next one
[21:38] <LarstiQ> phinze: any reason you're not running it in daemon mode?
[21:39] <phinze> LarstiQ: mostly because it was the fastest solution to the problem at hand (i wanted to keep an eye on the commit stream of several branches, as i'm usually the guy called in to resolve bzr problems)
[21:39] <phinze> LarstiQ: do you think daemon mode would prevent it from eating up all the server's resources?
[21:41] <phinze> i'm trying to think of what would cause it to spin off at 100% like it's doing
[21:41] <LarstiQ> phinze: I'm not going to guarantee that :)
[21:41] <phinze> just chugging through a big diff maybe?
[21:41] <LarstiQ> phinze: but it's what we run
[21:41] <Peng_> mwhudson: Mind if I vote resubmit?
[21:41] <LarstiQ> phinze: also, you're not fork bombing
[21:42] <LarstiQ> phinze: although for cron it should check if there is a previous instance and bail out if that is the case
[21:42] <phinze> LarstiQ: right that is what i should have done from the get-go
[21:43] <LarstiQ> phinze: 5 minutes running time sounds like a lot evenso, so if you can figure out where that time went that would be great
[21:45] <phinze> LarstiQ: yeah i'm looking into it -- running it in foreground and it just chugs at 100% until i get scared and kill it
[21:46] <phinze> LarstiQ: trying to figure out how to get it to give me some better output
[21:46] <Peng_> mwhudson: Well, I just did. :P
[21:46] <LarstiQ> phinze: it has a log output option, though not overly verbose
[21:46] <LarstiQ> phinze: strace?
[21:48] <phinze> LarstiQ: not installed on the server :(
[21:48]  * LarstiQ blinks
[21:48] <mwhudson> Peng_: thanks
[21:48] <LarstiQ> phinze: other diagnostic tools?
[21:49] <phinze> LarstiQ: it's an old crufty box that is long overdue for a rebuild
[21:49] <phinze> LarstiQ: i might be able to get strace on there though
[21:50] <phinze> hmm wait
[21:50] <phinze> i can just tar up the repo
[21:50] <phinze> only 115M
[21:51] <LarstiQ> phinze: smart thinking :)
[21:51] <LarstiQ> evening jfroy_
[21:52] <jfroy_> LarstiQ: yo
[21:57] <phinze> alllright, here comes strace and here goes my local machine's performance
[21:57] <phinze> :)
[22:00] <LarstiQ> phinze: it's for the greater good, godspeed! :)
[22:05] <phinze> LarstiQ: okay 1m41s running time locally w/ strace
[22:05] <phinze> 100% during, but it does stop
[22:05] <phinze> what's this about "The program doesn't like to watch empty branches.
[22:06] <LarstiQ> I don't recall that string.
[22:07] <phinze> README:111
[22:07] <LarstiQ> oh
[22:07] <phinze> it's a rather vague and ominous statement
[22:07] <LarstiQ> yeah, makes sense.
[22:08] <LarstiQ> phinze: sorry :)
[22:08] <phinze> ahh did you write it?
[22:08] <LarstiQ> phinze: when there are zero revisions in a branch, you get into corner cases.
[22:08] <LarstiQ> phinze: I didn't touch the README, but my fingers are over some of the code, yes.
[22:09] <BasicOSX> Submitted [merge], bundle buggy did it's job, 2 core developers approved, do I need to ask someone to merge or can I submit to PQM?
[22:09] <phinze> ahh cool, well thanks for your work on it; it fills a very important need
[22:10] <phinze> i don't think we have any branches with zero revisions
[22:11] <phinze> well i've got to run
[22:11] <phinze> i'll continue to look into this
[22:11] <phinze> LarstiQ: thanks for your help; i'll keep you posted
[22:12] <LarstiQ> BasicOSX: without more context, you could submit it, if I'm still up to date on the process.
[22:12] <LarstiQ> phinze: cool
[22:13] <BasicOSX> LarstiQ:  Bundle Buggy is just a communication tool, has nothing to do with PQM ?
[22:13] <LarstiQ> BasicOSX: there is some judgement involved, say with possibly contentious patches and not everyone has had a chance to vote yet
[22:13] <LarstiQ> BasicOSX: right
[22:13] <BasicOSX> Mine is a simple documentation change :-)
[22:14] <LarstiQ> BasicOSX: that sounds relatively safe :)
[22:14] <LarstiQ> BasicOSX: which one is it?
[22:14] <BasicOSX> Bug #343928 gnu changelog was documented incorrectly
[22:15] <LarstiQ> BasicOSX: yeah, I'd go ahead
[22:19] <BasicOSX> LarstiQ:  first PQM to bzr.dev, what's the location.conf's submit_branch? http://bazaar-vcs.org/bzr/bzr.dev/ ?
[22:20] <lifeless> http://bazaar-vcs.org/bzr/bzr.dev
[22:20] <Kobaz> trying to start the latest version of loggerhead: ImportError: No module named simplejson
[22:20] <Kobaz> where would i get simplejson?
[22:21] <mwhudson> Kobaz: oh oops
[22:21] <BasicOSX> Kobaz:  pypi?
[22:21] <mwhudson> it's included with python2.5, but under a different name i think
[22:21] <mwhudson> Kobaz: what version of python are you running?
[22:21] <Kobaz> 2.5
[22:21] <mwhudson> Kobaz: one moment
[22:22] <Kobaz> ii  python2.5                        2.5.2-14
[22:22] <mwhudson> ah, nuts, json is only in 2.5
[22:22] <mwhudson> Kobaz: oh, if it's debian/ubuntu "apt-get install python-simplejson'
[22:22] <mwhudson> ah, nuts, json is only in 2.6
[22:23] <mwhudson> is what i meant to say...
[22:23] <Kobaz> python-simplejson - Simple, fast, extensible JSON encoder/decoder for Python
[22:23] <Kobaz> i guess i need that?
[22:23] <mwhudson> yes
[22:23] <Kobaz> heh
[22:23] <Kobaz> i <3 debian
[22:25] <Peng_> mwhudson: The new dependency should be added to the documentation.
[22:25] <mwhudson> Peng_: good point
[22:25] <Peng_> Not that I'm volunteering. ;-)
[22:27] <Kobaz> okay so
[22:27] <Kobaz> i have https://bzr.local/webbzr/
[22:27] <Kobaz> i have a few directories in the base (not repo's)
[22:28] <Kobaz> and then i click on one... and the link goes to /webbzr/directory
[22:28] <Kobaz> but then it redirects to /directory
[22:28] <Kobaz> which isn't found... of course... since the base directory of loggerhead is /webbzr
[22:28] <mwhudson> do we think easy_install simplejson will work?
[22:28] <Kobaz> why is it doing the redirect?
[22:28] <mwhudson> Kobaz: did you start loggerhead with the --prefix option?
[22:29] <Kobaz> nope
[22:29] <Peng_> mwhudson: Well, it's on PyPI, so it should...
[22:29] <mwhudson> Peng_: good enough for me :)
[22:29] <mwhudson> Kobaz: well you should :)
[22:29] <Kobaz> heh
[22:29] <Kobaz> k
[22:30] <mwhudson> ./serve-branches --prefix webbzr
[22:30] <Kobaz> ooo
[22:30] <Kobaz> yeah
[22:30] <Kobaz> that worked
[22:30] <Kobaz> oh that works much better
[22:31] <Kobaz> To get this branch, use:
[22:31] <Kobaz> bzr branch http://bzr.local/webbzr/project/base/trunk
[22:31] <Peng_> mwhudson: You're updating the README, then?
[22:31] <Kobaz> that's not my branch url
[22:31] <Kobaz> how would i set that?
[22:31] <mwhudson> Peng_: just did yeat
[22:31] <Kobaz> the branch url is http://bzr.local/bzr/project/base/trunk
[22:32] <mwhudson> Kobaz: you need to hack sourcecode at the moment :/
[22:32] <Kobaz> aww
[22:32] <Kobaz> i have auto_publish_folder set
[22:32] <Kobaz> i guess it doesn't use that?
[22:32] <mwhudson> um
[22:32] <mwhudson> if you're using serve-branches
[22:32] <mwhudson> loggerhead.conf is entirely ignored
[22:32] <Kobaz> yeah i'm using serve-branches
[22:32] <Kobaz> oh
[22:32] <mwhudson> mmm
[22:33] <mwhudson> i guess loggerhead really should use the public location of the branch, if that's set
[22:33] <Kobaz> hmm
[22:33] <Peng_> Hmm, I don't think I set the public location of my branches.
[22:33] <Kobaz> but the only way to serve multiple branches is via serve-branches right?
[22:33] <Peng_> Kobaz: start-loggerhead can serve multiple branches, but you should use serve-branches.
[22:34] <Kobaz> heh
[22:34] <Kobaz> mm, i broke it
[22:36] <Kobaz> as soon as i view a directory containing versioned files... it completely dies
[22:37] <mwhudson> as in, exits?
[22:37] <Kobaz> trunk/files
[22:37] <Kobaz> that works
[22:37] <Kobaz> and then..
[22:37] <Kobaz> Though the site seems valid, the browser was unable to establish a connection.
[22:37] <Kobaz> * Could the site be temporarily unavailable? Try again later.
[22:37]  * mwhudson wonders if http://pastebin.ubuntu.com/132731/ makes sense
[22:37] <Kobaz> etc etc
[22:37] <Peng_> mwhudson: Mind if I change it to import json if simplejson isn't available?
[22:38] <mwhudson> Peng_: not at all, does loggerhead work at all with 2.6 though?
[22:38] <lifeless> jam: mail for you re: bbc
[22:38] <Peng_> mwhudson: ...I have no idea, but it won't hurt.
[22:38] <lifeless> we really must stop PackRepository being a subclass of KnitRepository some day
[22:39] <Kobaz> ooooh
[22:39] <Kobaz> it's redirecting to http://
[22:39] <Kobaz> my loggerhead is on https
[22:39] <Kobaz> and the links are going to http
[22:39] <mwhudson> Kobaz: oh right
[22:40] <mwhudson> Kobaz: there's a bug about that
[22:40] <Kobaz> hehe
[22:40] <Kobaz> anyways
[22:40] <mwhudson> basically there's no way for serve-branches to know it's being run behind https
[22:40] <Kobaz> dinner time
[22:40] <Kobaz> time to bust out of the orfice
[22:40] <Kobaz> well. maybe make a setting to either prefix http or https
[22:41] <mwhudson> Kobaz: right
[22:41] <Peng_> mwhudson: So do you mind if I push trivial changes like this straight to lp:loggerhead without review?
[22:41] <Kobaz> well
[22:41] <Kobaz> actually
[22:41] <Kobaz> you shouldn't do the full url
[22:41] <mwhudson> Peng_: go for it
[22:41] <Kobaz> do relative urls... and that would fix it
[22:41] <mwhudson> Kobaz: probably that too
[22:41] <Kobaz> don't make links with http://servername
[22:42] <Kobaz> do /prefix/dir/file
[22:42] <Kobaz> that's what i always do and https/http is never an issue
[22:42] <Peng_> mwhudson: Alrighty.
[22:42] <mwhudson> Kobaz: i believe redirects need to be absolute urls
[22:42] <Kobaz> they dont
[22:42] <Kobaz> atg least in firefox
[22:42] <Kobaz> anyways
[22:42] <Kobaz> bustin out
[22:45] <mwhudson> they do in rfc2616 though
[22:48]  * igc breakfast
[22:49] <lifeless> breakfast
[22:49] <lifeless> and then commit for a bit
[23:16] <lifeless> igc: talk with zooko: re gsoc, may be something in common
[23:28] <igc> zooko: I've added http://allmydata.org/trac/tahoe/ticket/663 to http://bazaar-vcs.org/SummerOfCode2009