[12:02] <AnMaster> lifeless, um, how would I tell gpg on command line what key to use?
[12:04] <hstuart> AnMaster, gpg -u user@domain.ext
[12:04] <AnMaster> ah
[12:05] <hstuart> I've wrapped my signing in a separate command file as gpg -u identity --clearsign $*   seems to work fairly well
[12:06] <hstuart> though I haven't really found a good way to see who has signed what commits
[12:06] <AnMaster> bzr: ERROR: Failed to gpg sign data with command [u'/usr/bin/gpg -u anmaster (AT) users.sourceforge.net', '--clearsign']  (it really said @ but I don't know if this channel is logged public and I hate spam)
[12:06] <AnMaster> why not some more detailed error message?
[12:07] <hstuart> AnMaster, you have to wrap it in a separate script and give that as the gpg_signing_command
[12:07] <AnMaster> oh? that seems odd
[12:07] <hstuart> I battled around with that for a while as well
[12:07] <hstuart> I think it has to do with the way that python executes separate processes, but I never bothered to investigate too closely
[12:08] <AnMaster> by the way using "$@" is in 99.99% percent of the cases better than $*
[12:08] <AnMaster> don't forget the quotes
[12:12] <lifeless> hstuart: you should not have --clearsign in your script
[12:12] <lifeless> hstuart: bzr supplies --clearsign
[12:12] <AnMaster> lifeless, but why is a script needed at all?
[12:13] <hstuart> lifeless, ah, well, then it gets really clearsigned ;)
[12:13] <lifeless> AnMaster: I'd say 'its a bug', I think there is a bug open on it
[12:13] <AnMaster> k
[12:14] <hstuart> AnMaster, right
[12:14] <AnMaster> ok, signing all current 135 commits, means I have to enter my key 135 times?
[12:14] <hstuart> heh
[12:14] <AnMaster> seems a lot harder to use than ssh-agent
[12:14] <AnMaster> that I use currently
[12:15] <lifeless> AnMaster: did you try kgpg ?
[12:15] <AnMaster> lifeless, well, it didn't work as it should
[12:15] <lifeless> ah well
[12:15] <hstuart> lifeless, is there a good way to see who has signed what commits, btw? I've been looking for that
[12:15] <lifeless> hstuart: hmm, don't think so
[12:15] <hstuart> drat - anything planned?
[12:15] <AnMaster> lifeless, is seems to support it's own set of options for command line processing
[12:15] <lifeless> it would be great to have someone step up and put some love into that
[12:15] <lifeless> AnMaster: :(
[12:16] <hstuart> lifeless, ok, I'll take that as a no then :)
[12:16] <AnMaster> or at least a very limited set of gpg options
[12:16] <lifeless> hstuart: its planned in the abstract
[12:16] <lifeless> hstuart: but I'm not aware of anyone actually wokring on it
[12:16] <AnMaster> anyway, any hints on gpg-agent?
[12:16] <lifeless> no idea, I haven't used gpg-agent
[12:16] <hstuart> yeah, I've seen the launchpad plan, but the gpg things haven't received any updates in forever
[12:17] <hstuart> ah well, anyway, off to bed, 'night
[12:17] <lifeless> gnight
[12:18] <lifeless> vila: re []  in argument lists, i think you are a little confused
[12:18] <lifeless> vila: try this:
[12:18] <lifeless> >>> def foo(l=[] ):
[12:18] <lifeless> >>>  l.append('1')
[12:18] <lifeless> >>>  print l
[12:18] <lifeless> >>> foo()
[12:18] <lifeless> >>> foo()
[12:18] <AnMaster> got to sleep too
[12:18] <AnMaster> hopefully gpg-agent will look less complex when I wake up
[12:18] <AnMaster> :)
[12:19] <lifeless> AnMaster: you could disable your passphrase
[12:19] <lifeless> sign them all
[12:19] <lifeless> reinstate it
[12:19] <AnMaster> lifeless, ugh, sounds insecure
[12:19] <lifeless> no more than having a process that will sign a document if asked over a local socket
[12:20] <AnMaster> hm
[12:20] <AnMaster> night
[12:20] <lifeless> (assuming you are not surfing etc at the time, don't have sshd running ...)
[12:20] <lifeless> night
[12:21] <AnMaster> lifeless, well I don't have any server running on my desktop as the user I use in x, I do have some test ones as other users
[12:21] <AnMaster> *locks x session, switches to a vt, runs vlock -a*
[12:21] <lifeless> there you go then, sounds fine :)
[12:45] <vila> lifeless: can't sleep, but no, not confused, I perfectly understand your example
[12:46] <lifeless> vila: so why did you say that the commands.run method will display the same behaviour?
[12:47] <vila> they will not, but they are always *called* with fixes=[] , so either we make it the default value (cmd_commit uses it as read-only) or we begin by if fixes is None: fixes =[] 
[12:48] <vila> both will have the same result, ok, the later is less risky, but how in hell will cmd_commit decide that it knows how to fix something ?
[12:48] <lifeless> I would use a tuple myself in this case
[12:48] <lifeless> fixes=()
[12:48] <lifeless> because its safe
[12:48] <lifeless> but it would need to be changed if commit started mutating the list
[12:49] <vila> Yeah, I see the point, was grumpy :)
[12:49] <poolie> hello
[12:49] <vila> hi poolie
[12:50] <poolie> hi vila
[12:52] <beuno> hello, poolie, I've got a question stored for you about the translation of the bzr docs, got a minute?
[12:52] <poolie> sure
[12:52] <vila> lifeless: in another context (still  related to []  as a default value)
[12:53] <beuno> I'm translating it into spanish, and I was wondering how to structure a few things, for example, the index.txt
[12:53] <vila> I introduced possible_transports in various methods as the way to share connections
[12:53] <beuno> should it be under docs as index.es.txt?  in the /es/ dir?  if that's the case, shouldn't the english one be moved to /en/ too?
[12:55] <vila> In one review John said that since I wanted to push people to use possible_tranports (p_t) I may as well declare it with a default value of [] 
[12:55] <lifeless> beuno: index.txt in the es dir
[12:55] <lifeless> vila: John was smoking his toenails that day then.
[12:55] <beuno> lifeless, and the english one stays under /doc/?
[12:56] <lifeless> beuno: I'd mail the list Ithink actually
[12:56] <lifeless> I'm sure igc has a plan, but hes not here yet
[12:56] <poolie> that would be cool to have it translated
[12:56] <beuno> lifeless, alright then, seems like the best place to gather opinions, will do that
[12:56] <poolie> beuno, do you think translating the ui is important too?
[12:56] <beuno> I've got about 20% translated
[12:56] <beuno> poolie, absolutely!
[12:57] <vila> lifeless: :) not completely, it may provide local caches for the duration of a bzr command
[12:57] <beuno> I'm currently translating the docs to reflect what bzr will actually say (in english), but the ideal situation would be to have everything localized
[12:58] <poolie> vila, what may?
[12:58] <vila> lifeless: still problematic for long running users as GUIs though
[12:58] <lifeless> vila: no, it will not be weakref. It will hold sftp links etc open for the entire runtime of e.g. graphical tools using bzr.
[12:58] <vila> lifeless: yup
[12:58] <lifeless> vila: Its a terrible idea to abuse this language defect like tat.
[12:58] <vila> lifeless: I didn't :)
[12:58] <poolie> if you're talking about mutating the paramater default as a hidden global variable i agree
[12:59] <lifeless> Good :)
[12:59] <poolie> that sounds pretty bad
[12:59] <lifeless> Apparently jam suggested that.
[12:59] <lifeless> I claim he was smoking his toenails.
[01:00] <beuno> and having it for me employees is a bonus
[01:06] <vila> lifeless: my bad, John didn't propose that but instead to make it a mandatory parameter
[01:07] <lifeless> vila: ah!
[01:07] <lifeless> much saner
[01:10] <vila> And I didn't implement it because I'm still unsure on where (in terms of code paths) the caching should be activated unconditionally
[01:11] <synic> is there a FAQ on how to improve the performance of a larger repository?
[01:11] <synic> is there a way we can mark old changes as 'obsolete' or something?
[01:12] <lifeless> synic: we're working on changes in teh core, targeted for0.92, to massively improve that
[01:12] <synic> anything I can do until then?
[01:13] <ignas> 3+ hours to push a branch to launchpad
[01:13] <ignas> and it's still below 50% of the progress bar
[01:13] <ignas> am i doing something wrong? maybe i shouldn't have used sftp as the protocol?
[01:17] <J-diddy> swapping it out with bzr+ssh:// will definitely help
[01:17] <lifeless> ignas: 0.92 will include bzr+ssh improvements that make it about 20% slower than rsync
[01:17] <lifeless> ignas: don't stop it now though
[01:17] <lifeless> ignas: when it hits 50% its actually about 80% or more done
[01:17] <ignas> i know, it just got to Fetch 3/4
[01:17] <lifeless> synic: not really sorry. Its a performance bug in bzr.
[01:18] <ignas> but having a 70mb repository is a bit painful, because event with maximum upload speed it still would take quire a lot
[01:18] <ignas> not 3 hours a lot though ;)
[01:18] <ignas> lifeless: thanks for the heads up though
[01:22] <synic> lifeless: are the changes in 0.92 something that launchpad will be able to integrate easily?
[01:24] <igc> morning all
[01:25] <lifeless> synic: yes
[01:26] <lifeless> poolie: calling ok ?
[01:26] <poolie> k
[01:45] <poolie> vila, were your cpu problems due to trackerd?
[01:48] <vila> no, first it was... evms, I uninstalled it
[01:50] <abentley> vila: Do you want a reply to your post re: [] ?
[01:50] <vila> then it was khubd, I went a bit bersek and deactivated services: bluetooth, powernowd, acpid, apmd, mdadm
[01:50] <vila> abentley: I will add a comment explaing that I was confused as lifeless pointed out a bit earlier :)
[01:50] <abentley> Okay.
[01:51] <vila> point (and door) closed :)
[01:52] <poolie> hello abentley
[01:52] <abentley> Hi there.
[01:54] <poolie> vila, thankyou for the patch for bug 140614
[01:54] <ubotu> Launchpad bug 140614 in bzr "selftest noise re _http_start" [Low,Fix committed]  https://launchpad.net/bugs/140614
[01:54] <poolie> can you explain to me briefly why this fixes it though?
[01:55] <poolie> why would releasing the semaphore cause the socket fd to be invalid?
[01:55] <vila> I didn't double-checked, but most probably the client was already using the socket while the server try to set the timeout
[01:57] <vila> as Aaron as pointed out, my previous fix, by releasing hundreds of sockets should have make the code faster (ftp tests should be even more affected as medusa relies on asyncore which use select)
[01:58] <vila> the fun thing is that when I saw the bug report and look at the code I wondered why the settimeout was before the lock release... so I tried that first... it worked
[02:02] <vila> poolie: does that sound convincing ?
[02:03] <poolie> enough for me
[02:03] <vila> ok
[02:21] <poolie> abentley, i got a reply to my request to install python-kid on the machine that serves bazaar-vcs.org
[02:21] <poolie> apparently it's hard because that machine runs dapper and kid is not in dapper
[02:21] <poolie> so our options are
[02:21] <poolie> - just live without it
[02:21] <poolie> - try to install kid from source
[02:21] <poolie> (not sure if there would be other problems)
[02:22] <poolie> - something else, like building the docs elsewhere and uploading them
[02:24] <abentley> I did have Kid installed from source on dapper, and had no trouble with that.
[02:24] <abentley> But if this is going to be a big problem, maybe we should look at another way of building pretty docs.
[02:25] <abentley> I just don't want to invent a new template language.
[02:25] <poolie> heh
[02:25] <poolie> yeha
[02:25] <poolie> i mean, yeah
[02:26] <ubotu> New bug: #140834 in bzr "too many futex syscalls" [Undecided,New]  https://launchpad.net/bugs/140834
[02:26] <abentley> Realistically, I guess we can look into what docutils provides by way of customization.
[02:26] <poolie> maybe that would be cleaner
[02:27] <poolie> if you think i should install kid and it will work i'm happy to do that
[02:29] <abentley> I'd be surprised if it didn't work.  It depends on how comfortable you are with having software on that machine not managed by apt[itude] .
[02:30] <poolie> personally i'm fine with it
[02:30] <poolie> it's more that sometimes you get into a rabbithole of missing dependencies
[02:31] <abentley> I installed kid with easy_install, as part of TurboGears.
[02:34] <abentley> It appears to have no dependencies, but if the install becomes painful, we can try a different approach.
[02:35] <fullermd> Hm.  There's a port of it.
[02:35] <fullermd> It lists the dependancies as python, py-setuptools, and py-elementtree
[02:36] <abentley> 0.9.6 no longer requires elementtree, AIUI.
[02:37] <fullermd> This is 0.9.5, so that could be
[02:37] <fullermd> Anyway, you got elementtree around for bzr anyway, so it doesn't matter.
[02:37] <abentley> Yes, that was a change in 0.9.6
[04:25] <ubotu> New bug: #140844 in bzr ""bzr log --line --verbose" does not work" [Undecided,New]  https://launchpad.net/bugs/140844
[04:59] <spiv> lifeless: abentley's reconcile doesn't introduce that corruption when run on a hand-fixed repo.
[05:00] <lifeless> spiv: can you confirm that it does not fix it either ?
[05:01] <spiv> lifeless: sure, give me ~20 min.
[05:19] <Stevage> hey guys, what does this mean: bzr: ERROR: Permission denied: u'C:/bzr/Tlib62/.bzr/repository/lock/held': [Error 5]  Access is denied
[05:20] <lifeless> well
[05:20] <lifeless> it means that either th elock or unlock failed
[05:20] <lifeless> your bzr trace file (run bzr --version to see where that is) will have a traceback
[05:21] <lifeless> is that dir readonly for you?
[05:21] <lifeless> do you have write access to it ?
[05:23] <Stevage> yeah, this is during a massive sequence of commits
[05:23] <Stevage> so like 300 commits in a row succeeded, then that one failed
[05:23] <fullermd> Sorry, the trial version only allows 300 commits per day.  You can upgrade for $39.95...
[05:23] <Stevage> ok I have the traceback
[05:24] <Stevage> :)
[05:25] <poolie> that reminds me of a bug alexander posted about recently
[05:25] <spiv> lifeless: confirmed: abentley's reconcile doesn't fix the corruption.
[05:25] <Stevage> http://rafb.net/p/PAed8E45.html
[05:25] <poolie> i think i merged something for that
[05:26] <spiv> Now to fix that.
[05:26] <lifeless> spiv: I think you have a new test case for his check and reconcile work then :)
[05:26] <lifeless> spiv: its good to know that it doesn't introduce it.
[05:26] <lifeless> now, WTF does.
[05:28] <spiv> lifeless: good question!
[05:29] <poolie> Stevage: are you using 0.91rc?
[05:29] <Stevage> no, .09
[05:29] <Stevage> .90
[05:29] <Stevage> I did download .91rc2 but I wasn't sure how to merge my changes into it?
[05:35] <poolie> Stevage: did you make your changes in the downloaded-from-tarball tree?
[05:35] <poolie> Stevage: i'm not 100
[05:35] <poolie> Stevage: i'm not 100% sure but i think this is fixed in 0.91
[05:35] <Stevage> no I haven't
[05:35] <Stevage> is there a way to merge my changes in .90 to the .91 ver?
[05:36] <Stevage> I mean, I know I can do it by hand, but I'm curious whether i can merge it?
[05:40] <ubotu> New bug: #140857 in bzr ""bzr: interrupted" should say where it was interrupted" [Wishlist,New]  https://launchpad.net/bugs/140857
[05:40] <ubotu> New bug: #140858 in bzr "when selftest is interrupted, it should show the results of all	tests so far" [Medium,New]  https://launchpad.net/bugs/140858
[05:49] <lifeless> 
[05:49] <lifeless> real    1m27.526s
[05:49] <lifeless> user    1m20.481s
[05:49] <lifeless> sys     0m4.476s
[05:59] <Stevage> ok, done. is there a way to precompile my python source so it runs faster each time?
[06:02] <poolie> Stevage: that should happen automatically by producing .pyc files
[06:02] <poolie> as long as the directory is writable
[06:08] <Vantage13> hi, i'm a little confused about bzr-cvsps-import.   I did an import using 0.18 or bzr and it created a bzr and a staging directory, but I thought it would also checkout the files from CVS.  From what I can see, none of the actually files are there.  There is however, the a directory structure based on the branches, etc...
[06:10] <lifeless> Vantage13: right, you can bzr checkout any of teh branches the converter created
[06:11] <Vantage13> lifeless: really?   Where will it get the files from?  CVS?
[06:13] <fullermd> No, from the bzr branches it just converted.
[06:13] <fullermd> They're there, they just don't have working trees.
[06:19] <Vantage13> fullermd: wow, that's quite cool.  Thanks!
[06:21] <Stevage> hmm, same problem: bzr: ERROR: Permission denied: "C:/bzr/Tlib63/.bzr/repository/lock/held": [Error 5]  Access is denied
[06:22] <Stevage> that's running on .91rc2
[06:22] <Stevage> wait, actually that's 0.92.0dev0
[06:22] <lifeless> whats the backtrace look like ?
[06:23] <Stevage> like the one I pasted earlier, if you have ti
[06:23] <lifeless> no, I don't
[06:24] <Stevage> http://rafb.net/p/FJ0j5K59.html
[06:24] <Stevage> (that's fresh)
[06:24] <lifeless> I wonder if there is a fileopen withint that path ?
[06:24] <lifeless> could you please file a bug, including what you are doing to trigger this
[06:25] <lifeless> we care about windows, and its almost certainly a windows specific glitch
[06:25] <Stevage> ok
[06:25] <Stevage> hard to say what I'm doing specially though
[06:25] <lifeless> well
[06:25] <Stevage> I'm doing hundreds of commits, then it just falls over
[06:25] <lifeless> just note that you are doing X commits in y timeframe
[06:25] <Stevage> sure
[06:25] <lifeless> are you using bzrlib or the bzr executable
[06:25] <Stevage> bzrlib
[06:26] <Stevage> both .90 and .92
[06:26] <lifeless> if you are using bzrlib, can you provide the script you are using
[06:26] <Stevage> oh, I mean I'm calling bzr from python
[06:26] <lifeless> it may be a articular sequence of calls neded to trigger this
[06:26] <Stevage> so I guess I mean bzr
[06:26] <lifeless> if you do system('bzr foo bar baz') you're not using bzrlib :)
[06:27] <lifeless> or subprocess.foo('bzr' , ....)
[06:31] <Stevage> heh
[06:31] <Stevage> it's a bit more esoteric than that
[06:31] <Stevage> I'm using a tool called finalbuilder
[06:35] <lifeless> igc: got the mail?
[06:36] <igc> lifeless: yes thanks
[06:36] <igc> I'll try it now
[06:45] <ubotu> New bug: #140869 in bzr "Access denied for lock file" [Undecided,New]  https://launchpad.net/bugs/140869
[06:51] <igc> lifeless: results on my machine emailed back now fyi
[07:00] <lifeless> thanks!
[07:16] <lifeless> of home time
[07:16] <lifeless> spiv: hows it going, do you need an input from me ?
[07:16] <sri> yo
[07:17] <lifeless> sri: yoyo
[07:17] <lifeless> sri: I'm about to go, but if you wanted to chat with me I'll be online in an hourish.
[07:20] <lifeless> spiv: ring if you want to chat about why its not finding the corruption
[07:20] <lifeless> ciao
[07:27] <vila> rats, miss lifeless
[07:28] <vila> I just saw his request to martin about cherrypicking a change into a not-corrupted bzr.dev
[07:28] <vila> does that mean we should do that for all pqm submissions until further notice ?
[07:38] <Stevage> can I copy a file within bazaar?
[07:38] <Stevage> as in, I have a file proj1/foo/blah.c  and want to copy it with history to proj1/boo/blah.c
[07:48] <Stevage> anyone?
[07:50] <fullermd> No, there isn't any such thing.
[07:55] <Stevage> bugger
[07:55] <Stevage> so you can do a rename like that, but not a copy
[07:55] <fullermd> Yeah, you can move files, but there's no copy.
[07:56] <fullermd> Aside from the lack of round tuits, it's a wide-open question what the proper semantics of copy should be in various situations (particularly merges), which is why there isn't one.
[07:58] <Stevage> hmm
[07:58] <Stevage> I can see it's going to take me a while to get used to directory-based version control
[07:58] <lifeless> vila: not 'not corrupted', 'fresh - without packs in it'
[07:58] <Stevage> the tool I'm migrating from is all file-based
[07:58] <lifeless> Stevage: we're planning on copy semantics as an optional thing in the future.
[07:58] <vila> lifeless: pfew, good, sry for the noise :)
[07:58] <lifeless> Stevage: there is wide spread debate on what this means
[07:59] <lifeless> Stevage: one way is to consider the whole project a big bag of lines and get rid of file id except for grouping lines into paths
[07:59] <lifeless> another is to have a more flexible id system that can represent copies as we as moves
[08:00] <fullermd> I've occasionally wished for copies as a way of simulating intra-branch branch/merge'ing.
[08:02] <Stevage> intetresting :)
[08:02] <Stevage> I'll have to subscribe to the list
[08:03] <Stevage> cya everyone
[08:08] <cory> I was a bit surprised that I can't seem to easily produce a diff or even list changed files between two branches, but it looks dead simple to do it with bzrlib.  Am I missing something?
[08:10] <fullermd> -rbranch: or -rancestor:?
[08:11] <cory> Can I do that with two remote branches and no working trees?
[08:11] <fullermd> I don't think so, but that's a bug.
[08:14] <fullermd> I vaguely recall that both diff and stat beg after WT's when they have no need of them.
[08:14] <cory> Ah, ok.
[08:15] <cory> Regardless, Branch.open("foo").basis_tree().changes_from(Branch.open("bar").basis_tree()) seems to give me precisely what I was hoping for. :)
[10:57] <igc> night all
[12:46] <lapthrick> howdy
[12:46] <lapthrick> mathrick@hatsumi:~/Dev$ bzr get svn://svn.gna.org/svn/pokersource/trunk bzr-pokersource
[12:46] <lapthrick> bzr: ERROR: libsvn._core.SubversionException: ('Malformed network data', 210004)
[12:46] <lapthrick> bzr 0.90.0 on python 2.5.1.final.0 (linux2)
[12:48] <lapthrick> http://pastebin.com/f1d0ed055 has the full backtrace
[12:50] <lifeless> lapthrick: I'd file a bug or question on bzr-svn
[01:02] <mtaylor> does anyone know of anything for making bzr work with quilt? Or a bzr project to do something similar?
[01:07] <Kinnison> In what sense? Maintaining a quilt in a bzr branch? maintaining a branch for each patch of a quilt?
[01:57] <mtaylor> Kinnison: I think more like maintaining a quilt in a bzr branch. one of my friends uses quilt on top of bk, but I was thinking it might be nicer if something like that was integrated with bzr or something
[02:04] <lapthrick> mtaylor: I think parts of quilt functionality are already provided by shelve, no?
[02:05] <mtaylor> lapthrick: yes. I think that some of them are, but I'm not sure if you can cherry pick from shelve, can you?
[02:06] <lapthrick> I believe so, AFAIK it does provide you the named changesets function, which is what's needed for cherrypicking
[02:07] <mtaylor> lapthrick: hmm. I'll go play with that then and see
[02:08] <lapthrick> "You can put multiple items on the shelf. Normally each time you run unshelve the most recently shelved changes will be reinstated. However, you can also unshelve changes in a different order by explicitly specifiying which changes to unshelve. This works best when the changes don't depend on each other."
[02:08] <lapthrick> mtaylor: from bzr shelve --help
[02:26] <jelmer> lapthrick: please file a bug report against bzr-svn
[02:28] <lapthrick> jelmer: will do as soon as I wrangle launchpad into resetting my password
[02:28] <lapthrick> which it insists on not doing
[02:28] <jelmer> Looks like I can reproduce it here
[02:28] <jelmer> but the server isn't responding properly
[02:28] <jelmer> even with stock svn
[02:28] <jelmer> svn ls svn://svn.gna.org/svn/pokersource
[02:28] <jelmer> gives the same error
[02:29] <lapthrick> oho, finally
[02:29] <lapthrick> jelmer: however, my svn did checkout without any problems
[02:29] <lapthrick> maybe something changed since then
[02:30] <lapthrick> it was last Friday I believe
[02:30] <jelmer> lapthrick: Your SVN checkout doesn't access the root of the repository (svn://svn.gna.org/svn/pokersource)
[02:30] <jelmer> which is the bit that is causing problems
[02:30] <lapthrick> ahh
[02:31] <lapthrick> jelmer: but I was checkouting trunk/
[02:31] <jelmer> bzr-svn will try to look at the repository root because it tries to retrieve the history of the repository
[02:31] <lapthrick> I see
[02:31] <lapthrick> so it's NOTABUG?
[02:31] <lapthrick> and/or NOTGNOME
[02:32] <jelmer> NOTBZR you mean? :-)
[02:32] <jelmer> I do think it's a bug - bzr-svn should be able to avoid connecting to the repository root
[02:33] <jelmer> at least over some protocols
[02:33] <lapthrick> jelmer: yes, but it's usually NOTGNOME where I come from, so it's a generic "not my problem" status :)
[02:33] <lapthrick> jelmer: I see, but how can you retrieve history then without looking at the root?
[02:33] <lapthrick> you mean it'll only look at the history of the dir specified?
[02:34] <jelmer> lapthrick: there are workarounds - for example, it should be possible to connect to svn://svn.example.com/foo/trunk but then request the log for ".." or "/"
[02:35] <jelmer> the behaviour of the get_log() call in svn differs per protocol (svn://, http://, svn+ssh://) though, which is why we try to avoid that at the moment
[02:37] <jelmer> I think the extra code complexity is worth it, if it means we can support the pokersource repository
[02:38] <lapthrick> jelmer: I see
[02:38] <lapthrick> jelmer: hmm, svn ls worked for me right now
[02:38] <lapthrick> can you retry?
[02:39] <jelmer> hmm, now it works for me too
[02:39] <lapthrick> mathrick@hatsumi:~$ svn --version
[02:39] <lapthrick> svn, version 1.4.4 (r25188)
[02:39] <lapthrick> but bzr still dies
[02:40] <jelmer> is that server perhaps under heavy load or something?
[02:40] <lapthrick> dunno
[02:40] <lapthrick> http:// worked though
[02:40] <lapthrick> I will retry with svn:// once it finishes
[02:41] <lapthrick> mathrick@hatsumi:~$ svn ls svn://svn.gna.org/svn/pokersource
[02:41] <lapthrick> svn: Can't read from connection: Connection reset by peer
[02:41] <lapthrick> jelmer: I guess it might be the server at fault
[02:43] <lapthrick> copying revision  320/2895
[02:43] <lapthrick> oh man, that's not gonna be fast
[03:05] <jelmer> lapthrick: at the moment we have to fetch all historical changes. work has started to make it possible to fetch only the last few revisions
[03:05] <lapthrick> jelmer: isn't it kind of necessary to fetch the whole history to have a real bzr branch?
[03:08] <jelmer> lapthrick: it is possible to do "lazy" fetching - in other words, not fetch anything until the user is trying to access it
[03:08] <lapthrick> I see
[03:09] <AfC> jelmer: [how do you do that?] 
[03:10] <AfC> [oh, sorry, you're talking about bzr-svn. I thought you meant Bazaar itself] 
[03:10] <jelmer> AfC: This is true for Bazaar itself as well
[03:11] <jelmer> AfC: The idea is to make it possible to fetch just the last few revisions of a branch and store a pointer to another branch that contains more of that history
[03:11] <AfC> jelmer: how do you do that, then? Is there a --lightweight option to `bzr branch` as well?
[03:12] <Vantage13> Hi, I'm using bzr 0.18 w/ bzr-cvsps-import to try and import a large CVS repo, but I keep getting memory errors.  Any way around this?
[03:12] <jelmer> AfC: It's not possible yet - these are the stackedrepository / shallow branches specs
[03:13] <AfC> jelmer: ah. I have envisaged a modality whereby the commit messages etc were there (ie, you could run `bzr viz`) but the actual deltas between revisions wouldn't be present unless [able to be]  fetched [on demand, or silent error] 
[03:14] <jelmer> AfC: something like that could be done easily once the shallow branch / stacked repository code is in
[03:15] <jelmer> AfC: but it may involve doing things like caching diffstats for "bzr log -v'
[03:18] <AfC> jelmer: I was more thinking "sorry, diff not available" ... where I was really going with this was trying to avoid the necessity to download / push massive amounts of revisions especially of large code drops that subsequently got deleted before merging
[03:18] <AfC> [this happens a lot for us] 
[03:19] <AfC> [but if I accept the revisions, they're full of all the crap I subsequently expunge, thus traffic] 
[03:20] <fullermd> It strikes me that some sort of graft/rebase is probably the better solution to that problem...
[03:26] <jelmer> AfC: Ah, I see. It should be possible to set a policy as to what bzr should do if a revision is not available in the branch itself - fetch it or consider it a ghost.
[03:29] <TeTeT> how well does bazaar cope with binary files, e.h. PNGs?
[03:32] <radix> TeTeT: well enough that I've never noticed any problems
[03:32] <radix> I've heard rumors that its binary delta algorithm isn't efficient or whatever, but it doesn't concern me
[03:37] <gabe__> i have tens of websites in a bzr repo, they have all manner of binary files, work a treat for me
[03:37] <TeTeT> radix: thx, should be fine with small pngs then
[03:37] <TeTeT> I once run into trouble with some very large files, 10+ MB
[03:37] <TeTeT> but this was an older version, I think 0.13 or so
[03:52] <corporate_cookie> I'm more curious than anything..how dose BZR handle binaries ?
[03:53] <corporate_cookie> the way i understand it ..bzr stores ...sort of a recipe of changes between versions ...it dose not actually store files them selves but rather the instructions to build those files
[03:54] <corporate_cookie> how would this work with a Binary file / a non text based file
[03:54] <radix> corporate_cookie: so, there's an algorithm for efficiently representing differences between text files
[03:55] <radix> corporate_cookie: there's also an algorithm for representing differences between "binary" files, which doesn't rely on newline markers
[03:55] <fullermd> Is there?
[03:57] <radix> google for "binary delta" and "binary diff" :-)
[03:57] <corporate_cookie> radix:  ..how slow / useful is this algorithm ...practically
[03:57] <corporate_cookie> ok : )
[03:58] <fullermd> Oh, I'm aware that there _are_ such algorithms.  I was questioning the part where it had anything to do with bzr at the moment.
[03:58] <radix> oh, I don't know
[03:58] <radix> I was responding to the general question about "how would this work"
[03:58] <lapthrick> corporate_cookie: ..why ...are ...you ...talking ...like ...this?
[03:59] <fullermd> I'm pretty sure that in bzr it works just like text files.
[03:59] <corporate_cookie> lapthrick:  dramatic pauses make life more spicy
[03:59] <corporate_cookie> Captain Kirk
[03:59] <corporate_cookie> ...it worked ... for ...him
[04:17] <mvo> lifeless: hello! I'm playing with bzr-git currently and it seems to not like me currently: http://paste.ubuntu.com/293/ . am I missing something here?
[04:18] <AnMaster> is there anything like $Id$ of svn for bzr, would be helpful for my app to be able to output what revision it is from with --version
[04:18] <AnMaster> or branch + revision perhaps
[04:19] <jelmer> AnMaster: No, not yet - there are plans to add support for such keywords, but it hasn't been implemented yet
[04:19] <AnMaster> ah, it would make support a lot simpler
[04:20] <jelmer> AnMaster: the specification for that feature is at https://blueprints.launchpad.net/bzr/+spec/bzr-keyword-expansion
[04:21] <jelmer> mvo: I think bzr-git has bitrotted recently, think it just needs to be updated to be compatible with more recent versions of bzr
[04:21] <lapthrick> CVS keywords have always bugged me, I have instinctive dislike for anything that's not data-transparent
[04:22] <AnMaster> hm
[04:22] <AnMaster> I don't use CVS so I don't know, but I use svn and bzr
[04:22] <jelmer> lapthrick: yeah, same here. at least svn requires you to explicitly enable them
[04:23] <AnMaster> and it is quite useful to have for --version output on one file with svn
[04:24] <lapthrick> AnMaster: yeah, but CVS quite excelled at having non-transparent features enabled by default
[04:24] <AnMaster> lapthrick, ah that sounds bad
[04:24] <lapthrick> and then you had to disable them for each and every file by hand
[04:24] <lapthrick> woe was you if you forgot to disable linebreak conversion on a binary file or something
[04:25] <AnMaster> what is the best software to do something like viewvc/viewsvn for bzr?
[04:25] <lapthrick> AnMaster: there's bzr-web or what was its name
[04:25] <AnMaster> easy to set up on server preferred
[04:25] <AnMaster> server runs lighttpd on freebsd
[04:25] <jelmer> loggerhead
[04:25] <lapthrick> http://goffredo-baroncelli.homelinux.net/bazaar
[04:26] <AnMaster> hm?
[04:26] <AnMaster> jelmer, and link to loggerhead? and is it easy to set up?
[04:27] <AnMaster> I do not have root access on the server, but I can run python, php and perl scripts on it
[04:27] <lapthrick> http://www.lag.net/loggerhead/
[04:27] <lapthrick> (was not overly easy to google)
[04:27] <jelmer> http://www.lag.net/loggerhead/
[04:28] <AnMaster> any online docs for it? can't find that on it's page
[04:28] <jelmer> whoops, too late :-) I was having trouble with google as well
[04:28] <mvo> jelmer: yeah, it looks like it. I played around with the code a bit, but it seems like there are too many changes for me
[04:28] <jelmer> AnMaster: There's the README.txt in the source tarball
[04:29] <AnMaster> ah *reads*
[04:29] <AnMaster> looks like it need to run a bg process and needs proxy stuff in web server config? that I can't do
[04:30] <AnMaster> I can run python, php and perl by fastcgi
[04:30] <AnMaster> but I can not change web server config
[04:30] <AnMaster> jelmer, so it looks like that doesn't work?
[04:30] <jelmer> It's a standard turbogears app, maybe there's some way to use that inside apache?
[04:31] <lapthrick> its own loggerhead install seems to be down
[04:31] <AnMaster> jelmer, it is lighttpd, not apache
[04:31] <AnMaster> but well I'm not good at python that this seems to be
[04:39] <abadger1999> AnMaster: We've run TG stuff as mod_python in Fedora before.
[04:39] <abadger1999> It wasn't a good experience but fastcgi might be better.
[04:39] <AnMaster> abadger1999, hm ok, anything special needed?
[04:42] <abadger1999> Looking for some documentation on the web right now...
[04:44] <abadger1999> AnMaster: http://tools.cherrypy.org/wiki/FastCGIWSGI
[04:44] <abadger1999> TurboGears uses CP2.2 under the hood so the 2.2 instructions there should be pretty good.
[04:44] <AnMaster> abadger1999, hm, this looks apache centric. again
[04:45] <abadger1999> There's lighttpd setup on that page.
[04:45] <AnMaster> ah *scrolls down*
[06:12] <james_w> mvo: I don't think bzr-git ever worked for branching. I think the best you could do was history exploration.
[06:15] <mvo> james_w: aha, ok. I will just have to look into git then I guess. I was trying to avoid it :)
[06:32] <james_w> jelmer: do you have a local override for export-upstream in your bzr-svn branch?
[06:33] <jelmer> james_w: no, not all
[06:35] <jelmer> james_w: why?
[06:36] <james_w> just wondering. It would be more efficient. You wouldn't have to hit the network to export the tarball.
[06:37] <jelmer> well, bzr-svn merges upstream every now and then so all the revisions are already available locally
[06:38] <jelmer> the exporting step takes just a few seconds when I run `bzr builddeb`
[06:41] <james_w> that's good.
[06:41] <james_w> jelmer: did you see my reply to your bug?
[06:42] <jelmer> no, not yet - when was it sent?
[06:42] <jelmer> never mind, just got it
[07:27] <james_w> jelmer: any thoughts? I was hoping you would say "what about..." and all would become clear.
[07:28] <jelmer> james_w: will reply in a sec
[07:28] <james_w> jelmer: thanks.
[09:16] <lapthrick> bah
[09:16] <lapthrick> bzr shell forgets "ls"
[09:16] <lapthrick> as in, bzr ls, it only has the system ls
[09:33] <lifeless> lapthrick: /usr/bin/ls
[09:33] <lapthrick> lifeless: nono, I do have /usr/bin/ls available
[09:33] <lapthrick> it's bzr ls that's missing
[09:34] <lifeless> oh I see
[09:37] <lapthrick> well, okay, I stand corrected. I don't have /usr/bin/ls, I have /bin/ls :)
[09:39] <alxgsv> Hello
[09:39] <alxgsv> i want to ask if there a way to solve my problem
[09:40] <alxgsv> bzr via proxy
[09:40] <alxgsv> http_proxy="login:password@ip:port" doesnt work
[09:42] <lifeless> abentley: ping
[09:52] <lifeless> mvo: yo
[09:58] <ubotu> New bug: #141026 in bzr-pqm "pqm-submit does not check for uncommitted changes" [Undecided,New]  https://launchpad.net/bugs/141026
[10:10] <Lo-lan-do> Good evening/morning/day/night all
[10:10] <alxgsv> hi )
[10:13] <Lo-lan-do> As I've been engaged in other activities lately, and didn't follow bzr-svn development closely, I was wondering if there had been any changes in there.
[10:13] <Lo-lan-do> Hmm.  There's one log entry that seems promising: "Handle pushing merges of which LHS parent is older revision of branch path."
[10:14] <jelmer> Lo-lan-do: yeah, I think that fixed one of the bugs you hit
[10:14] <Lo-lan-do> I'll give it a try right away.
[10:14] <lapthrick> jelmer: btw, bzr-svn is , finally I don't have to worry about stupid shit like not having write privileges for some kinda package I happen to be working with
[10:15] <lapthrick> make it faster on checkouts and it will be unstoppable
[10:15] <Lo-lan-do> I concur emphatically.
[10:15] <Lo-lan-do> (On both points, alas ;-)
[10:15] <lapthrick> a friend is playing with hgsvn right now
[10:16] <lapthrick> so far, it seems to be very fast
[10:16] <jelmer> thanks, great to hear
[10:16] <lapthrick> but I dunno about usablility
[10:17] <Lo-lan-do> Ah, yes, there was the problem about an svn property that had been corrupted.
[10:18] <lapthrick> jelmer: also, it's quite remarkable that for a 15MB source tree with 2895 revs bzr-svn eats only 47MB, whereas a plain SVN checkout needs 38MB
[10:19] <jelmer> Lo-lan-do: The bug that caused that has been fixed
[10:19] <jelmer> so it won't corrupt your repository again
[10:19] <jelmer> are you still getting the error about the property?
[10:19] <Lo-lan-do> I just got the following:
[10:19] <Lo-lan-do> Using saved location: svn+https://svn.gforge.org/svn/gforge/trunk
[10:19] <Lo-lan-do> bzr: ERROR: exceptions.AssertionError: Revision id lolando@debian.org-20070831143537-22lpbh2js43vt97j was added incorrectly
[10:19] <jelmer> lapthrick: svn always has two copies of each file - the working copy you can edit and an backup copy it uses do to local diffs
[10:20] <Lo-lan-do> I suppose I needed to fix the SVN repo before pushing, so I'm now looking in my emails for the value that shouldn't have been removed from the property.
[10:23] <Lo-lan-do> jelmer: Does the order of the lines in the bzr:revision-id:v3-trunk0 property matter?
[10:25] <lapthrick> jelmer: yeah, but the point is that bzn stuffs 2895 times as much history into barely 40% more space
[10:26] <jelmer> Lo-lan-do: bzr-svn looks at diffs and assumes there is only one line added per commit
[10:27] <lifeless> lapthrick: hgsvn doesn't seem to have the ability for different people to interoperate as easily
[10:27] <jelmer> lapthrick: nice, I missed the bit about the number of revs (-:
[10:28] <lifeless> lapthrick: its more like a better svn client, than about actual full blown interoperation
[10:28] <lifeless> lapthrick: with bzr-svn people can push into svn and back out again losslessly
[10:30] <lapthrick> lifeless: I see, so hgsvn just pulls, but can't push?
[10:30] <lifeless> it uses a single directory that has both .svn and .hg dirs
[10:31] <lapthrick> jelmer: as an aside, it's a bit strange, the current rev in that repo is 3402, but bzr-svn reports pulling 2895
[10:31] <lapthrick> lifeless: ahh, so it's up to you to keep them in sync
[10:31] <lifeless> lapthrick: basically its a set of scripts to help you keep them synced
[10:31] <jelmer> lapthrick: svn's revnoss are repository-based, bzr's revnos are branch-based
[10:31] <Lo-lan-do> I suppose the 507 missing revs are in other branches.
[10:31] <lapthrick> I see
[10:31] <lifeless> whereas bzr-svn migrates the data, flagging it in bzr as coming from svn, and allowing smart merges with svn whether or not you were the original converter
[10:32] <Lo-lan-do> bzr: ERROR: exceptions.AssertionError: Revision id lolando@debian.org-20070831143537-22lpbh2js43vt97j was added incorrectly
[10:32] <Lo-lan-do> :-(
[10:32] <jelmer> Lo-lan-do: what did you change specifically/
[10:33] <jelmer> Lo-lan-do: (to try and get it fixed?)
[10:33] <Lo-lan-do> http://lists.gforge.org/pipermail/gforge-commits/2007-September/000550.html
[10:33] <jelmer> we may need a bzr-svn fix to get it to deal with these broken commits correctly
[10:33] <lapthrick> can bzr-svn convert an existing checkout yet>
[10:33] <lapthrick> ?
[10:34] <jelmer> lapthrick: how do you mean?
[10:34] <jelmer> lapthrick: like 'bzr upgrade' in a svn checkout?
[10:34] <lapthrick> jelmer: I did svn co svn://some/package
[10:35] <lapthrick> can I now cd package; bzr branch . or something?
[10:35] <Lo-lan-do> jelmer: You told me the other day that a push I did replaced the property with a new value, instead of appending the new revid, so I tried to restore the old revid
[10:36] <jelmer> Lo-lan-do: bzr-svn doesn't look just at the contents of the revid property but also at the diffs
[10:37] <jelmer> Lo-lan-do: you could make a local copy of that repository and try to remove that property completely and then try the push again
[10:38] <Lo-lan-do> Hm.  Is it possible to slurp a remote SVN repository and recreate it locally?  I don't have direct access to the repo...
[10:41] <lifeless> lapthrick: you mean to do an inplace conversion from a svn checkout to a bzr checkout ?
[10:41] <lapthrick> yeah
[10:41] <lifeless> I don't know if it can.
[10:41] <lapthrick> jelmer probably does :)
[10:41] <jelmer> it can if it's running a recent version of subversion
[10:42] <lapthrick> is 1.4 recent?
[10:42] <lapthrick> jelmer: and how would I go about doing it? bzr branch . ?
[10:44] <jelmer> lapthrick: sorry that was an answer to Lo-lan-do
[10:44] <lapthrick> ahh
[10:44] <jelmer> lapthrick: you can't upgrade a svn checkout in-place
[10:44] <jelmer> but you can do something like 'bzr branch svn-wc-dir bzr-branch-dir'
[10:45] <lapthrick> jelmer: aha, and it will pull all the history, or will it rather defer until it's actually needed?
[10:45] <jelmer> lapthrick: it will pull all history - there's no way around that until bzr supports shallow branches
[10:46] <lifeless> which jelmer is working on :)
[10:47] <jelmer> Lo-lan-do: the gforge repo doesn't seem to support syncing
[10:47] <lapthrick> mathrick@hatsumi:~/Dev/rails$ bzr branch pokerolymp/ bzr-pokerolymp
[10:47] <lapthrick> bzr: ERROR: Not a branch: /home/mathrick/Dev/rails/pokerolymp/
[10:48] <lapthrick> jelmer: doesn't seem to work, I guess I'll just pull another copy via net
[10:48] <Lo-lan-do> Damn.
[10:48] <Lo-lan-do> I'll try deleting the property then, shall I?
[10:48] <jelmer> Lo-lan-do: yeah - that should work, if you remove the local bzr-svn cache
[10:49] <jelmer> (~/.bazaar/svn-cache/6d150e1c-e21c-0410-8b89-9ee68aed362b)
[10:53] <Lo-lan-do> Right.  propdel committed (through svn), now waiting for the bzr merge to complete (seems to be rather slowed down by the lack of cache :-)
[10:57] <lapthrick> jelmer: apparently bzr-svn hates https :(
[10:58] <lapthrick> which makes it pretty hard for me to use it for my job repo
[10:58] <jelmer> lapthrick: why, what error are you getting?
[10:58] <lapthrick> KeyError: 77
[10:59] <lapthrick> jelmer: want a full backtrace?
[10:59] <jelmer> lapthrick: what version of bzr-svn are you using?
[10:59] <jelmer> lapthrick: if you're using 0.4.x, please file a bug report - that's a serious bug
[11:01] <lapthrick> jelmer: dpkg reports 0.4.1-1
[11:01] <jelmer> lapthrick: is this a public branch you're trying to copy?
[11:02] <lapthrick> no
[11:02] <lapthrick> it's authenticated
[11:03] <lapthrick> jelmer: is that supported?
[11:03] <jelmer> lapthrick: yes, it uses the svn auth cache
[11:04] <jelmer> in other words, if you have authenticated against that repository using svn earlier, it should work
[11:04] <lapthrick> jelmer: then svn has no problem at all with checking out
[11:04] <lapthrick> it didn't ask me for the password
[11:04] <jelmer> lapthrick: could you post the backtrace in a bug report on launchpad ?
[11:09] <sri> lifeless: naw, no chat as of yet :)  Just hanging out for now
[11:11] <lifeless> :)
[11:11] <Lo-lan-do> Progress!
[11:11] <Lo-lan-do> bzr: ERROR: libsvn._core.SubversionException: ("File '/svn/gforge/trunk/gforge/debian/po/de.po' already exists", 175005)
[11:11] <Lo-lan-do> A different error :-)
[11:12] <Lo-lan-do> Should I remove the bzr:file-ids property on that directory too?
[11:23] <jelmer> Lo-lan-do: ah, yes
[11:30] <Lo-lan-do> Lots of network activity happens, and the command seems to take longer than previously.
[11:31] <Lo-lan-do> So even if it eventually fails, it'll have failed at a later stage :-)
[11:37] <Lo-lan-do> It's still computing.
[11:38] <jelmer> if you run it with -Dcommit -Dtransport it will write information to ~/.bzr.log
[11:38] <Lo-lan-do> Ah, damn.  Failed again, still with bzr: ERROR: libsvn._core.SubversionException: ("File '/svn/gforge/trunk/gforge/debian/po/de.po' already exists", 175005)
[11:39] <Lo-lan-do> (After 18 minutes)
[11:39] <jelmer> Lo-lan-do: can you run with -Dcommit -Dtransport and try to push again?
[11:40] <Lo-lan-do> Yep.
[11:41] <Lo-lan-do> http://paste.debian.net/37562
[11:45] <jelmer> Lo-lan-do: thanks
[11:45] <lapthrick> boo
[11:45] <lapthrick> rspush is not working
[11:45] <jelmer> Lo-lan-do: Looks like it's trying to push those changes again that caused the error earlier
[11:45] <lapthrick> bzr bzr-pokersource:2900/> rspush mimi.imada.sdu.dk:/home/makat05/WWWpublicUnhandled error:
[11:45] <lapthrick> Unknown status: 255
[11:45] <lapthrick> are there any glaring errors you can see?
[11:45] <jelmer> Sorry, I never use rspush
[11:46] <jelmer> lapthrick: is rsync installed on the remote host and local machine?
[11:46] <lapthrick> local yes
[11:47] <lapthrick> hmm
[11:47] <lapthrick> I think the problem was with SSH auth
[11:47] <lapthrick> cause plain push to sftp:// displayed that BIG SCARY WARNING about fingerprint having changed
[11:50] <jelmer> Lo-lan-do: What version are you running 0.4.3 or 0.4 from bzr?
[11:50] <Lo-lan-do> 0.4.3 so far
[11:55] <Lo-lan-do> jelmer: Same error, full log in http://paste.debian.net/37564
[11:56] <abentley> lifeless: pong
[11:57] <jelmer> Lo-lan-do: I'll do some more analysis later this week and see if I can get it fixed
[11:57] <jelmer> Lo-lan-do, is the branch you're trying to push available somewhere
[11:57] <jelmer> ?
[11:57] <lifeless> abentley: could I ask you to review my 'dont propogate index changes' patch, not so much from 'is the code ok' as its mainly deletes, but from 'is this the right approach'
[11:57] <Lo-lan-do> jelmer: Would it be likely to help (as a temporary workaround) if removed the problematic files from SVN, then pushed, then re-added them if needed?
[11:57] <lifeless> abentley: also spiv has confirmed your reconcile neither creates the problem, nor fixes.
[11:58] <lifeless> abentley: so hes modifying it to detect and correct.
[11:58] <jelmer> Lo-lan-do, it's not the files that are problematic, it's bzr-svn's view of history
[11:58] <abentley> lifeless: cool.
[11:58] <jelmer> Lo-lan-do, it's trying to push that broken revision again
[11:58] <lifeless> jelmer: how to repair it ?
[11:59] <lifeless> oh, need to analyse, sorry.
[11:59] <abentley> lifeless: one thought I had was that perhaps these discrepancies should trigger something like the reconcile code.
[11:59] <Lo-lan-do> What I'm trying to push is basically a merge of http://alioth.debian.org/~lolando/bzr/gforge/debian/sid into the bzr-svn branch
[11:59] <abentley> So that you don't pull bogus parent updates, but do pull valid parent updtes.
[11:59] <lifeless> abentley: the current propogation was a cheap 'fix on the fly' approach.
[11:59] <lifeless> but on consideration its actually bogus - it scales with history
[11:59] <lapthrick> ShortReadvError: readv() read 591 bytes rather than 4306 bytes at 0 for 2e/1101%40c4f34931-41c7-4605-b615-9bb9f479c57e%253atrunk%253apoker-network%25252%2546pokerweb%25252%2546pages%25252%2546currency.php.knit
[11:59] <lifeless> because it requires cross checking all parents ever
[12:00] <abentley> Okay, that might be the gripping hand.
[12:00] <jelmer> lapthrick, looks like a webserver that's trying to execute all files containing .php
[12:00] <lifeless> abentley: been reading classic scifi recently ?
[12:00] <lapthrick> jelmer: ooh
[12:00] <lapthrick> now that's dumb
[12:01] <lifeless> lapthrick: yeah, we didn't appreciate how many broken web server rules there were. We've fixed that now
[12:01] <lapthrick> do you know what .htaccess spell would kill it?
[12:01] <lifeless> lapthrick: in the next repository disk format.
[12:01] <lapthrick> lifeless: okay, what format is that?
[12:01] <lapthrick> is it in 0.90?
[12:01] <lifeless> lapthrick: no, 0.92 we hope
[12:01] <lapthrick> bueh
[12:01] <abentley> No, Murakami lately.  I just like the "gripping hand" extension.
[12:02] <lapthrick> abentley: Murakami is nice