[00:07] <beuno> lifeless, you know what would be cool?  Making bzr-stats have similar indexes to bzr-search. So to make it easy to get stats, and be able to get something line "how many lines X commiter has added"
[00:11] <beuno> (in a cheap way, not processing everything each time)
[00:11] <lifeless> beuno: yah
[00:35] <edcrypt_> hi people - are there any script to fetch svn:externals with bzr-svn?
[00:37] <edcrypt_> pinax.hotcluboffrance.com uses a lot of external apps, I think I'll write a quick script to fetch each one with bzr...
[00:53] <Verterok> beuno: pushed, mail sent
[00:54] <Verterok> I'm off, at least for a few hours (birthday party), seeya later
[00:58] <beuno> Verterok, cool, have fun
[00:59] <Verterok> beuno: thanks
[01:34] <engie> Hi. I've pushed, with sftp, a branch to a web server and I can browse to it at http://www.studentrobotics.org/~stephen/jsdndide/local/ - what do I use to branch from this over http from another machine? I've tried every variant on branch with that URL I can think of!
[01:38] <jam> engie: You seem to have a shared repository in use on that machine, which is not exposed via http
[01:38] <jam> I'm guessing you have one in your home dir
[01:39] <jam> and Apache is only serving things under public_html
[01:39] <jam> So you need to "bzr init-repo public_html/" or possibly "public_html/jsdndide" before you do another "bzr push"
[01:40] <engie> OK. Is this because the local branch is under an init-repo directory on my local machine?
[01:40] <jam> engie: no, there is a repo on the remote machine
[01:40] <jam> otherwise we would have created one with the branch
[01:40] <jam> sorry, with the "push"
[01:42] <jam> engie: It is a good thing to have a shared repo on the other machine, it just needs to be somewhere that people can access it through http
[01:42] <engie> Ohh, looks like I accidentally pushed a .bzr up there when I was trying things out yesterday
[01:42] <engie> That machine doesn't have bzr on it
[01:43] <jam> engie: you don't need one, you can do "bzr init-repo sftp://host/~/public_html"
[01:43] <engie> Is there any benefit to doing that? Does it share history between multiple branches?
[01:46] <engie> Ahh brilliant, that's working, thanks
[03:33] <lifeless> jelmer: so what do you think
[03:33] <lifeless> RAOF: go to http://200.127.6.219:8080/bazaar/bzr/changes
[03:34] <lifeless> RAOF: and type in the search box
[03:40] <RAOF> lifeless: Is there really only one change there matching 'lambda'?
[03:41] <lifeless> looks like
[03:42] <RAOF> So, the find-as-you-type thing is good.  And it's nice and fast.
[03:42] <RAOF> The formatting seems a little off?
[03:42] <lifeless> yes
[03:42] <lifeless> being worked on
[03:42] <RAOF> Hm, it also doesn't much like "refactor" as a search term.
[03:42] <lifeless> hey, spare time, hacked up, new search engine etc
[03:42] <RAOF> It flips between anything matching 're' and 'refactor' :)
[03:43] <lifeless> beuno: http://200.127.6.219:8080/bazaar/bzr/revision/33?q=lambda doesn't search-complete?
[03:43] <lifeless> RAOF: uhm, not sure what you mean about flipping
[03:43] <RAOF> lifeless: Oh, I thought you were after comments/queries/criticisms.  If you'd like unadulterated praise, I can provide that, too :)
[03:43] <lifeless> RAOF: I'm not after either actually :)
[03:44] <lifeless> RAOF: you can throw peanuts at SLUG on friday if you like
[03:44] <lifeless> RAOF: this is just a follow up to the xesam comment in u-m
[03:44] <RAOF> Right.
[03:44] <RAOF> Aaah, I think I see the problem:  Typing r..e..f..a..c..t..o..r gives "refactoring" as the sole hit.
[03:44] <lifeless> which comment I can't even remember now
[03:45] <lifeless> just that it made me think I should show you this
[03:45] <RAOF> Right.  Contrary to Amaranth, I think search can be useful.  And I can immediately see how this could be nice and useful :)
[03:45] <lifeless> yah, this is a tiny code base its searching - the bzr-search plugin itself
[03:45] <lifeless> searching bzr's code base will give more suggstions:
[03:46] <lifeless> :!bzr search -s refactor
[03:46] <lifeless> Suggestions: [('refactor',), ('refactored',), ('refactoring',), ('refactorings',), ('refactors',)]
[03:46] <RAOF> But typing 'refactor' really quickly will briefly bring up 'refactoring', and then bring up all matches for 'r'
[03:46] <lifeless> RAOF: oh interesting. Thats because its a lot cheaper to search a smaller dataset I suspect
[03:46] <lifeless> RAOF: so its getting out of order results
[03:47] <lifeless> beuno: you should include in the response to a lookup, the string that was asked for
[03:47] <lifeless> beuno: then the client can ignore responses that are not the same as the current search is showing (or perhaps just ones that were done off a shorter prefix)
[03:48] <lifeless> s/smaller dataset/smaller number of terms/
[03:50] <lifeless> RAOF: there is a full command line client to bzr-search, if you prefer that
[03:52] <lifeless> garh, fugliest site ever: http://python2.near-by.info/index.php?option=com_content&view=article&id=144&Itemid=111
[03:52] <lifeless> I was trying to find pure python b+/b-tree implementations
[03:52] <lifeless> but that one sure seems locked away
[04:05] <beuno> lifeless, the javascript isn't included in the revision page. It's a bug  :)
[04:06] <lifeless> beuno: :P
[04:06] <beuno> and, it does wierd things because it looks for every character, no matter how fast you type
[04:06] <beuno> another know bug
[04:07] <beuno> I have to make the javascript stop propagating if you type before it sends out the request
[04:08] <beuno> right now it queues them, which was simpler at the time
[04:08] <lifeless> beuno: not at all
[04:08] <lifeless> beuno: my suggestion will make it appear better
[04:08] <lifeless> say it asked for - in order - 'r', 're', 'ref', 'refa'
[04:08] <lifeless> but the answers come back in the order 'ref', 'refa', 're', 'r'
[04:09] <lifeless> thats why it looks wierd
[04:09] <lifeless> but more specific searches complete faster, so this is actually expected
[04:09] <beuno> yeah, probably because
[04:09] <lifeless> now, imagine that in each answer you include the search at the top of it
[04:09] <beuno> 'r' took longer to process
[04:09] <lifeless> so the answer for r will have 'I am a search for 'r'
[04:09] <lifeless> and so on
[04:10] <lifeless> then the client can do this:
[04:10] <lifeless> if the current contents of the widget does not start with the response, ignore it
[04:11] <lifeless> if the contents do start with the response, and no drop down is shown, store the thing the response is for in a variable and show the drop down
[04:11] <beuno> yes, that's one way to do it. But that would hammer the servers pretty bad on a large scale
[04:11] <lifeless> if a drop down is already shown, and the response is for a shorter query than the drop down is, discard the response
[04:12] <lifeless> beuno: this is not a replacement for asking less often; its needed anyway (because under high load this can happen anyway)
[04:12] <beuno> lifeless, right, that makes sense
[04:12] <lifeless> (oh, and if the user deletes terms, obviously reset this variable or something
[04:12] <beuno> so it should be a combination of both
[04:13] <lifeless> yes
[04:13] <beuno> ok, so *more* javascript to write  :)
[04:13] <lifeless> :)
[04:14] <beuno> but it's great that we're debugging this so much, it may get in shape to go into trunk sooner
[04:14] <beuno> I'd like to add a few optional plugins to LH
[04:14] <beuno> this being one of the strongest recommended ones
[04:16] <beuno> also, I have plans to get the integrated into bzr-gtk, if no one does it first
[04:16] <beuno> it's even better as a desktop application  ;)
[04:19] <lifeless> perhaps jelmer will now hes seen it work :)
[04:19] <lifeless> beuno: perhaps these glitches (like revision page missing the javascript should be bugs ?
[04:20] <beuno> lifeless, I'd have to create a project for that. Do you think it's worth having a seperate project for it?
[04:20] <lifeless> nah just on loggerhead
[04:21] <beuno> oh, sure, that sounds like a good idea
[04:22] <beuno> I'll file the revisions one (and annotate, and the rest) if you file the search order  :)
[04:22] <lifeless> k
[04:23] <lifeless> done
[04:24] <beuno> me too
[04:24] <jml>   File "/home/jml/.bazaar/plugins/svn/core.py", line 25, in <module>
[04:24] <jml>     from bzrlib.plugins.svn.client import get_config
[04:24] <jml> ImportError: No module named client
[04:25] <jml> I got that when I tried to branch a svn branch with bzr
[04:25] <lifeless> is there a client.py file ?
[04:26] <jml> there's a client.c file. Apparently I need to build bzr-svn.
[04:27] <lifeless> jelmer: ^
[04:29]  * jml installs a bunch of stuff
[04:30] <jml> ok. that version of bzr-svn is not going to help me much.
[05:01] <lifeless> now
[05:01] <lifeless> Peng: around?
[05:03] <lifeless> jml: ping
[05:03] <jml> lifeless: pong
[05:03] <lifeless> loggerhead is down
[05:03] <lifeless> do you know if we moved it off vostok yet ?
[05:05] <jml> lifeless: no I don't.
[05:05] <lifeless> dang
[05:06] <lifeless> do you know the new machine name it would have moved too ?
[05:07] <beuno> lifeless, AFAIK, the new version of LH will be deployed on wendsday, so maybe that's when they're moving it?
[05:07] <lifeless> beuno: these things are unrelated
[05:07] <lifeless> beuno: deployments are routine; moving to a new machine is reconfiguration, testing etc
[05:08] <lifeless> mwhudson was talking about doing it driday
[05:08] <jml> lifeless: no, I don't.
[05:08] <lifeless> anyhow, It's 5am in London, I'll wait till 7am and ring james
[05:10] <lifeless> jml: have you played with kjbuckets ever?
[05:10] <lifeless> http://gadfly.sourceforge.net/kjbuckets.html
[05:10] <jml> lifeless: years ago
[05:10] <lifeless> thats more than I; impressions?
[05:10] <lifeless> http://bazaar-vcs.org/RobertCollins#head-b2dc9ae46f1860c46f79682db455c3512152d148
[05:11] <jml> lifeless: memories more like it. in the end I did my own graph classes.
[05:12] <jml> lifeless: I recall the API as being a little cumbersome.
[05:12] <lifeless> k, thats sufficient to tip me away
[05:12] <lifeless> needing to compile would be a burden anyhow
[05:14] <lifeless> scary: http://www.pythonweb.org/engine/
[05:16] <Peng> lifeless: pong
[05:16] <lifeless> Peng: do you have that magic to get the new LH running at a subfolder?
[05:17] <Peng> lifeless: Subfolder?
[05:17] <lifeless> yeah, so it can fit in an existing site
[05:17] <lifeless> mwhudson showed you how last week
[05:17] <Peng> lifeless: Oh.
[05:19] <Peng> lifeless: Here's my serve-branches.py: http://paste.pocoo.org/show/75647/
[05:19] <lifeless> Peng: thanks!
[05:19] <Peng> lifeless: (Then I just used lighty's mod_proxy/mod_proxy_core.)
[05:20] <lifeless> Peng: yeah, I have squid for that :P
[05:20] <Peng> :)
[05:35] <lifeless> loggerhead is back
[05:35] <beuno> lifeless, are you deploying the new LH in squid-cache.org?
[05:36] <lifeless> beuno: not just yet, I'm going to deploy a demo copy at my house
[05:41] <beuno> lifeless, re: bug #242046
[05:41] <beuno> is bzr uninstalable too?
[05:41] <beuno> I used PPAs copy feature, and have had to re-upload without it akready for gutsy
[05:42] <lifeless> beuno: bzr and bzrtools - both
[05:42]  * beuno grumbles
[05:42] <beuno> I'll re-upload now
[05:42] <beuno> so the copy tool is not really useful...
[05:43] <beuno> (or I'm using it wrong, which is more probable)
[05:44] <beuno> hrm, that's odd. I *did* re-upload bzr for feisty
[05:45] <beuno> not bzrtools though
[05:45] <lifeless> well
[05:45] <lifeless> the problem is the dependency on python-central
[05:49] <beuno> buildlog seems to think the right version was used: http://launchpadlibrarian.net/14569048/buildlog_ubuntu-feisty-i386.bzr_1.5.0-1~bazaar1~feisty1_FULLYBUILT.txt.gz
[05:51] <lifeless> ok
[05:51] <lifeless> may just be bzrtools;)
[05:51] <lifeless> let me uninstall that and upgrade bzr
[05:51] <beuno> I'm fixing bzrtools now
[05:51] <lifeless> ok bzr is fine
[05:52] <beuno> cool, I'll upload bzrtools in a minute
[05:52] <beuno> sorry about that
[05:55] <lifeless> np
[05:59]  * beuno uploads and waits for the build deamons to wake up
[06:01] <Peng> Bug 241938?!
[06:03] <lifeless> Peng: yah, we should be able to handle such files
[06:04] <lifeless> theres nothing in the disk format preventing handling them
[06:04] <Peng> How much work would it take not to read entire files into RAM?
[06:06] <lifeless> Peng: for simple storage and tree building, not a huge amount, though doing it without affecting performance for normal files is important
[06:08] <lifeless> Peng: for delta storage, diffs, merge its much tricker
[06:10] <lifeless> delta storage depends on diffs
[06:10] <lifeless> merge could just write .BASE, .OTHER, .THIS and give up
[06:10] <lifeless> but three-way merge etc is nice to offer, and that depends on diff
[06:11] <lifeless> in a high entropy file the line count is about 1/256 the file length, a 1.4G file is 5.6million lines long
[06:12] <lifeless> if we hash the file to (say) sha1, its still 100MB per instance of the file (20*5.6million)
[06:12] <lifeless> which is pretty high
[06:13] <lifeless> and easily exploited to cause DOS by having many more \n's.
[06:21] <beuno> lifeless, re-uploaded bzrtools, should be fixed, but can you double check?
[06:25] <lifeless> beuno: its good now
[06:26] <beuno> :)
[07:19] <jelmer> lifeless: hmm, I'll give that a try some time
[07:19] <jelmer> lifeless: the loggerhead frontend certainly is very fast!
[07:20] <jelmer> jml: you need to run make these days (or ./setup.py build_ext --inplace)
[07:20] <lifeless> jelmer: revno 42 should work nicely for you
[07:20] <Peng> jelmer: Is bzr-svn supposed to have any old-style classes?
[07:21] <jelmer> Peng: nope
[07:21] <Peng> It has 11. :P
[07:21] <jelmer> is there anything in particular bad about old style classes?
[07:22] <jelmer> or is it just a stylistic thing?
[07:22] <Peng> For me, it's stylistic.
[07:26] <lifeless> jelmer: is there a small svn repo around you run live tests against ?
[07:26] <lifeless> jelmer: in particular one that bzr-svn supports :P
[07:28] <jelmer> I generally use svn://svn.samba.org/smb-build/trunk
[07:29] <jelmer> lifeless: if you've got any repositories in particular that don't work, please file a bug..
[07:29] <lifeless> jelmer: do you support repository.weave_store.get_weave ?
[07:30] <jelmer> lifeless: nope, don't support any weave implementation at all
[07:30] <jelmer> not as provider, that is
[07:30] <lifeless> jelmer: are you working on it? (will be needed for stacking)
[07:30] <Peng> jelmer: fwiw, I have a branch up at http://bzr.mattnordhoff.com/bzr/bzr-svn/trivial/new-style-classes that fixes all of the old-style classes I could find.
[07:31] <jelmer> lifeless: I'm planning to work on it, haven't started yet
[07:31] <lifeless> jelmer: and can you point me at the bits of bzr-svn that would give access to the svn backing data?
[07:31] <jelmer> lifeless: Trying to finish my own python bindings atm
[07:31] <jelmer> lifeless: what do you mean with backing data specifically?
[07:32] <jelmer> lifeless: *svn python bindings
[07:32] <jelmer> Peng: thanks, I'll have a look at merging that
[07:32] <Peng> :)
[07:34] <lifeless> jelmer: I'd like to make bzr-search index svn repos
[07:35] <lifeless> jelmer: all it needs is a non-colocated branch object supporting the repository graph and versionedfile apis
[07:36] <jelmer> Peng: merged, thanks
[07:37] <jelmer> lifeless: Getting the versionedfile APIs to work is a fair amount of work
[07:37] <jelmer> lifeless: the graph code is all there
[07:39] <lifeless> eww
[07:39] <lifeless> bzr: ERROR: libsvn._core.SubversionException: ("Can't find a temporary directory", 20014)
[07:40] <lifeless> jelmer: ^ hints?
[07:40] <lifeless> jelmer: I did '/home/robertc/bin/bzr', 'checkout', '--lightweight', 'svn://svn.samba.org/smb-build/trunk', 'sbm-build-test'
[07:44] <lifeless> 4.G free on /
[07:44] <lifeless> 198 files in /tmp/
[07:46] <jelmer> hmm, no - what version of bzr-svn is this?
[07:46] <lifeless> svn --version
[07:46] <jelmer> you may want to try with the latest release just to be sure
[07:46] <lifeless> svn, version 1.4.6 (r28521)
[07:46] <lifeless>    compiled Mar 11 2008, 08:53:49
[07:46] <lifeless> I'm running hardy
[07:47] <lifeless> happens just running svn co
[07:50] <jelmer> also happens running svn co you mean?
[07:51] <lifeless> svn: Can't find a temporary directory
[07:51] <lifeless> I mean
[07:51] <lifeless> $ svn co svn://svn.samba.org/smb-build/trunk
[07:51] <lifeless> svn: Can't find a temporary directory
[07:51] <jelmer> time for strace :-)
[07:52] <lifeless> garh
[07:52] <lifeless> I was hoping you had seen fuckage before :)
[07:53] <jelmer> I vaguely recall something like this
[07:53] <jelmer> but don't remember the specifics :-(
[07:53] <Peng> Set TMP or whatever, just to check?
[07:58] <lifeless> server side fuckage
[07:58] <lifeless> http://rafb.net/p/sOwYPM49.html
[08:00] <lifeless> the first line, I think, is the key
[08:00] <lifeless> read(3, "( success ( ) ) ( success ( 36:e8204dac-47fa-0310-9482-a4e8a03ab89e 29:svn://svn.samba.org/smb-build"..., 4096) = 105
[08:01] <lifeless> sorry, line 5
[08:01] <lifeless> read(3, "( success ( ( ) 0: ) ) ( failure ( ( 20014 32:Can\'t find a temporary directory 77:/home/tretkowski/s"..., 4096) = 170
[08:01] <lifeless> success (failure!)
[08:01] <jelmer> hardcoehmm, chroot broken perhaps :-(
[08:02] <jelmer> hardcoded paths?
[08:02] <lifeless> well, I'm not tretkowski :P
[08:02] <lifeless> bzr-svn work with gcode yet ?
[08:02] <jelmer> yeah, always has afaik
[08:03] <lifeless> k
[08:03] <lifeless> I'll hunt for a small project there ;P
[08:03] <jelmer> you just need the svn+ hack to work around the fact that bzr aborts as soon as it gets a permission denied
[08:05] <Peng> Oh.
[08:06] <Peng> Hmm.
[08:06] <Peng> With the 0.4 branch, trying to branch http://ack.googlecode.com/svn/trunk/ (with or without "svn+") exits after a second with a return code of 11.
[08:07] <asabil> lifeless: last time I checked bzr-svn was unable to checkout some code from gcode : http://code.google.com/p/waf/
[08:13] <jelmer> asabil: even with the svn+ hack?
[08:14] <asabil> jelmer: hack ? I was using either http:// or svn+ssh://
[08:15] <jelmer> asabil: I don't remember seeing a bug report about that :-)
[08:15] <jelmer> asabil: I meant svn+http://
[08:16] <asabil> I don't think I tried svn+http
[08:16] <lifeless> jelmer: what needs to happen to fix the bug?
[08:17] <jelmer> lifeless: bzr needs to be somewhat more persistent when probing for repository formats
[08:17] <jelmer> rather than aborting the minute it gets something that's not NotBranchError
[08:18] <lifeless> jelmer: why? what raises the permission denied ?
[08:18] <jelmer> lifeless: trying to open .bzr/branch/format raises a 403
[08:18] <lifeless> rather than a 404?
[08:19] <jelmer> yes, afair that was the problem
[08:19] <lifeless> hmmm
[08:19] <lifeless> so
[08:19] <lifeless> I don't think the driver loop should catch more things
[08:20] <lifeless> the probe functions should catch whatever other things that neither indicate an error nor a found branch
[08:20] <jelmer> I don't think the Bzr branch format catching 403 is very nice though
[08:21] <jelmer> if something's got to do it, rather have it be the driver loop
[08:23] <lifeless> well
[08:23] <lifeless> how can the driver loop tell that 403 means 404?
[08:25] <lifeless> have we filed a bug with googlecode that it gives 403 when a 404 is appropriate?
[08:25] <lifeless> (I agree that the Bzr branch format catching 403 is not nice). But I also think that the driver catching 403 is  not nice
[08:26] <lifeless> because, if you had nested branches, typeA and typeB
[08:26] <jelmer> ah, and the other reason the svn+ stuff exists is to work around the ssl certificate stuff
[08:26] <lifeless> and there is a permission problem on typeB, typeA can be detected incorrectly
[08:29] <lifeless> what will address the ssl certiicate stuff?
[08:31] <jelmer> there's an ancient bug report open about bzr dealing with self signed certificates
[08:38] <lifeless> k, I have a lightweight checkout
[08:38] <lifeless> so I can fiddle
[08:39] <lifeless> no promises, but if I get something shaping up I'll give you a branch
[08:39] <lifeless> now for dinner and games though :)
[08:40] <jelmer> cool
[08:40] <jelmer> have a nice weekend
[08:40]  * jelmer goes and removes the last dependencies on the official svn python bindings
[08:45] <Jc2k> oooh
[08:45] <gour> congrats jelmer
[08:45] <gour> they finally did 1.5.0, but still....
[08:45] <Peng> Would your bindings be usable by other projects?
[08:46] <jelmer> Peng: in theory, yes
[08:47] <jelmer> however, they're not very well documented and the set I converted is limited to what bzr-svn needs
[08:47] <gour> that's good enough
[08:49] <jelmer> if there are other projects interested in using these bindings as well, I'd happily provide them as a separate package
[08:53] <jelmer> I'd rather wait for such projects to ask first though, rather than putting all of the work in now to find out nobody cares
[09:27] <lifeless> jelmer: you still support 1.4 w/patches?
[09:27] <lifeless> jelmer: (hardy only has that ...)
[09:29] <lifeless> jelmer: how do I get a repository id out of a bzr-svn branch object?
[09:30] <jelmer> lifeless: yeah, patches aren't even necessary anymore
[09:30] <jelmer> lifeless: branch.repository.uuid
[09:46] <lifeless> jelmer: and the relative path to the branch?
[09:46] <lifeless> jelmer: I'm going to use uuid/branch-path-here/ as a lookaside index path
[09:50] <jelmer> lifeless: branch.get_branch_path()
[10:08] <lifeless> hi AfC
[10:09] <AfC> lifeless: Good evening
[10:14] <AfC> Is there a command [line client command] which lists all the revision properties / metadata of a given revision?
[10:14] <lifeless> I don't think there is today
[10:14] <lifeless> some of the data can be pretty big and is not human consumable
[10:15] <AfC> Huh
[10:15] <lifeless> gcommit stores per-file commit messages as revision properties
[10:16] <AfC> (oh yeah? What consumes it?)
[10:16] <lifeless> I think gannotate or something
[10:16] <lifeless> jam will know
[10:16] <AfC> (not important)
[10:33] <lifeless> AfC: speaking of locale, ulrich drepper rejected the latin patch for libc
[10:33] <lifeless> AfC: so Ubuntu is carrying it locally :)
[10:34] <lifeless> jelmer: ok, I've got to the point where   File "/home/robertc/.bazaar/plugins/svn/repository.py", line 332, in get_inventory_weave
[10:34] <lifeless>     raise NotImplementedError(self.get_inventory_weave)
[10:34] <lifeless> is triggered
[10:34] <lifeless> jelmer: its kinda slow to get that far :(
[10:48] <AfC> lifeless: Ulrich has always been a hard case.
[10:48] <lifeless> AfC: oh yes :)
[10:49] <lifeless> he applied his trademark tact and diplomacy
[10:49] <AfC> Maybe if you were to become a Benedictine monk or something. That might add credibility (you know, since you have none).
[10:49] <lifeless> :)
[10:49] <lifeless> wasn't my credentials, its was the locals
[10:53] <lifeless> 'just another made up locale' wa the prhase I think
[10:55] <AfC> Yeah, I can see that. Latin is a lot like Klingon, after all.
[10:56] <lifeless> :P
[11:01] <lifeless> ok, its working now for commits
[11:01] <lifeless> jelmer:
[11:04] <lifeless> jelmer: revno 43, if you'd like to tell me what I'm doing wrong that makes it so slow, that would be cool.
[11:40] <lifeless> jelmer: ping
[11:42] <lifeless> jelmer: where do you want bugs filed, ctrl-C was having trouble stopping 'bzr search test' on http://waf.googlecode.com/svn/trunk
[11:46]  * Jc2k is tempted to forcefully upgrade parents to ubuntu
[11:47] <Jc2k> lifeless: will bzr-search work against bzr-mirror.gnome.org :)
[11:52] <lifeless> Jc2k: yes, bzr-mirror is native bzr
[11:52] <lifeless> Jc2k: I recommend fresh indices with revno 42
[11:53] <Jc2k> cool i might give that a spin later
[11:59] <lifeless> if you do, you could also try the loggerhead branch that supports it :)
[12:00] <Jc2k> presumably thats now all shiny and wsgi-ify-arific
[12:00] <Jc2k> in which case, take me to ur url :)
[12:00] <lifeless> yes
[12:01] <lifeless> https://code.edge.launchpad.net/loggerhead
[12:01] <lifeless> second from top
[12:07] <Jc2k> this ok for bzr-search: cd ~/.bazaar/plugins && bzr branch lp:bzr-search search && cd search && bzr revert -r40
[12:07] <Jc2k> ?
[12:07] <lifeless> no need to revert
[12:09] <Jc2k> 40 was wrong anyway, i meant 42
[12:09] <lifeless> 43 is fine too
[12:09] <lifeless> but < 42 will use a different index logic that gives poorer results on searches
[12:10] <Jc2k> i see
[12:10] <Jc2k> rar, the search branch of loggerhead hard depends on a bzr-search that is globally installed
[12:11] <lifeless> well
[12:11] <lifeless> file a bug
[12:11] <lifeless> and show me the error
[12:11] <mwhudson> surely you can fiddle BZR_PLUGINS_PATH ?
[12:11] <Peng> Or run LH as a user with it in his ~/.bazaar/plugins?
[12:12] <lifeless> Jc2k: what user does loggerhead run as
[12:14] <Jc2k> lifeless: at the moment, as me, but in a second im going to move it to x469yq
[12:15] <lifeless> pastebin thee rrror
[12:17] <lifeless> Jc2k: it should not depend on a global install of bzr-search
[12:17] <lifeless> Jc2k: if you can pastebin the error I can advise
[12:18] <lifeless> Jc2k: for different accounts, just put bzr-search in the ~/.bazaar/plugins/search dir in the relevant account
[12:18] <Jc2k> lifeless: sorry, laptop just ran out of power
[12:18] <Jc2k> lifeless: thats where it is
[12:19] <Jc2k> this is going to be painful.. *tries to remember copy and paste in putty*
[12:21] <Jc2k> lifeless: line 20 of loggerhead/search.py
[12:21] <Jc2k> from bzrlib.plugins.search import errors
[12:21] <Jc2k> No module named search
[12:21] <lifeless> ok, do this
[12:21] <lifeless> python -c 'import bzrlib.plugins.search'
[12:22] <Jc2k> same error
[12:22] <lifeless> ok
[12:23] <lifeless> for me:
[12:23] <Jc2k> ah
[12:23] <Jc2k> got it
[12:23] <lifeless> :P
[12:24] <Peng> Does Loggerhead use any global bzr settings for anything, like your username or something?
[12:24] <lifeless> Peng: well, it doesn't do commits
[12:24] <Peng> Yeah, but..
[12:24] <lifeless> Peng: but yes, it does load the global settings
[12:24] <Peng> Do any of them affect it?
[12:24] <lifeless> dunno
[12:25] <Peng> My only ones are email, editor and LP user.
[12:25] <lifeless> I can't imagine any of those affecting it
[12:25] <Peng> Anyway, I'm moving it to its own user, and wondering if I should copy bazaar.conf over.
[12:25] <lifeless> Jc2k: what was wrong?
[12:26]  * Jc2k blushes
[12:26] <Jc2k> fix was
[12:26] <lifeless> Jc2k: also, currently indices are per-branch, not per-repository (because search shouldn't return commits from a different branch), so you probably only want to index trunk; a full text index is a pretty large fraction of the history in the first place
[12:26] <Jc2k> cd ~/.bazaar && mv search plugins/
[12:26] <lifeless> Jc2k: :P
[12:26]  * Jc2k blushes some more
[12:27] <Jc2k> ok. i'll index conduit/trunk first. what is the command foo?
[12:27] <lifeless> bzr index conduit/trunk
[12:27] <lifeless> or
[12:27] <lifeless> cd conduit/trunk && bzr index
[12:28] <Jc2k> and i can run that every time i update the mirror?
[12:28] <lifeless> nah
[12:28] <lifeless> it will keep itself up to date once indexed
[12:28] <Jc2k> sweet!
[12:28] <lifeless> (or at least its meant to; we can check that it is by running your script and searching for something in the most recent commit)
[12:30]  * Jc2k desperately wants to learn more about bzr internals some time so he can hack on things :)
[12:30] <Jc2k> k, the conduit index was quite quick
[12:32] <Jc2k> awesome
[12:32]  * Jc2k searches for fixme :)
[12:32] <lifeless> its currently case insensitive only
[12:32] <lifeless> sorry
[12:33] <lifeless> sensitive
[12:33] <Jc2k> what are your thoughts on showing GNOME this?
[12:33] <Jc2k> i want to keep up the "look at this shiny shiny" blogging
[12:33] <lifeless> well
[12:33] <lifeless> you're supporting the mirror :P
[12:34] <Jc2k> hmm
[12:34] <lifeless> I would say
[12:34] <lifeless> give beuno a few days to polish loggerheads UI for it
[12:34] <lifeless> its web2.0y
[12:35] <lifeless> but a little crude
[12:35] <Jc2k> kk
[12:35] <lifeless> talk to him when he gets up though
[12:35] <lifeless> and get it running so you can tell him what bits suck and what don't :)
[12:35] <Jc2k> :D
[12:36] <Jc2k> the only think i noticed is that it finds a revision, but i have no clue what file the match is in
[12:36] <Jc2k> thing, even
[12:36] <ToyKeeper> hrrm...  looks like bzr_access does 'bzr' but not 'access' yet.
[12:37] <lifeless> ToyKeeper: I recall a patch or two for that recentl
[12:38] <ToyKeeper> I took a quick look, and it appears the reason it doesn't do per-repo permissions is because the repo path isn't specified in SSH_ORIGINAL_COMMAND.
[12:41] <ToyKeeper> Every "bzr push bzr+ssh://host/path/to/repo" results in "bzr serve --inet --directory=/ --allow-writes" on the remote side.  I'm not sure how to get the /path/to/repo part.
[12:43] <ToyKeeper> At least, it's not in os.environ anywhere.  Maybe there's a better place to look.  :)
[12:44] <lifeless> ToyKeeper: does bzr_access hook into the smart server methods, or just wrap things ?
[12:45] <ToyKeeper> As far as I can tell, it just wraps things...  look up the ssh user, then replace the --directory= and --allow-writes parameters, and exec bzr.
[12:45] <lifeless> ah
[12:47] <ToyKeeper> Granted, that's sufficient for my personal use...  but it's not very useful for more than one user.  :)
[12:51] <clemente> Hi. I have this: „etec“ is a link to /etc, and is listed to be added to the repository. I want not to add it, so I try: „bzr remove --keep etec“. And the result: „bzr: ERROR: Not a branch: "/etc/".“
[12:51] <clemente> So I can't remove it
[12:52] <lifeless> clemente: I think there is a bug open
[12:52] <lifeless> clemente: you need to:
[12:52] <lifeless> rm <link>; bzr remove <link>
[12:53] <lifeless> ln -s <whatever>
[12:53] <Peng> (or mv <link> <link>.bak or something..)
[12:54] <clemente> lifeless: thanks, that works
[13:00] <clemente> It's bug 236149, by the way
[13:00] <Pieter> Vienna:5.0 pieter$ time bzr pull lp:mysql-server/6.0
[13:00] <Pieter> bzr: ERROR: These branches have diverged. Use the merge command to reconcile them.
[13:00] <Pieter> real	25m3.689s
[13:01] <Pieter> why does that have to take 23 minutes?
[13:01] <Jc2k> what happens if you do it again?
[13:01] <mwhudson> which bzr version?
[13:01] <mwhudson> there was a bug here
[13:02] <Pieter> 1.5
[13:02] <Peng> Were the performance issues pulling from packs to knits fixed?
[13:02] <Pieter> Jc2k: then it's 'just' 23 seconds
[13:02] <lifeless> Pieter: it has pulled the data in
[13:03] <lifeless> Pieter: repeat the operation; bet you it will be much faster
[13:04] <Pieter> yeah, 60x as fast is ok
[13:04] <lifeless> Peng: well, knits to packs has to annotate
[13:04] <lifeless> Pieter: hmm, 30 seconds still. likely an index problem:
[13:05] <lifeless> http://bazaar-vcs.org/RobertCollins#head-b2dc9ae46f1860c46f79682db455c3512152d148
[13:05] <lifeless> Peng: I believe it should be 'ok' to pull to knits, not stellar, but ok
[13:06] <Jc2k> Pieter: can you answer a gitweb question?
[13:06] <Pieter> Jc2k: perhaps, try me :)
[13:07] <Jc2k> *grabs a url*
[13:08] <Jc2k> ok question 1, how can i make the first page faster. its scanning 520 modules and is insanely slow.
[13:09] <Jc2k> question 2, have a look at http://git-mirror.gnome.org/?p=glib;a=summary
[13:09] <Pieter> what version of gitweb do you have? (out of which git version?)
[13:09] <Pieter> there have been patches for the slow listing, I think they were integrated into 1.5.5 or 1.5.6
[13:10] <Jc2k> its a bare mirror, i have down git --bare svn fetch, how to i update "master" to svn/trunk?
[13:10] <Jc2k> *done
[13:10] <Pieter> git update-ref svn/trunk master
[13:11] <Pieter> eh
[13:11] <Pieter> reverse those
[13:11] <Jc2k> is that a once per update thing, or a once per repository thing?
[13:11] <Pieter> once per update
[13:12] <Pieter> if you want to do it for always, try git symbolic-ref master svn/trunk
[13:13] <Pieter> or rather, git symbolic-ref refs/heads/master refs/remotes/svn/trunk, or wherever it is
[13:14] <Jc2k> will that cause any problems for people cloning from git-mirror.gnome.org ?
[13:15] <Pieter> no
[13:17] <Jc2k> ace
[13:17] <Jc2k> thank you for answering my questions Pieter, as always :)
[13:17] <Jc2k> what as the git-gc command you wanted me to run?
[13:18] <Pieter> git repack -adf --window=100 or so should do
[13:18] <Jc2k> i'll run that and the symbolic-ref thing when theres some free time on the server then
[13:19] <Jc2k> im guessing that'll be about 4 hours
[13:19] <Pieter> make sure you have the refs right :) i'm not sure wher git-svn stores its refs
[13:20] <Jc2k> will do!
[13:22] <Pieter> Jc2k: http://kerneltrap.org/mailarchive/git/2008/3/13/1160884 << about projcet list caching
[13:39] <Jc2k> Pieter: does one of those say "this is in HEAD and will be in git 1.x"?
[13:40] <Jc2k> :)
[13:40] <Pieter> Jc2k: no. There's a gitweb caching GSoC going on though that will be in 1.6.0
[13:40] <Jc2k> ah
[13:49] <Peng> This is weird... when one of my branches was branched over http, the smart server was barely used at all.
[13:49] <Peng> Absolutely none of the more bandwidth-intensive requests used it. There are a couple dozen hits to the indexes and packs.
[13:52] <awilkins> Peng: Do people find HTTP more convenient?
[13:52] <Peng> awilkins: ?
[13:53] <awilkins> Peng: Are you saying that making it availeble over HTTP makes people use the smart server less, or that serving over HTTP doesn't USE the smart server?
[13:54] <lifeless> Peng: it falls back to VFS operations for many things today; spiv has been working on making it do so less; possibly there are bugs there, or the client was one tat doesn't have his work incorporated
[13:55] <Peng> One person branched this branch over http. It auto-detected bzr+http being available, but barely used it.
[13:56] <Peng> There were 35 hpss requests and 49 for packs or indices.
[13:56] <lifeless> wow, very chatty
[13:56] <Peng> Hmm, does the smart server log?
[13:56] <lifeless> yes
[13:56] <lifeless> .bzr.log
[13:56] <Peng> Huh.
[13:57] <Peng> Well, it's running as my web servers user, and it doesn't have a home dir. Oh well.
[13:57] <Peng> server's*
[14:09] <jelmer> lifeless: filed as bugs against bzr-svn in lp
[14:10]  * jelmer reads his backlog
[14:10] <spiv> jelmer: I've seen flurry of commits on bzr-svn recently.  How's the cext going?
[14:13] <jelmer> spiv: it's there and working :-)
[14:15] <spiv> jelmer: sweet
[14:21] <spiv> jelmer: if I want to try out the shiny new stuff, which branch should I sue?
[14:21] <spiv> Er, "use" :)
[14:22] <Jc2k> eh, we know your motives now spiv :P
[14:22] <jelmer> the 0.4 one
[14:24] <jelmer> lifeless: woot on getting bzr-search working against svn!
[14:26] <spiv> jelmer: hmm, I get a segfault if I try to pull in my python trunk conversion (in svn_auth_set_parameter), and traceback if I try to pull in my Twisted trunk checkout (KeyError for u'trunk' in _get_old_id).
[14:27] <spiv> I mustn't be lucky tonight :)
[14:28] <jelmer> please try pulling again
[14:29] <jelmer> I'm pushing my latest changes now
[14:29] <jelmer> hmm, one sec
[14:37]  * spiv -> zzz
[14:40] <jelmer> spiv: g'night
[14:40] <jelmer> awilkins: ping
[14:55] <Jc2k> lifeless: my server is about to explode :P k thx bai
[14:58] <Jc2k> its sucked up 95% of memory :)
[14:59] <Jc2k> it seems to have calmed down now
[15:33] <jelmer> Jc2k: what were you running?
[15:36] <Jc2k> jelmer: bzr index
[15:36] <Jc2k> on gcompris
[15:52] <MvG> Is there any verbose documentation about the different repository formats? I'm especially curious about the difference between rich-root and rich-root-pack.
[16:15] <Peng> MvG: rich-root is dirstate-tags (well, the repo hasn't changed since knit) only with rich roots, and rich-root-pack is pack-0.92 only with rich roots.
[16:18] <MvG> What are rich roots?
[16:21] <jelmer> MvG: in rich root formats, the root directory has a file id
[16:22] <MvG> Ah.
[16:22] <jelmer> MvG: older formats don't store a file id for the root directory
[16:23] <MvG> What's the kind of operation that uses this feature?
[16:23] <MvG> Anything to do with having nested branches?
[16:23] <MvG> What's the status of nested branches, by the way?
[16:24] <jelmer> yeah, nested branches need root ids
[16:24] <jelmer> bzr-svn also relies on root ids because it avoids a lot of special casing and corner cases
[16:25] <jelmer> MvG: LarstiQ was working on it last I heard
[16:25] <jelmer> LarstiQ: ping
[16:34] <LarstiQ> has no one else done anything with it?
[16:36] <jelmer> not afaik
[16:36] <LarstiQ> ok
[16:46] <vxnick> Hi All - got a bit of a problem if anyone can help?
[16:47] <fredreichbier> just ask, vxnick ;)
[16:48] <vxnick> Thanks - basically, I'm tracking an upstream by way of "svn export" (as I can't get bzr-svn working for one reason or another)
[16:49] <vxnick> I'm tracking this in "upstream/project", (which I "bzr init"-ed) - I then "bzr add" and "bzr commit" these files
[16:49] <vxnick> The problem I'm having is merging the contents of that project into an empty trunk (which is a checkout)
[16:49] <vxnick> It tells me the working copy is out of date, although a "bzr update" doesn't do anything as there's nothing in the repository
[16:50] <vxnick> I also managed to get a nice traceback somehow :(
[16:51] <vxnick> Now, merging the contents into trunk works fine (bzr status shows N+ for each file), but I can't commit these as it says there are no changes to commit
[16:55] <vxnick> When I bzr update, it shows "-D" next to each file, and I get "bzr: ERROR: Reserved revision-id {null:}" (presumably because I'm on revision 0)
[16:56] <vxnick> bzr status then shows whitespace next to each filename
[16:56] <vxnick> and bzr commit deletes the files, but throws a traceback and this error: bzr: ERROR: exceptions.AssertionError: 2 != 1
[16:57] <vxnick> any ideas, fredreichbier?
[16:59] <Peng> Wow.
[16:59] <Peng> Using "svn export" for a mirror is pretty awful.
[16:59] <Peng> You should really try to get bzr-svn -- or any other converter -- working.
[16:59] <vxnick> Yeah, I gave it a couple of goes but with no luck
[17:00] <Peng> What issues were you having?
[17:00] <vxnick> bah, I can't remember now
[17:00] <vxnick> it was a couple of weeks ago I last tried
[17:01] <vxnick> I was working on the basis that "svn export" doesn't export any history with it, just a clean tree
[17:01] <vxnick> in effect working the same as if I were to add the files myself
[17:03] <clemente> vxnick: that's what I was thinking... Can you reproduce the problem if you add the files yourself? Maybe the problem has nothing to do with Subversion
[17:03] <vxnick> bear with me and i'll give it a go now...
[17:06] <clemente> I myself am getting a crash with „bzr status“ and I'm trying to figure out the cause
[17:06] <clemente>   File "/Werkstatt/bzr.dev/bzrlib/tsort.py", line 415, in __init__
[17:06] <clemente>     parents = self._graph.pop(branch_tip)
[17:06] <clemente> KeyError: 'pop(): dictionary is empty'
[17:06] <vxnick> clemente: same issue when adding the files myself
[17:06] <Peng> Uh-ohs.
[17:07] <Peng> clemente: Up-to-date bzr.dev?
[17:07] <vxnick> just to clarify - should I be "bzr init" the directory when I add the files, along with bzr add and bzr commit, then merge into trunk?
[17:07] <clemente> Peng: almost; one moment...
[17:08] <clemente> Peng: yes
[17:09] <Peng> clemente: If you can find a way to reproduce this, file a bug.
[17:09] <Peng> (Well, search for existing bugs first...)
[17:09] <clemente> What's the efficient way of finding out more about an error? Inserting „pdb.set_trace()“? Turning on some debug mode...? Running tests?
[17:10] <Peng> clemente: You can run it so it'll automatically drop into pdb, but I forget how.
[17:11] <vila> BZR_PDB=1 ?
[17:11] <clemente> vila: yes
[17:12] <clemente> vxnick: I suppose that init+add+commit should work... (Do they work without problems for you?) The big problems could be with the merge
[17:13] <clemente> vxnick: if you get errors, maybe you can debug them. BZR_PDB=1 :-)
[17:13] <vxnick> clemente: those work fine for me usually, so I think you're right in that it's the merge.
[17:14] <vxnick> I presume you can merge something into an empty directory, or do you need to have the same (older) files there beforehand?
[17:14] <vxnick> I could pull the files in, but then the parent dir for the trunk would be the upstream, which doesn't make much sense to me
[17:16] <vxnick> the main problem, to clarify, seems to be that "bzr commit" doesn't commit the merge to the repository - bzr status shows the new files, and I can see them in the physical directory of the trunk too
[17:16] <vxnick> "commit" just reckons there's no changes, thus nothing to commit
[17:18] <clemente> I thought „commit“ sends the changes to your branch, whereas „push“ sends them to the remote repository. I would try „push“ and „merge“ instead of „commit“
[17:18] <vxnick> I've got a remote repository setup with a checkout on my local machine
[17:19] <vxnick> commit can work locally and/or remotely I believe
[17:19] <vxnick> if you are using a checkout
[17:19] <vxnick> I believe push/pull work for a branch
[17:19] <vxnick> but I'm quite new to bazaar, so might be wrong :)
[17:22] <clemente> vxnick: yes, right. I'm also new and in fact I still haven't succeeded in doing a „merge“...
[17:22] <vxnick> I've managed to merge branches locally, but this is the first time I've tried merging into a checkout
[17:23] <vxnick> I have prevously "bzr init"-ed a directory and then branched it, then merged from the branch back into the "trunk"
[17:23] <vxnick> if you branch something, you have to "pull" the changes from the original dir into the new branch - I think that merges as well automatically
[17:24] <vxnick> if you want to merge the differences from the new branch to the old, you use merge
[17:24] <vxnick> if that makes sense
[17:29] <clemente> vxnick: I don't know. I would try looking at where the error message comes from in the code, in case you get an error
[17:29] <vxnick> yeah I might try that, but I'm not familiar with Python
[17:29] <vxnick> and I have to do some weird stuff to get the trace from it
[17:30] <vxnick> other than that, it's just the generic bzr error messages such as "working copy out of date" and so on
[17:31] <clemente> Then look if the syntax you're using is the correct one
[17:31] <clemente> You may also find a way to reproduce it to see if some other person sees the problem
[17:33] <vxnick> yeah fair enough
[17:33] <clemente> Don't worry... I have just gotten your error :-)
[17:33] <clemente> bzr: ERROR: Reserved revision-id {null:}
[17:33] <clemente> After doing a merge of a patch I created with „send“
[17:34] <Leonidas> What is the command to modify the working tree to look like some older revision?
[17:35] <Leonidas> I've tried both checkout and update, but none of them lets me specify the desired revision
[17:35] <vxnick> bzr revert?
[17:35] <vxnick> or uncomitt
[17:35] <vxnick> uncommit*
[17:36] <vxnick> see what "bzr help revert" or "bzr help uncommit" show - that should help :)
[17:36] <Leonidas> vxnick: bzr revert seems to be what I needed. Right. uncommit whould be too much, I don't want to loose the tip/HEAD
[17:36] <vxnick> ah right
[17:36] <Leonidas> btw, that is the name of the most recent revision? hg calls it tip, git HEAD and bzr? -1?
[17:37] <LarstiQ> Leonidas: -1 is a shorthand for that, yes
[17:37] <vxnick> HEAD I think
[17:38] <LarstiQ> vxnick: not in a tool addressable way
[17:38] <LarstiQ> Leonidas: but if you want to talk terminology in discussions, tip or head would be understood
[17:39] <Leonidas> LarstiQ: ok, thanks.
[17:46] <clemente> vxnick: I got also „D-“ on update
[17:47] <vxnick> is that with a checkout?
[17:48] <clemente> Problem is: rev_id=null  here:
[17:48] <clemente>   /Werkstatt/bzr.dev/bzrlib/mutabletree.py(52)tree_write_locked()
[17:48] <clemente> -> return unbound(self, *args, **kwargs)
[17:48] <clemente> > /Werkstatt/bzr.dev/bzrlib/workingtree_4.py(1103)set_parent_trees()
[17:48] <clemente> -> _mod_revision.check_not_reserved_id(rev_id)
[17:48] <clemente> But I don't understand more
[17:48] <clemente> vxnick: it was with init+merge+update
[17:49] <clemente> where the merge came from a patch file (created with „bzr send“)
[17:49] <clemente> It happens also with latest bzr
[17:50] <vxnick> have you tried just a normal merge?
[17:50] <clemente> You mean, from a repository instead of from a file?  (No)
[17:53] <vxnick> try making a dir "bzr init dir" then branching it to "dir2" - add a couple of files with some random text in "dir" and then cd to dir2 and "bzr pull". Make some changes in "dir2", cd to "dir" and "bzr merge ../dir2"
[17:58] <clemente> vxnick: I suppose you had to do „commit“ at least once after the „init“
[17:59] <clemente> otherwise you stay at revision 0
[17:59] <vxnick> yeah, sorry
[17:59] <vxnick> and bzr add before the commit
[17:59] <clemente> (and this may be the problem for rev_id to be null...)
[18:04] <clemente> vxnick: ok, it stays there without errors under „pending merges“
[18:04] <clemente> (I did a „commit“ also on dir2)
[18:04] <vxnick> do a commit and it should work
[18:05] <clemente> Ok, so no problems in update/commit/status
[18:05] <clemente> My first successful merge, thanks for the help :-)
[18:05] <clemente> Now I try with a patch file instead of with a repo
[18:10] <clemente> Ok, I only get the error message if the merge occurs before revision 1
[18:11] <clemente> This fails on „update“:  mkdir bzr00004; cd bzr00004; bzr init; bzr merge /n/resprueba/mezcla ; bzr update
[18:11] <clemente> But this works:  mkdir bzr00005; cd bzr00005; bzr init; echo a>b; bzr add b; bzr commit -m "be"; bzr merge /n/resprueba/mezcla ; bzr update
[18:12] <clemente> So the problem is doing the „merge“ before you have done a „commit“ on your new repository
[18:12] <clemente> I suppose it's a bug
[18:16] <asabil> clemente: how do you want to merge in an empty repo ?
[18:16] <asabil> They have no parent in common
[18:17] <clemente> Is it not allowed?  „merge with empty“ == „branch“?
[18:18] <asabil> clemente: try to pull
[18:19] <clemente> Yes, „pull“ works
[18:20] <clemente> I think then that instead of failing, bzr should show an error message which says that (you can't merge in an empty repository)
[18:22] <Peng> s/repository/branch/
[18:23] <clemente> But I thought that after „init“ you got really an empty repository, that is, a first parent (a root parent)
[18:37] <Peng> s/repository/branch/
[18:38] <clemente> Thanks. Does „repository“ mean „collection of branches“?
[18:38] <Peng> No.
[18:38] <Peng> A repository is a big bag of revision data.
[18:38] <clemente> A branch too
[18:39] <Peng> No.
[18:39] <clemente> Or a branch is the place, and the repository the content?
[18:39] <Peng> On disk, a branch is simply the ID of the most recent revision in that branch. That's used to figure everything else out from the revisions in the repository.
[18:43] <clemente> I submitted bug 242175, about improving the error message
[18:44] <clemente> Peng: where can I find precise definitions of those concepts? (applied to Bazaar)
[18:44] <Peng> I dunno; user guide?
[19:30] <clemente> (Peng: yes, it was)
[19:30] <clemente> What's that about a „smart server“? Does it work? According to [1] it's still under design phase. [1]: http://bazaar-vcs.org/Specs/SmartServer
[19:30] <Peng> clemente: Yes the smart server works.
[19:32] <clemente> Ok, I'll try it
[19:32] <Peng> clemente: It still doesn't have optimal performance, but they're working on it, and it's perfectly usable today.
[19:33] <Peng> clemente: FWIW, I always use the smart server.
[19:34] <Peng> clemente: If you're using a knit repo (upgrade!), it's a huge performance improvement. Packs are fast enough that it's not really, but it probably would be if you're moving a lot of data, and anyway, it's cooler and getting better all the time.
[19:35] <clemente> Can you also use on a machine where you can't modify apache.conf?
[19:36] <Peng> clemente: bzr+http? Um, can you modify .htaccess?
[19:37] <clemente> Yes
[19:43] <Peng> clemente: You can use it then
[19:43] <Peng> clemente: You can install bzr?
[19:45] <clemente> Yes
[19:46] <clemente> Is that in the manual?
[19:46] <Peng> Is what?
[19:47] <clemente> The explanations for setting up the smart server with .htaccess
[19:47] <clemente> I only find that for ssh, inetd, or a dedicated server
[19:48]  * Peng shrugs.
[19:48] <Peng> When I set it up, I used the documentation.
[19:49] <clemente> I will read more documentation then
[19:49] <Peng> Hmmm.
[19:49] <Peng> You're right.
[19:49] <Peng> That section doesn't mention it.
[19:50] <Peng> The source tree has doc/en/user-guide/http_smart_server.txt
[19:50] <Peng> Not sure where to find it in the html
[19:51] <Peng> clemente: Oh, it's at the bottom, in an appendix. http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#serving-bazaar-with-fastcgi
[19:51] <Peng> clemente: (You don't need to use FastCGI.)
[20:16] <clemente> Ok, thanks for all help, I will continue learning bzr; bye
[20:33] <bkor> jelmer: "It generates inefficient code - it generates proxy classes that " <-- ends abruptly
[20:35] <awilkins> jelmer: pong
[20:45] <jelmer> bkor: whoops, thanks
[20:46] <jelmer> awilkins: The C extensions branch is there!
[20:46] <jelmer> and passing all tests on Linux
[20:47] <Peng> Hmm. I was able to push bzr-svn into a rich-root-pack repo, but not upgrade the subtree repo to it.
[20:49] <jelmer> Peng: Hmm, that sounds like a bug
[20:50] <Peng> jelmer: (I meant bzr-svn's repo itself, not an svn repo managed by bzr-svn.)
[20:50] <Peng> I was also left with a "repository.backup".
[20:50] <Peng> Probably the same thing that happened to you a couple days ago.
[20:50] <Peng> Bzr flatly refused to do it since, of course, rich-root-pack doesn't support subtrees.
[20:51] <jelmer> Ideally, bzr would only refuse to upgrade from subtree to rich-root-pack if there was actually a revision in that repository that used subtrees
[20:52] <Peng> Yep.
[20:52] <Peng> And it already has the proper machinery, since push can do it.
[20:53] <jelmer> Push probably breaks if you try to push a revision with a subtree into rich-root-pack
[20:53] <Peng> That's what I mean. Push probably handles it exactly how upgrade should.
[20:54] <edcrypt> some of this info seems outdated: http://live.gnome.org/DistributedSCM
[20:55] <jelmer> Peng: I mean that it breaks badly :-)
[20:55] <Peng> Oh.
[21:01] <bkor> edcrypt: please update
[21:02] <edcrypt> bkor: will try to research some references...
[21:10] <mwhudson_> morning
[21:10] <Jc2k> evening mwhudson_ :)
[21:11] <mwhudson_> Jc2k: did you see that you can run loggerhead trunk now? :)
[21:11] <Jc2k> mwhudson_: did you try search on my copy of loggerhead ;)
[21:11] <Jc2k> you should be able to give it a spin on gtk+ now :)
[21:13] <mwhudson_> neat :)
[21:13] <Jc2k> so yeah, im running a different branch now :)
[21:14] <mwhudson_> heh, ok
[21:16] <Jc2k> its very had not to blog about the loggerhead foo :)
[21:18] <Jc2k> mwhudson_: i can link loggerhead into apache more now?
[21:18] <Jc2k> rather than having it running in a screen session :P
[21:19] <Peng> Heh, I have it running in screen too.
[21:22] <Jc2k> i guess i just need mod_wsgi
[21:27] <mwhudson_> Jc2k: i guess so, yes
[21:27] <mwhudson_> Jc2k: feel free to blog
[21:27] <mwhudson_> i don't really know if there are any real actual advantages to mod_wsgi
[21:27] <Jc2k> mwhudson_: waiting a few days for some bueno polish :)
[21:27] <mwhudson_> oh, ok :)
[21:28] <mwhudson_> beuno: i see you noticed your ~loggerhead-team membership :)
[22:05] <lifeless> moin
[22:05] <thumper> morning
[22:09] <mkanat> mwhudson_: Trying loggerhead trunk, getting a traceback with start-loggerhead.py: http://pastebin.mozilla.org/465681
[22:10] <mwhudson_> mkanat: you use auto_folder ?
[22:10] <mkanat> mwhudson_: I do.
[22:10] <mwhudson_> i bet i never even checked that
[22:10] <mwhudson_> mkanat: have you seen the new serve-branches.py script?
[22:10] <mkanat> mwhudson_: I have, but I don't want to serve everything in the path. Is that avoidable?
[22:11] <mwhudson_> not without programming i guess
[22:13]  * mwhudson hmms
[22:14] <mwhudson> actually it's url_prefix that's broken i think
[22:14] <mkanat> Oh, hmm.
[22:15] <mkanat> Yeah, I need that unless I can just tell it "strip off the /var/www/html/everythingsolved.com/bzr/ from every path for the URL".
[22:16] <lifeless> jelmer: any comment on the speed issue it has?
[22:16] <mwhudson> truth be told, i've never understood the purpose of many of the things you can put in loggerhead.conf :)
[22:16] <mkanat> mwhudson: Heh. :-)
[22:17] <mwhudson> mkanat: i just pushed r166 of trunk, try that?
[22:17] <lifeless> Jc2k: which branch chewed all your ram while indexing?
[22:17] <mwhudson> morning lifeless
[22:18] <mkanat> mwhudson: Yes, that seems to be running! :-)
[22:19] <mwhudson> mkanat: woo!
[22:19] <Jc2k> lifeless: i'm not entirely sure if it was bzr index or not, but things got a little rough on the box for trunk of... gcompris, gimp-help, gimp and guadec-web
[22:19] <mwhudson> mkanat: i hope this one doesn't chew all your ram...
[22:19] <Jc2k> i aborted them..
[22:19] <mkanat> Well, the first plus I can see is that my log isn't full of 404s. :-)
[22:19] <lifeless> Jc2k: oh it likely was :)
[22:19] <lifeless> Jc2k: can you edit index.py
[22:19] <Jc2k> gimp.. i dont know, i was just worried it would break so i abored it anyway
[22:19] <lifeless> look for group_size = 2500
[22:20] <Jc2k> lifeless: i can, but i'd prefer not to whilst it was still running
[22:20] <Jc2k> its indexing nautilus
[22:20] <lifeless> drop that down and repeat until it stays happy
[22:20] <lifeless> I'd like to figure out some way to auto tune
[22:20] <jelmer> lifeless: 'morning
[22:20] <jelmer> lifeless: speed issue?
[22:20] <lifeless> Jc2k: uhm, its fine to do as its running :P
[22:20] <mkanat> mwhudson: I'm getting a few tracebacks in my debug.log, though not sure what the problem is (I just have spiders that are crawling the site, apparently). Want to see the traceback?
[22:21] <lifeless> jelmer: in the backlog; it was very slow at indexing just the commits via bzr-svn
[22:21] <mwhudson> mkanat: yeah, let's have a look
[22:21] <mkanat> mwhudson: http://pastebin.mozilla.org/465683
[22:21] <lifeless> Jc2k: the .py -> .pyc will be recompiled the next time python loads it
[22:22] <mwhudson> mkanat: so i think that happens when someone browses to blah/blah/inventory?file_id=file_id_of_non_directory
[22:23] <mwhudson> mkanat: it's possible we're generating a bogus link somewhere
[22:23] <mkanat> mwhudson: Ah. And that link shows up in the UI? (This is the Googlebot doing this, apparently.)
[22:23] <mwhudson> mkanat: it seems unlikely that googlebot just made such a url up, indeed :)
[22:23] <mkanat> mwhudson: And WOW, this version is WAY better on the resources!
[22:24] <mkanat> I can't even pick it out in top's list.
[22:24] <mwhudson> mkanat: :)
[22:24] <lifeless> jelmer: the easiest way to show you is for you to try it yourself :P
[22:26] <mwhudson> mkanat: i can't see anywhere where a bogus link like that would be generated
[22:26] <mkanat> mwhudson: I'll watch my apache log for referrers.
[22:26] <mwhudson> mkanat: it's possible that we fixed this bug without noticing at some point and googlebot is remembering it
[22:26] <mkanat> mwhudson: Yeah, that is possible.
[22:27] <mwhudson> mkanat: one idea
[22:27] <mkanat> Ah, I couldn't pick it out in top because it wasn't there--I had Ctrl-C'ed and I forgot that I was running ./start-loggerhead.py -f. :-)
[22:27] <mwhudson> mkanat: do you have an 'updir' link in the root of the branch (in the files view)?
[22:28] <mkanat> mwhudson: I'll look.
[22:28] <mwhudson> that's something i could imagine going wrong
[22:28] <mwhudson> (though it doesn't in my tests)
[22:28] <mwhudson> mkanat: this branch should still be a lot better than the old version on resources
[22:28] <mwhudson> mkanat: please let us know how it does over time
[22:29] <mkanat> mwhudson: Yeah, it is so far.
[22:29] <mkanat> mwhudson: Yeah, I will.
[22:29] <mkanat> mwhudson: Oh, problem.
[22:29] <awilkins> jelmer: So the 0.4 branch now has the cext branch merged in it?
[22:29] <mkanat> mwhudson: The URLs look like http://localhost:8080//bzr.everythingsolved.com//vci/stable/revision/88
[22:30] <jelmer> lifeless: I'm confused - bzr-search appears to rely on weaves which bzr-svn doesn't have
[22:30] <mkanat> mwhudson: Which is the path to the local server, not the right URL.
[22:30] <mwhudson> mkanat: oh bugrit
[22:30] <mwhudson> mkanat: i thought i'd fixed that
[22:30] <jelmer> awilkins: yep
[22:30] <lifeless> jelmer: it only indexes commit messages on SvnBranch objects today
[22:30] <mwhudson> ugh, indeed, totally not
[22:31] <jelmer> lifeless: ah, ok
[22:31] <lifeless> jelmer: yesterday I did the various bits of machinery needed to teach it where to store an index for a svn branch, and disabled the stuff it couldn't use
[22:31] <awilkins> jelmer: Will distutils build them?
[22:31] <jelmer> awilkins: yes
[22:32] <lifeless> jelmer: if you change commits_only = True, to False on line 161 of index.py you can see it fail to access weaves :)
[22:32] <mwhudson> mkanat: fixing...
[22:33] <mkanat> mwhudson: Okay. :-)
[22:33] <mwhudson> mkanat: can you try r167 from https://code.edge.launchpad.net/~mwhudson/loggerhead/config-vhost ?
[22:34] <mkanat> mwhudson: I can just pull from that into my current?
[22:34] <mwhudson> yes
[22:34] <mkanat> mwhudson: Wow, bzr does not like that URL.
[22:35] <mwhudson> mm
[22:35] <mwhudson> it should redirect to the branch
[22:35] <mwhudson> lp:~mwhudson/loggerhead/config-vhost should work better
[22:35] <mkanat> mwhudson: http://pastebin.mozilla.org/465687
[22:35] <Jc2k>  Sorry, you don't have permission to access this page.
[22:35] <Jc2k> You are logged in as John Carr.
[22:36] <mwhudson> oh
[22:36] <thumper> ???
[22:36] <mwhudson> mkanat: try again
[22:36] <mkanat> bzr: ERROR: Not a branch: "http://bazaar.launchpad.net/~mwhudson/loggerhead/config-vhost/".
[22:37] <thumper> ah
[22:37] <thumper> mkanat: there will be a pause
[22:37] <thumper> mkanat: while the http system realises that it is no longer private
[22:37] <mkanat> Okay.
[22:37] <thumper> mkanat: give it a minute or so
[22:38] <mkanat> bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/%7Eloggerhead-team/loggerhead/trunk/.bzr/branch/lock): Transport operation not possible: http does not support mkdir()
[22:39] <mwhudson> what command line are you running??
[22:39] <mkanat> mwhudson: bzr pull https://code.edge.launchpad.net/~mwhudson/loggerhead/config-vhost
[22:39] <mwhudson> (do you have a checkout? in which case 'bzr unbind')
[22:39] <mkanat> Oh, right, I should unbind.
[22:39] <mkanat> mwhudson: Thanks. :-)
[22:39] <mkanat> mwhudson: I had it bound manually so that I could just type "bzr up" when I wanted to.
[22:40] <mwhudson> uh
[22:40] <mwhudson> 'bzr pull' should work
[22:40] <mwhudson> mkanat: oh, this branch will require paste.deploy, btw
[22:40] <mkanat> mwhudson: Okay, that version dies: http://pastebin.mozilla.org/465688
[22:41] <mwhudson> PrefixMiddleware(app, translate_forwarded_server=True, prefix=webpath)
[22:41] <mwhudson> i.e. add the 'app' argument
[22:41] <mwhudson> (sorry)
[22:41] <mkanat> Okay.
[22:41] <Jc2k> lifeless: i halved it, whatever that will lead to..
[22:42] <mkanat> mwhudson: Now my frontpage URLs are slightly wrong: http://bzr.everythingsolved.comvci/stable
[22:43] <mkanat> mwhudson: And if I fix that in the URL bar, the internal URLs look like: http://bzr.everythingsolved.comhttp%3a//bzr.everythingsolved.com/vci/stable/revision/88
[22:43] <mwhudson> so basically, that didn't work at all
[22:43] <mwhudson> mkanat: what's the server.webpath in your loggerhead.conf ?
[22:44] <mkanat> server.webpath = 'http://bzr.everythingsolved.com/'
[22:44] <mkanat> I just added that slash.
[22:44] <mkanat> So it was server.webpath = 'http://bzr.everythingsolved.com'
[22:44] <mwhudson> mkanat: so if you remove that
[22:44] <mwhudson> and the "translate_forwarded_server=True"  in start-loggerhead.py
[22:44] <mwhudson> then it should Just Work
[22:44] <LarstiQ> (TM)
[22:45] <mkanat> mwhudson: It originally didn't have the /.
[22:45] <mkanat> mwhudson: Adding the slash makes no difference, it seems.
[22:45] <mwhudson> mkanat: but that worked with the old loggerhead, right?
[22:46] <mkanat> mwhudson: Yeah, slashless worked with the old loggerhead.
[22:46] <mwhudson> so two things (1) do what i said above, that should get you working (2) i have some work to do to get perfect compatibility with old loggerhead.conf files
[22:47] <mkanat> mwhudson: Oh, remove server.webpath entirely?
[22:47] <mwhudson> mkanat: yes
[22:47] <mkanat> Okay, here we go! Let's try. :-)
[22:48] <mkanat> Okay, with both of them gone, the front page works.
[22:49] <mkanat> mwhudson: But the internal URLs look like: http://localhost:8080/vci/stable/revision/88
[22:50] <mwhudson> mkanat: you are running behind apache using mod_proxy ?
[22:50] <mkanat> mwhudson: Yeah, I think so.
[22:51] <mwhudson> oddness
[22:52] <mkanat> mwhudson: Here's my Apache conf: http://pastebin.mozilla.org/465704
[22:52] <mwhudson> mkanat: that's not mod_proxy, that's mod_rewrite :)
[22:52] <mkanat> mwhudson: Well, [P] is using mod_proxy, no?
[22:53] <mwhudson> hm, maybe
[22:53] <mwhudson> anyway, what paste.deploy is doing is relying on HTTP_X_FORWARDED_SERVER
[22:54]  * mkanat read the Apache docs just now and it says that [P] does indeed use mod_proxy.
[22:54] <mwhudson> yeah, me too
[22:55] <mkanat> mwhudson: Anywhere I could put some debug code to spit out that env var?
[22:56] <mwhudson> def (environ, start_response, orig=app):
[22:56] <mwhudson>  print environ
[22:56] <mwhudson>  return orig(environ, start_response)
[22:56] <mkanat> mwhudson: In what file?
[22:56] <mwhudson> in start-loggerhead.py, just before the serve call
[22:57] <mkanat> Okay.
[22:57] <mkanat> mwhudson: In the try block?
[22:58] <mwhudson> mkanat: yeah, should work
[22:58] <mwhudson> (doesn't matter much, basically)
[22:58] <mkanat> def (environ, start_response, orig=app):
[22:58] <mkanat>         ^
[22:58] <mkanat> SyntaxError: invalid synta
[22:59] <mwhudson> erm
[22:59] <mwhudson> do you know python well?
[22:59] <mkanat> I know it, but I don't know these frameworks well enough.
[22:59] <mkanat> And I don't know it well enough to know what an empty def call does.
[23:00] <mwhudson> i typed three lines for that function
[23:00] <mwhudson> mkanat: http://pastebin.ubuntu.com/22225/
[23:00] <mwhudson> mkanat: phone now, brb
[23:00] <mkanat> mwhudson: Okay.
[23:00] <mkanat> (Ahh, it was nameless originally.)
[23:01] <mwhudson> mkanat: oops :)
[23:01] <mkanat> 'HTTP_X_FORWARDED_SERVER': 'bzr.everythingsolved.com'
[23:01] <mwhudson> mkanat: sorry about this, thanks for being patient
[23:01] <mkanat> mwhudson: Hey, no problem.
[23:02] <mwhudson> mkanat: and then still funky urls?
[23:02] <mkanat> mwhudson: Yep.
[23:02] <mwhudson> grr
[23:02] <mkanat> Not *as* funky as they used to be.
[23:02] <mkanat> I mean, at least these could theoretically be right, if I was somehow on the server itself. :-)
[23:03] <mkanat> You can see it here if you want: http://bzr.everythingsolved.com/vci/stable/changes
[23:04] <mkanat> HTTP_X_FORWARDED_HOST is also bzr.everythingsolved.com.
[23:05] <mwhudson> mkanat: i wonder what version of paste deploy you have?
[23:05] <mkanat> rpm -q python-paste
[23:05] <mkanat> python-paste-1.6-1.el5
[23:06] <mkanat> rpm -q python-paste-deploy
[23:06] <mkanat> python-paste-deploy-1.3.1-1.el5
[23:06] <mwhudson> mm, pretty close to the same as me
[23:08] <mkanat> Hmm, welcome to "our product has no changelog".
[23:09] <mkanat> Ahh, yes it does.
[23:09] <mkanat> It was just cleverly hidden.
[23:09] <mkanat> mwhudson: What version of paste-deploy do you have?
[23:10] <mwhudson> 1.3.1-2 (ubuntu hardy here)
[23:10] <mkanat> Yeah.
[23:10] <mkanat> Okay, so yeah, the same.
[23:11] <mkanat> mwhudson: And paste 1.6?
[23:12] <mwhudson> 1.6-2
[23:13] <Peng> What's this about url_prefix being broken?
[23:13] <mwhudson> Peng: if you're not using loggerhead.conf. it shouldn't affect you
[23:14] <Peng> Indeed I am not.
[23:15] <Peng> I'm using serve-branches.py with the Paste Deploy prefix thingy. :)
[23:15] <Peng> (If that's what url_prefix does..)
[23:16] <mwhudson> Peng: it's not
[23:16] <Peng> Heh, okay.
[23:16] <Peng> I'll shut up then. :)
[23:16] <mwhudson> mkanat: try this patch: http://pastebin.ubuntu.com/22228/
[23:17] <mwhudson> i think i was getting too complicated :)
[23:55] <poolie_> good morning