[03:48] <james_w> what would be the old way of spelling Graph.iter_lefthand_history()?
[03:54] <lifeless> branch.get_history(0
[05:07] <AfC> I lament Git.
[05:34] <poolie> mm
[06:51] <twb> bzr-fastimport repo used to include darcs-fast-export script.  Now I can't find it.  What happened to it?
[06:52] <twb> Hmm, seems latest version simply delete all exporters, without telling me where to get replacements
[06:54]  * twb randomly googles and finds http://hackage.haskell.org/package/darcs-fastconvert
[09:12] <mgz> morning
[11:45] <johan> Hi, I'm having an issue uncommiting a set of changes in a branch, using bzr 2.5.0
[11:45] <johan> bzr: ERROR: An inconsistent delta was supplied involving 'pixmaps/validation-error-16.png', 'pixmapsvalidationerr-20070828004315-ef6og11rrm2qvq9v-234'
[11:45] <johan> reason: Unable to find block for this record. Was the parent added?
[11:45] <johan> happens when I try to uncommit
[11:47] <mgz> johan: similar to bug 910002 maybe?
[11:48] <johan> mgz: yes, seems to be the same issue
[11:49] <johan> running bzr uncommit again says nothing to commit, but it also complains that the working tree needs to be updated
[11:49] <johan> I'd really like to be able to check out an earlier version of a branch before that bug is fixed
[11:50] <mgz> you can just do that
[11:51] <mgz> `bzr co --lightweight -r -5 ../olderversion` for instance
[11:51] <johan> ah, let me try that
[11:51] <mgz> plus the . to indicate from the cwd
[11:52] <johan> not needed, it worked fine thanks
[14:31] <hypnocat> bzr is often criticised for being slow compared to git.. is bzr slow because it's written in python?  or because of the algorithms it uses?  or some design decisions?
[14:33] <mgz> it's mostly historical
[14:34] <mgz> git was born fast and dumb, bzr evolved differently
[14:35] <quicksilver> git was designed pretty much first and foremost "how do I maintain linux kernel source trees and fast"
[14:35] <mgz> so, many core things these days don't have very different performance characteristics
[14:35] <quicksilver> and since the linux kernel tree is (a) big and (b) had loads of history
[14:35] <quicksilver> actually having a design that made sense was quite secondary to it being very fast.
[14:36] <quicksilver> bzr was designed "how do we do DVCS right?"
[14:36] <johan> no history was imported into the kernel when git was created
[14:36] <quicksilver> really? I stand corrected.
[14:36] <mgz> there are still some obvious differences
[14:36] <johan> they left the old bitkeeper data behind and did a clean break
[14:37] <mgz> cold startup is worse with python
[14:37] <hypnocat> would it help if bzr used one of the python compilers instead of the python interpreter?
[14:38] <mgz> so, your first vcs command after a memory pressure situation will be faster with a small binary rather than lots of pyc files
[14:39] <mgz> hypnocat: no, in short.
[14:40] <mgz> long version, bzr already uses cython (and C) for some parts where more C-like performance is needed
[14:40] <mgz> and the pypy answer to bad performance is "let it run for several seconds so the JIT warms up"
[14:41] <mgz> which obviously doesn't help much with a multiply invoked commandline tool like bzr
[14:41] <hypnocat> so, what are the main things that bzr does right compared to git that slow it down so much?
[14:41] <mgz> I think you missed my first line :)
[14:41] <hypnocat> that it's historical?
[14:42] <hypnocat> i got that.. they evolved differently
[14:42] <hypnocat> and the core stuff has similar performance
[14:42] <mgz> these days, there aren't big differences in performance on basic opterations
[14:42] <hypnocat> so where are the big performance differences?
[14:43] <mgz> I think their network protocol is more reliably performant
[14:44] <mgz> because there's only one way of doing it, whereas bzr doesn't discourage you from using lots of different protocols, some of which then do silly things
[14:48] <mgz> feel free to benchmark things though, or look in the list archives for older benchmarks, a few have been done
[14:48] <hypnocat> alright, thank you
[18:38] <bsd> Hi jelmer.  Is there any support in bzr-svn (or a bug) to allow stacking against a Subversion repo?  I'm having to work against a very large and old repo, and it will take days (weeks!) to download it all…
[18:38] <jelmer> hi bsd
[18:39] <jelmer> bsd: unfortunately stacking across different repository formats is not supported at the moment, and the svn format does not support stacking itself
[18:42] <bsd> jelmer: so there's little that can be done other than maintaining a parallel branch.  Oh well.
[18:44] <jelmer> bsd: how big is the branch?
[18:44] <bsd> jelmer: 142k entries.  But they've pushed in zip files and all sorts of monstrous binaries.
[18:44] <jelmer> ah
[20:34] <Omni|Work> How do I find out which branch a tag is on?
[20:34] <Omni|Work> I do 'bzr tags' and there are a whole ton of tags with a '?' on them.
[20:35] <wilx> The information is part of the log output.
[20:45]  * Omni|Work nods.
[23:13] <poolie> hi all