[09:09] <knittl> hi guys
[09:09] <knittl> i recently did a benchmark "log of subtree"
[09:09] <knittl> bzr really sucks xD
[09:09] <knittl> 8 minutes for 10 k revs
[09:09] <knittl> yes, _minutes_
[09:11] <knittl> * bzr really sucks at this operation xD
[09:12] <knittl> (nobody should take it as offense)
[09:16] <lifeless> knittl: what format
[09:16] <lifeless> what bzr version
[09:19] <knittl> lifeless: current bzr version and i didn't specify a format, so i'd guess 2a (or whatever it's called)
[09:19] <lifeless> seems to definitely need tuning
[09:21] <knittl> yeah. right now it loses by a huge margin
[09:21] <knittl> in average 500x times slower than git/hg
[09:23] <lifeless> its that much slower than bzr log -v too :P
[09:23] <lifeless> please do file a bug
[09:24] <knittl> -v prints modified files? that means it would be still slower
[09:31] <lifeless> log -v of the whole tree is reasonable
[09:31] <lifeless> log -v of a subtree would be slow for the same reason log subtree is slow
[09:31] <knittl> it's reasonable fast but still slower than the others. i don't have a problem with that ;)
[09:32] <knittl> i'm now trying on a smaller repo with shorter history – as soon as log -v has finished
[09:35] <knittl> in a 2k repository it only takes 20s
[09:39] <lifeless> hmm
[09:39] <lifeless> please file a bug
[09:39] <lifeless> I smell a regression
[09:41] <knittl> !bugs
[09:41] <ubot5`> If you find a bug in Ubuntu or any of its derivatives, please file a bug using the command « ubuntu-bug <package> » - See https://help.ubuntu.com/community/ReportingBugs for other ways to report bugs - Bugs in/wishes for the IRC bots (not Ubuntu) can be filed at http://bugs.launchpad.net/ubuntu-bots
[09:42] <knittl> lifeless: i read somewhere that a subtree log in a branch is really slow
[09:42] <knittl> and it's known
[09:42] <knittl> but this is not a branch, this is the only line of history
[09:42] <knittl> (i'm using the django repository as a reference)
[09:46] <knittl> also, it's impossible to log a file in a directory that was removed
[09:46] <lifeless> you can with -r
[09:47] <knittl> what's r?
[09:47] <lifeless> log -r revitexistedin path
[09:47] <knittl> ok
[09:47] <knittl> hmmm…
[09:47] <knittl> but it works with files in root, which got removed
[09:47] <lifeless> if they were removed in the last commit only
[09:48] <knittl> a friend tested this case for me. i don't know if the file was removed only then
[09:48] <knittl> lifeless: https://bugs.launchpad.net/bzr/+bug/503071 maybe this bug?
[09:49] <ubot5`> Launchpad bug 503071 in Bazaar "bzr log DIR could layer above iter_changes (affected: 2, heat: 6)" [Medium,Confirmed]
[09:49] <lifeless> thats the perf of log DIR bug
[09:49] <lifeless> but log -v is too slow
[09:49] <knittl> i was talking about bzr log -- dir
[09:49] <lifeless> I think that that is new
[09:50] <knittl> log -v isn't much slower than normal log (it scales proportionally)
[09:55] <Kamping_Kaiser> hi all, are ther eparticular situations in which you would want to use merge --pull over pull?
[10:00] <Kamping_Kaiser> guess i sshould explain where the question is from
[10:01] <Kamping_Kaiser> the tool 'mr' uses 'bzr merge --pull' to update repos, but if there are uncommited changes the update bails. 'bzr pull' successfullydoes these updtes
[10:01] <Kamping_Kaiser> so unless ther eis a particular reason i'm not aware of to use merge, i might file a bug suggesting to simply use pull
[10:04] <lifeless> well they are different things
[10:04] <lifeless> pull maintains a mirror
[10:04] <lifeless> merge integrates changes from another branch; merge --pull says 'mirror if you can otherwise merge'
[10:07] <Kamping_Kaiser> if i have locally commited changes and i pull, it overwrites them? (I've not noticed that behaviour, thats all)
[10:07] <lifeless> no, pull will error, merge will merge, merge --pull will merge.
[10:08] <Kamping_Kaiser> hm
[10:08] <Kamping_Kaiser> so i'm going to get an error of some sort either way.
[10:08] <Kamping_Kaiser> guess i'll have to make sure i send my patches imediately in future instead of sitting on them :)
[13:50] <jml> I would like to push a Bazaar branch to Twisted's Subversion repository
[13:51] <jml> but I'm afraid it will break something in the Subversion repository that I will be unable to fix.
[13:51] <jml> what should I do?
[13:52] <jelmer> jml: Create a local clone of the svn repository and push to that first?
[13:53] <jml> hmm. I guess I do have read access to the actual repo.
[13:56] <jml> I guess I also don't really know how to check for badness.
[13:56] <jml> all I really have are nebulous fears.
[14:00] <jelmer> I think if it does something wrong it will be fairly obvious from a look at "svn log -v"
[14:07] <jml> ok. I hope this works. I'd really love to abandon svn.
[14:17] <jml> this is a fairly lengthy process :)
[14:55] <jml> jelmer, bzr-svn seems to be doing more work than I'd expect. "Initialising Subversion metadata cache "
[14:55] <jelmer> jml: that should be a one-time thing
[14:57] <jml> oh wait, I think I get it.
[14:58] <jml> I've been using the bzr-svn mirror of Twisted without bzr-svn installed, but now I've installed it so I can try writing to svn repos with bzr.
=== JFo is now known as JeremyFoshee
=== JeremyFoshee is now known as JFo
[15:05] <jml> jelmer, interestingly, pushing up the branch doesn't make a revision that creates the branch as you would normally expect in svn.
[15:05] <jml> jelmer, this breaks some of our trac automation.
[15:05] <jml> man. I'm so late. Gotta go.
[15:06] <jelmer> jml: You mean the new revision does the copy *and* the changes as opposed to creating the branch in a separate revision?
[15:06] <jelmer> jml: ttyl
=== Ursinha-afk is now known as Ursinha
[16:19] <JoshBrown> maxb: You remember we were talking about that qbzr issue to do with filepaths?
[16:20] <JoshBrown> <JoshBrown> maxb: I think this is a qbzr issue since everything works fine using plain bzr
[16:20] <JoshBrown> <maxb> that seems rather odd. Possible, but odd
[16:20] <JoshBrown> <JoshBrown> maxb: Yeah, maybe it's something to do with canonicalization of links or something like that. Anyway I'm off for now, I'll check the differences between the commands I'm running and the ones qbzr is running tomorrow. Bye, and thanks for the help!
[16:22] <JoshBrown> maxb: Turns out Bash expands the `~` character, but qbzr doesn't. Could this be classed as a bug?
[19:17] <vyoma> Hello
[19:18] <vyoma> I'd like to know if there are guidelines for setting up Bazaar repository(folder structure) for projects involving Eclipse plug-ins.
[19:19] <vyoma> Projects involving Eclipse plug-ins usually involve 'n' number of plugin (can be called modules) and each are worked on as separate (but interdependent) projects.
[19:20] <vyoma> Any pointers or links to documents would be helpful.
[20:18] <lifeless> voidspace: hi; just so you know, you've dropped of launchpad-dev :P
[20:19] <lifeless> voidspace: have I shown you pypi.org/pypi/fixtures
[20:20] <lifeless> vyoma: a person called 'verterok' often hangs out here; they wrong bazaar-eclipse, and are sure to know.
[23:14] <lifeless> mgz: ping
[23:14] <lifeless> mgz: I know its late, but :
[23:14] <lifeless> ERROR: junitxml.tests.test_junitxml.TestWellFormedXml.test_error_with_surrogates
[23:14] <lifeless> ----------------------------------------------------------------------
[23:14] <lifeless> Traceback (most recent call last):
[23:14] <lifeless>   File "junitxml/tests/test_junitxml.py", line 313, in test_error_with_surrogates
[23:14] <lifeless>     self.assertTrue(unichr(0x201A2) in traceback)
[23:14] <lifeless> UnboundLocalError: local variable 'unichr' referenced before assignment
[23:14] <lifeless> Ran 18 tests in 0.007s
[23:15] <mgz> ...but I've been to bed for a few hours and got up again
[23:16] <lifeless> darn, I just reverted with my conflict fixes
[23:16] <lifeless> anyhow, where does unichr come from on python2.6 on Ubuntu ?
[23:16] <mgz> should be in builtins
[23:16] <lifeless> so
[23:17] <mgz> there's a better way of spelling that make-it-work-on-Python-3 thing anyway
[23:17] <lifeless> defining it locally makes it a non-free variable
[23:17] <lifeless> so you have to do
[23:17] <lifeless> local_unichr = chr
[23:17] <lifeless> and local_unichr = unichr
[23:17] <lifeless> ....
[23:17] <lifeless> something_with_local_unichr
[23:17] <mgz> rather than making unichr work like I did, just create that string in one way for Python 3 and another for Python 2
[23:17] <lifeless> or that
[23:20] <mgz> want me to push something doing that? It's slightly more annoying because unichr is limited by sys.maxunicode and you can't just use u-prefixed strings
[23:20] <lifeless> if you would like to push anything that makes it work, that would be dandy
[23:24] <mgz> okay, this works, pushing.
[23:26] <mgz> ah, of course, test didn't fail here as I'm giving narrow unicode builds a pass anyway
[23:28] <lifeless> just fixing conflicts
[23:28] <mgz> hm, point about lack of news taken.
[23:29] <lifeless> I hope I wasn't too subtle
[23:35] <mgz> thanks for merging those lifeless.
[23:35] <lifeless> my pleasure
[23:35] <lifeless> sorry I was slack
[23:35] <lifeless> been beating up on LP transparency and performance
[23:37] <mgz> was good to get a little testing on babune first anyway
[23:38] <lifeless> 0.6 is up on pypi and launchpad anyhow
[23:39] <mgz> fantastic.
[23:44] <lifeless> now, wtf did I put the source package branch
[23:46] <lifeless> hmm
[23:47] <lifeless> pyjunitxml could grow a parser too
[23:47] <lifeless> to allow injection from an xml file into python/subunit