[00:00] <lampliter> hey, hoping bzr+eclipse folks around?
[00:03] <lampliter> hmm same echo as earlier :-)  fwiw, the docs for bsz-eclipse are seriously out of date.  Eclipse apparently changed the user interface in the plug-ins section
[00:04] <lampliter> either that or I'm wandering around the wrong part of eclipse.  That's been known to happen before.
[00:10] <sorakiu> i am developing a website on a contract -- i'm a little fuzzy on gplv2 -- can i put the source in a bazaar repository without opening the source code?  i'm using bzr as-is
[00:11] <bob2> sure
[00:11] <bob2> [IANAL] copyright affects derivative works, your website doesn't derivce from bzr
[00:11] <sorakiu> its only if i make changes to bzr the program or link against it that gplv2 applies, right?
[00:11] <sorakiu> ahh - thx
[00:11] <sorakiu> i like it so far -- its cool
[00:12] <lifeless> bob2: you gotta stop with the I ANAL stuff :P
[00:14] <lampliter> this a family channel even if we are a tad bzr
[00:15] <lifeless> I know :)
[00:15] <lifeless> IANAL stands for I Am Not A Laywer
[00:15] <lampliter> I just thankful he didn't hut a <heart> after the I
[00:15] <lampliter> :-)
[00:16] <bob2> and INAA stands for I Need An Adult
[00:16] <lifeless> buts its confusion for folk that don't know the abbreviation, and folk that do don't need the warning (IMO) - only laywers need to declare that they aren't giving legal advice.
[00:16] <lifeless> bob2: lol
[00:17] <lampliter> I was old when folks started using those abbrevs

[00:17] <lifeless> :)
[00:17] <lampliter> so GOMLYPK
[00:18] <lampliter> get off my lawn you punk kids
[00:48] <verterok> lampliter: hi
[00:49] <verterok> lampliter: what's the issue with bzr-eclipse?
[00:52] <Noldorin> hello.
[00:52] <Noldorin> does the bzr smart server still not have its own authentication?
[00:53] <lifeless> that is correct
[00:53] <lifeless> we recommend that you layer it either over ssh or http if authentication is required,
[00:55] <Noldorin> lifeless: yeah, that's what i've done at the moment. just makes it a bit of a pain when i want read-only http access
[00:55] <Noldorin> to the public
[00:59] <lifeless> Noldorin: Indeed; we should make that better. I'll file a bug.
[01:00] <Noldorin> cheers :)
[01:00] <Noldorin> lifeless: how's the 2.0 release coming along btw? i take it this won't get included...
[01:02] <poolie> spiv, i'll call you in a minute
[01:02] <spiv> poolie: ok
[01:09] <igc> poolie: I'll like a call this morning as well please
[01:10] <poolie> cool, i'll call you after
[01:13] <igc> poolie: my 'chat' list is long btw - content filtering, migrations, performance, upgrades, website, docs, packaging, GUIs, etc.
[01:13] <lifeless> Noldorin: no chance
[01:13] <lifeless> Noldorin: it needs code
[01:14] <Noldorin> fair enough
[01:14] <Noldorin> plans for the release going well anyway?
[01:14] <igc> lifeless: I'd like to submit that doc contents tweak you approved to 2.0
[01:14] <igc> lifeless: what's the pqm address?
[01:15] <lifeless> submit_branch = http://bazaar.launchpad.net/~bzr-pqm/bzr/2.0
[01:15] <lifeless> pqm_email = pqm@bazaar-vcs.org
[01:15] <igc> lifeless: thanks
[01:18] <lampliter> verterok: sorry, debugging vpm probs with mac
[01:18] <verterok> lampliter: np
[01:19] <lampliter> thank you for paying attention to my request for help
[01:19] <lampliter> okay, the problem is the documentation screen shots are out of sync with the current version of eclipse
[01:19] <lampliter> I think it's installed properly.  I think I've set up things properly but, I can't figure out how to grab my files from launch pad from eclipse
[01:20] <verterok> lampliter: Project new --> Bazaar --> Branch as a new Prokect
[01:21] <verterok> lampliter: sorry, that should be: File --> New --> Project --> Bazaar --> Branch as a new Prokect
[01:21] <lampliter> I'm using pydev  does that matter?
[01:21] <verterok> lampliter: or checkout as a new project
[01:21] <verterok> lampliter: no, it shouldn't
[01:22] <verterok> lampliter: is your .project and .pydevproject? versioned?
[01:22] <lampliter> they were originally managed by Emacs and command line bzr but my hands broke worse and I'm trying to put speech recognition macros on top of the eclipse user interface
[01:23] <lampliter> so, it's making a lot of changes all once
[01:23] <lampliter> I'm going to be asking the eclipse people a lot of embarrassing accessibility questions in the relative near future.  :-)
[01:27] <spm> lampliter: given I just had an eclipse bug moved into 'triaged' - 3 years after reporting and providing all desired info - don't hold your breath :-)
[01:28] <lampliter> hehe well, anyone who uses Python well knows that job is a lot slower.  ;-)
[01:28] <lampliter> speech recognition error, job/Java
[01:29] <spm> Oh I dunno... job/java sounds perfectly sane to me ;-)
[01:30] <lampliter> okay, I have a checkout of my project sitting in my project directory.  Do I want to put my eclipse project in the same place?
[01:32] <spm> if I understand your meaning correctly; yes. I personally do this and bzr ignore the eclipse files; but I also use cmdline bzr so ymmv
[01:32] <spm> s/use/vastly prefer/
[01:35] <lampliter> Understood.  When my hands aren't too bad shape and am working in Linux, I prefer the command line as well.  But when I'm using speech recognition, I am stuck on Windows
[01:35] <lampliter> so I need to build a hand friendly speech driven environment
[01:36] <lampliter> so back to my question.  I found I had a copy of my project checked out.  Do I want to just impose the eclipse project environment on top of that or do I want to put the eclipse project in a different location?
[01:37] <lifeless> 4 bugs to go
[01:44] <lampliter> it can't cope with spaces in the path names
[01:44] <lampliter> bzr import Wizard can cope with spaces in the path names such as "my documents".  It fails by stripping off the my and then not letting you move forward without saying anything
[01:45] <lampliter> I've just spent the past 15 minutes trying to figure out why it couldn't figure out where my project directory was
[01:45] <lampliter> it's not your fault.  Microsoft was an idiot for allowing spaces in filenames in the first place
[01:47] <bob2> what is "bzr import Wizard"?
[01:47] <lampliter> is part of the plug-in for eclipse.  Bazaar Import Wizard
[01:49] <bob2> oh
[01:49] <lampliter> oh, I also see part of the cognitive problem.  It says the final location to branch from and then has the browse button when it really should be a repository URL.  I'm sorry, my brain is not working right.  It's been a long day
[01:50] <lampliter> on the plus side, I got my blood sugar down to 72.  And the fact that I'm channel surfing quite as bad as a sign I should go get something to eat and bring my blood sugar back up a bit
[01:50] <lampliter> joys of being diabetic and still not fully in control
[02:01] <poolie> https://bugs.edge.launchpad.net/~ian-clatworthy/+assignedbugs
[02:07] <lifeless> spiv: is that needing review?
[02:09] <poolie> Bugs in Bazaar Version Control System <https://bugs.edge.launchpad.net/bzr/+bugs?search=Search&amp;field.importance=Critical&amp;field.status=New&amp;field.status=Incomplete&amp;field.status=Confirmed&amp;field.status=Triaged&amp;field.status=In+Progress&amp;field.status=Fix+Committed> -- igc
[02:15] <lifeless> I need a teddy bear I think.
[02:15] <lifeless> spiv: Up for a call? bug 402652
[02:19] <lampliter> okay, got a few  more  neurons.  When through and finish the create a project and it failed during the checkout
[02:20] <lampliter> she says "error while executing checkout object of type 'NoneType' has no len()
[02:21] <lampliter> I'm guessing something in the authentication/identity area is not set up right
[03:14] <lifeless> grabbing food
[03:14] <lifeless> poolie: if you're done with your other calls; you could ring my mobile ;)
[03:15]  * igc lunch
[03:33] <lifeless> laksa is just the best thing in the world when one is sniffly
[03:40] <yek401> so I know you said bzr join --reference isn't supported.. but is it even functional in any of the dev releases?
[04:28] <TravisD> I am new to bzr (as a warning, mostly). I have a branch on my laptop which i wish to push to a repository on a server I have access to
[04:28] <lifeless> cool
[04:29] <lifeless> is it misbehaving, you are just looking for 'getting started' help ?
[04:29] <TravisD> I issue the command bzr push sftp://..., and I get an error, bzr: ERROR (ignored): GraphIndex(', followed by a long URL, followed by bzr: ERROR: Generic path error: ... unable to rename to ...
[04:29] <TravisD> (Sorry about breaking that into two messages)
[04:30] <lifeless> TravisD: that could be a permission issue
[04:30] <lifeless> what are the last 3 or so path elements in the error?
[04:30] <lifeless> the bits under 'repository/'
[04:30] <TravisD> bzr: ERROR (ignored): GraphIndex('sftp://tdick@gpu.srv.ualberta.ca/~/bzr_projects/SameGameSolver/trunk/.bzr/repository/indices/904bda77bfd1ba65ea5e551d8529329d.rix')
[04:30] <TravisD> bzr: ERROR: Generic path error: '482iwleesvd30gra23ql.pack': Failure: unable to rename to '../packs/904bda77bfd1ba65ea5e551d8529329d.pack')
[04:30] <TravisD> ]
[04:31] <TravisD> ahh, sorry about the multiline paste -- was not expecting that
[04:31] <lifeless> ok
[04:31] <lifeless> that looks like you are missing write or execute permission on the packs directory
[04:32] <TravisD> hmm
[04:33] <TravisD> as a point of interest, in "SameGameSolver", ls -a shows no .bzr directory
[04:33] <TravisD> should there be one?
[04:33] <lampliter> from bzr-eclipse -- Executing: checkout lp:akasha C:\Users\esj\workspace\akasha; Error while executing checkout object of type 'NoneType' has no len()
[04:34] <lifeless> TravisD: yes, otherwise the writes to create the indices and uploads/pack would have failed
[04:34] <lifeless> TravisD: oh sorry
[04:35] <lifeless> TravisD: no, there's no need for a repositoriy, use of a separate repository is optional
[04:35] <lifeless> the .bzr under trunk is an in-place repository for just that branch and should work totally fine
[04:35] <TravisD> ah, I see
[04:35] <TravisD> Earlier I issued: bzr init-repo .../SameGameSolver
[04:35] <TravisD> would that not make the .bzr directory?
[04:36] <lifeless> yes it would have ;P
[04:36] <TravisD> I will try it again :)
[04:42] <TravisD> lifeless, this is from a fresh attempt: http://www.pastebin.org/13543
[04:42] <TravisD> this time the .bzr is present as expected
[04:57] <lifeless> TravisD: sorry I'm on a phone call
[04:58] <TravisD> thats no problem
[06:03] <TravisD> lifeless, any ideas?
[06:04] <lifeless> looking now
[06:04] <TravisD> thanks :) Sorry to be a pester
[06:04] <lifeless> no bother
[06:05] <lifeless> was a longish call
[06:05] <TravisD> haha no problem
[06:06] <lifeless> TravisD: that does look like some sort of perm error
[06:06] <lifeless> what ftp server is it, do you know?
[06:06] <lifeless> also, you don't need the separate 'init' step, just pushing will create a new branch for you
[06:06] <lifeless> could you please file a bug for us to gather data and debug this?
[06:07] <TravisD> I don't know the server, unfortunately
[06:07] <TravisD> is there a way I can check in an ssh session?
[06:08] <johnjosephbachir> i have foo1/file.txt and foo2/file.txt. i want to apply changes made to foo1/file.txt in r5 to foo2 -- is there a slick way to do this, or do i just generate a diff, and apply it on the commandline with patch
[06:08] <lifeless> TravisD: ssh -vv host
[06:09] <TravisD> OpenSSH_4.6, OpenSSL 0.9.7j 04 May 2006
[06:09] <lifeless> johnjosephbachir: are foo1 and foo2 branches?
[06:09] <johnjosephbachir> no-- two directories in the same branch
[06:09] <lifeless> TravisD: ok, no huge surprises there
[06:09] <lifeless> johnjosephbachir: then just make a diff and apply it
[06:09] <johnjosephbachir> lifeless: that seems so 2005, but okay. :)
[06:10] <TravisD> lifeless, could a malformed branch on my system cause this kind of error?
[06:11] <TravisD> Also, I think I'm using bzr 1.18, if that makes a difference
[06:11] <TravisD> (Just installed Karmic Koala and got it out of the debian repositories)
[06:11] <lifeless> TravisD: no, I don't think so
[06:12] <TravisD> lifeless, drwxr-xr-x  2 tdick  uofa   2.0K Aug 30 21:37 packs <-- this is the permissions on the packs directory in .bzr/repository/
[06:13] <lifeless> TravisD: on the server?
[06:13] <TravisD> yep
[06:14] <lifeless> I dunno.
[06:14] <lifeless> I need to pop out for a bit; someone else may be able to help, but I really recommend you file a bug
[06:14] <TravisD> sure, how do I do that? haha
[06:14] <lifeless> https://launchpad.net/bzr/
[06:14] <TravisD> alright :) thanks
[06:14] <lifeless> click on file a bug
[06:18] <poolie> igc, i might file that bug about getting it into add/remove?
[06:18] <igc> poolie: sure
[06:20] <igc> poolie: https://lists.ubuntu.com/archives/bazaar/2009q3/061200.html
[06:22] <poolie> thanks
[06:29] <TravisD> bug submitted, fairly comprehensive, I think
[06:32] <poolie> https://lists.ubuntu.com/archives/bazaar/2009q3/061200.html igc
[06:46] <igc> poolie: did you mean to post a different link to the one I gave you?
[06:46] <poolie> i did :)
[06:46] <poolie> i actually meant bug 421778
[07:24] <jml> quick question
[07:24] <lifeless> boom-tish
[07:24] <jml> I want to move files from one branch to a related branch
[07:24] <jml> a non-related branch
[07:25] <lifeless> do you need to take history?
[07:25] <jml> lifeless, I'd like to, but only if it's easy to do so
[07:25] <lifeless> [note that taking history takes /all/ file histories]
[07:25] <lifeless> jml: does that influence your answer
[07:25] <jml> lifeless, it does.
[07:25] <jml> lifeless, I'll just copy the contents and forget history
[07:25] <lifeless> do you need to take history?
[07:26] <jml> history is bunk
[07:26] <lifeless> tada
[07:49] <vila> hi all
[07:50] <lifeless> hai
[07:54] <poolie> lifeless: have you hit bug 421804 ever?
[07:54] <poolie> hello vila
[07:56] <vila> hmm, my karmic slave won't complete booting... any magic key during boot to get a root shell ?
[08:03] <lifeless> poolie: it wouldn't surprise
[08:03] <lifeless> me to find that I have
[08:03] <lifeless> poolie: on the 2a group combining, I want John's input..
[08:03] <lifeless> poolie: I've asked for it in the bug, and I'm EODing... 'now'
[08:03] <poolie> igc, just as feedback "improve documentation bundling" is a poor summary
[08:04] <poolie> compared to say "split documentation bundles by language"
[08:04] <lifeless> poolie: I think I have hit it, yes.
[08:05] <lifeless> the language of the 'This bug affects me too  Edit' message annoys me.
[08:05] <poolie> it's a bit better now
[08:05] <lifeless> It doesn't affect my web browser/laptop/launchpad.
[08:05] <lifeless> its a bit of a philosophical annoyance
[08:10] <poolie> hi vila
[08:11] <poolie> how's stuff?
[08:11] <vila> good, my karmic slave booted finally (I had to threaten it of reinstall, that worked)
[08:11] <poolie> heh :)
[08:12] <loxs_wrk> hi, will bzr 2 work with bzr 1 branches?
[08:12] <lifeless> yes
[08:12] <lifeless> it will create bzr 2 branches by default
[08:12] <lifeless> but you can read from bzr 1 branches into a bzr 2 branch
[08:12] <loxs_wrk> and 1 won't be able to work with bzr 2 branches?
[08:13] <lifeless> 1.16 and above can
[08:13] <loxs_wrk> I see, thanks
[08:13] <lifeless> we will be strongly encouraging people to upgrade
[08:14] <loxs_wrk> well, people will upgrade when distros upgrade :)
[08:14] <loxs_wrk> like my distro (gentoo) is already updated
[08:14] <vila> lifeless: 'selftest is using atext for some strange reason'.... :-D You really don't know ?
[08:15] <lifeless> vila: no, I don't
[08:15] <vila> well, because there is no such thing as setUp/tearDown for TestSuite...
[08:15] <lifeless> stopTestRun
[08:15] <poolie> yay gentoo
[08:15] <lifeless> for instance
[08:16] <lifeless> vila: but separately, why not do it per test
[08:16] <vila> lifeless: correction: there *was* no such...
[08:16] <vila> lifeless: I think the rationale was to catch any possible problem in any test (or outside or at the border or... catch'm all...)
[08:17] <vila> that's the most I can recall from the discussion, I think it was with spiv
[08:17] <lifeless> vila: right, I'm not saying 'no catcher', just 'per-test' - that makes it cleaner, at the cost of 5 mkdirs
[08:18] <spiv> I don't recall the specific discussion.
[08:18] <vila> that helped keep the /tmp dir cleaner too (since we often regressed there and also because ctrl-c'ing tends to avoid the atexit)
[08:19] <spiv> I can imagine using atexit as a hackish solution to that sort of problem.
[08:20] <lifeless> vila: Don't feel that I'm attacking you please; I think its a bug that we use atexit, as demonstrated by my bug report.
[08:20] <vila> spiv: I'm pretty sure you're the one annotate will point its finger at for using it in the first place ;-)
[08:20] <vila> OOOh, no problem there !
[08:20] <lifeless> vila: if you agree that we can do better, great. If you think we should stay with atext, lets discuss why ;)
[08:20] <vila> I agree we should do better, I was just trying to bring the context back
[08:20] <spiv> vila: quite possibly :)
[08:21] <vila> I wasn't throwig stones either !
[08:21] <spiv> vila: it's ok that my memory is poor because we have a vcs to remember stuff for me ;)
[08:21] <vila> spiv: exactly :)
[08:22] <spiv> But glancing at the comments on that atexit.register, it does seem to be used because we don't have a good way to know when the TestCaseWithMemoryTransport.TEST_ROOT resource is no longer needed, so atexit is a cheap approximation of what we want.
[08:23] <spiv> If it were free to create and destroy that directory with every test that wants it then that would solve the problem.
[08:24] <spiv> As would removing the need for that particular safety net :)
[08:25] <spiv> (Or if measurement shows that the cost of doing that per test is negligible, let's just do that right now)
[08:29] <vila> data point: I just deleted ~200 testbzr directories from my /tmp dir
[08:32] <lifeless> vila: so clearly its not working :P
[08:33] <vila> I ctrl-c a lot :)
[08:33] <vila> but that sounds too much
[08:34] <spiv> Ctrl-C shouldn't prevent atexit from triggering, AIUI.
[08:34] <spiv> But yes, clearly it is failing to clean up reliably.
[08:35] <vila> poolie: regarding bug #390502, my jaunty slave is using 2a for ~1 week, I intend to migrate the others today
[08:36] <vila> That's not the same as upgrading the lp branches, but stilll a significant test IMHO
[08:37] <poolie> that's good
[08:37] <poolie> i'd like to do it soon
[08:56]  * igc diiner
[08:56] <igc> dinner
[09:06] <poolie> vila, i'm going to poke at getting an EC2 for packaging going
[09:06] <vila> to replace kerguelen you mean ?
[09:07] <poolie> yes
[09:29] <poolie> vila, can you point me to any good instructions on how to set up a win32 build environment?
[09:30] <lifeless> I think sidnei did some
[09:30] <vila> jam's brain ?
[09:30] <lifeless> hmmm
[09:30] <vila> what precisely do you want ? compiler/dev tools setup or just buildbot setup ?
[09:30] <lifeless> http://www.mail-archive.com/bzr-windows@lists.launchpad.net/msg00058.html
[09:31] <poolie> the first
[09:31] <vila> the most recent one I know about is the one robert pointed to ^
[09:32] <vila> http://bazaar-vcs.org/BzrWin32Installer is the corresponding wiki page
[09:32] <poolie> oh it's pretty awful
[09:32] <vila> poolie: yes
[09:34] <vila> the dream setup should be: 1) install bzr.exe, 2) bzr branch lp:bzr-pimp-my-windev, 3) bzr pimp-my-windev 4)....
[09:34] <poolie> mm
[09:35] <lifeless> vila: you could use a config; that can unpack tars and stff too :P
[09:35] <lifeless> but I think sidnei made it all work via buildout
[09:36] <vila> lifeless: we're talking about *installing* the tools, not running the installer build
[09:36] <lifeless> vila: I know
[09:36] <vila> and yes, 'pimp-my-win' is a plugin that can untar unzip run installers :-D
[09:37] <vila> and sidnei made an install via buildbot ?
[09:37] <vila> never heard about it...
[09:38] <lifeless> he made nightly windows builds
[09:38] <lifeless> didn't he?
[09:38] <vila> yes, they have been integrated in the test farm, they currently run on kerguelen
[09:39] <vila> they rely on kerguelen having all the needed tools already installed
[09:45] <vila> test farm all green by the way (after the necessary fixes for the  week-end related hiccups)
[09:45] <lifeless> even win32?
[09:47] <vila> win32 selftest has been disabled because it (currently) 1) crash with CantCreateThread without reporting the number of failures, 2) run under cygwin (not the primary target)
[09:47] <lifeless> oh right
[09:47] <vila> I want a local setup to debug both
[09:49] <poolie> CantCreateThread because there are too many leaks?
[09:49] <poolie> :/l
[09:50] <vila> poolie: That's my best guess yes
[09:53] <isma_tin> buenos dias a todas/os
[09:59] <spiv> Hmm, the global _page_cache in chk_map interferes with noticing missing data.
[10:00] <spiv> It would be less dangerous to cache per-repo rather than globally.  Oh well, I can hack around that...
[10:25] <lifeless> jelmer: do you use doap?
[10:50] <thumper> thank you to whoever fixed commit --strict not to complain when I say to commit only one file of several changed \o/
[10:51] <lifeless> thumper: hmm, 2a? bzr nightly ?
[10:51] <lifeless> -might be a bug
[10:51] <thumper> no
[10:51] <thumper> I mean it
[10:52] <thumper> if I say a file name
[10:52] <thumper> don't bitch about the other changed files
[10:52] <lifeless> I'm not offering a value judgemnet :)
[10:52] <lifeless> just saying that the change in behaviour may have been an untested case, and that both the old and new behaviour are not necessarily strictly intentional
[10:53] <lifeless> I'm glad you like what its doing now.
[11:01] <lifeless> hmmm, I'm writing blog posts that are too long now.
[11:05] <crisb> anyone around who can help me with an AIX test problem? just need a few pointers.  its #405745
[11:06] <spiv> crisb: it hangs?
[11:07] <spiv> crisb: maybe hit SIGQUIT (probably Ctrl-\) and type "bt" and add that to the bug.
[11:09] <spiv> crisb: it might be interesting also to run just the HTTP tests without the blackbox tests.
[11:09] <bialix> spiv: ping
[11:09] <spiv> crisb: e.g. "bzr selftest -s bt.test_http"
[11:09] <spiv> bialix: pong
[11:10] <spiv> (Although I need to tear myself away from my laptop soon)
[11:10] <bialix> spiv: is it known problem with 1.18?
[11:10] <bialix> bzr: ERROR: bzrlib.errors.ErrorFromSmartServer: Error received from smart server: ('error', "Absent factory for ('odict.html-200
[11:10] <bialix> 90118140732-dye8mko5bfy12t15-2', 'bialix@ukr.net-20090118142612-vk1ob9k8l58oivi8')")
[11:10] <bialix> got while run command: bzr get lp:bzr-scmproj/0.4.5
[11:11] <spiv> crisb: (I've added these comments to the bug)
[11:12] <crisb> spiv:cheers, just giving it a go now
[11:12] <spiv> bialix: probably bug 354036, looking now.
[11:14] <bialix> spie: filed my case as https://bugs.launchpad.net/bzr/+bug/421860
[11:14] <bialix> spiv: ^
[11:15] <spiv> bialix: yes, it's bug 354036
[11:16] <spiv> bialix: the fix script attached to 354036 identifies several missing inventories
[11:16] <bialix> so it's not fixed?
[11:16] <spiv> bialix: it is in bzr
[11:16] <bialix> oh, it's THAT bug again?
[11:16] <spiv> bialix: but affected branches in launchpad are hard to fix due to the way Launchpad keeps separate copies for where you push to and where other users read from.
[11:17] <spiv> So the fix script fixes it for users that can write to the branch, but not those that can only read from it.
[11:17] <bialix> so what I should do?
[11:17] <lifeless> bialix: run the fix script
[11:18] <spiv> a) Run the fix script and get a Launchpad admin to delete the mirrored branch and trigger a fresh mirror from the hosted area, or b) delete/rename the branch on Launchpad entirely and repush :(
[11:18] <lifeless> for a) you could also run the fix script and push something there
[11:18] <lifeless> or uncommit, then push the original again after it mirrors the uncommit?
[11:19] <lifeless> spiv: 6
[11:19] <bialix> on my current PC I have no copy of that branch
[11:19] <spiv> lifeless: that won't cause the missing inventories to get copied across to the mirrored area AFAIK.
[11:19] <lifeless> spiv: doesn't matter does it? I thought bzr+ssh read from the main copy...
[11:19] <spiv> lifeless: if you have write access.
[11:19] <wgrant> lifeless: Only if you have write access.
[11:19] <lifeless> oh bah
[11:19] <lifeless> need a 'fixme' button
[11:19] <spiv> lifeless: write access == use hosted area, everyone else == mirrored area.
[11:19] <lifeless> bialix: bzr pull nosmart+ , and it will work
[11:19]  * spiv makes some noise on the bug.
[11:20] <lifeless> spiv: in the summary please
[11:20] <wgrant> Will a tip change not cause the puller to resolve it? Maybe I've previously fixed it with a format change...
[11:20] <wgrant> (that causes a full remirror)
[11:21] <lifeless> wgrant: yes, format change does full mirror
[11:21] <lifeless> tip changes do regular pulls
[11:21] <bialix> spiv, lifeless: pull from http source does work
[11:22] <wgrant> lifeless: And a regular pull won't fix it?
[11:22] <lifeless> no, it won't
[11:23] <crisb> spiv: have attached the backtraces (both hang)
[11:25] <bialix> spiv: your script hang on Windows
[11:25] <bialix> spiv: I told you so many months ago
[11:25] <spiv> lifeless: done
[11:26] <spiv> bialix: it's lifeless' script :P
[11:26] <bialix> then lifeless
[11:27] <spiv> bialix: I'm not sure why it would, I don't see any obvious portability pitfalls in it.
[11:27] <lifeless> bialix: does it run into a locking issue?
[11:27] <bialix> it prints me: missing inventories(...) and then hang
[11:27] <bialix> lifeless: how can I know this?
[11:27] <lifeless> bialix: at that point it should be uploading the inventories
[11:27] <lifeless> bialix: is there any network traffic
[11:28] <spiv> Are you running it against Launchpad or a local branch?
[11:28] <bialix> no
[11:28] <lifeless> bialix: use Process Explorer
[11:28] <bialix> no network traffic
[11:28] <bialix> it just hang
[11:28] <bialix> and it seems it does the job
[11:28] <bialix> and then hang
[11:28] <lifeless> very odd
[11:28] <lifeless> uhm
[11:28] <spiv> If you're running it against a remote branch then I have no idea unless there's something about open SSH connections causing the process to never die.
[11:28] <bialix> because on second run I've got: Missing inventories: set([])
[11:29] <bialix> spiv: I should run it against local? why for?
[11:29] <bialix> the problem IS with lp: branch
[11:29] <spiv> bialix: well, I can imagine some scenarios :)
[11:29] <spiv> bialix: but just checking assumptions
[11:30] <bialix> yeah, ol win people ar dump?
[11:30] <spiv> Not at all.
[11:30] <spiv> If it's local, then the typical locking bugs would have been my first suspect.
[11:30] <bialix> spiv: I don't understand the problem and your script, so I'm just using instructions from summary
[11:31] <bialix> it said about bzr+ssh
[11:31] <bialix> so why I should use it local? my problem with lp only
[11:31] <spiv> But because it's network, that seems unlikely, so it I guess it's something about the way it uses the network, e.g. maybe somehow there's a non-daemonic thread created by paramiko.
[11:31] <spiv> The bug can apply to local branches too.
[11:31] <Raim> hi
[11:32] <spiv> It's more unusual to have stacked branches locally, but it does happen.
[11:32] <bialix> spiv: because problem solved I have no desire nor time to dig so deep.
[11:32] <bialix> spiv, lifeless: thanks
[11:32] <bialix> but it hang
[11:32] <spiv> bialix: sure.  I'm happy to help debug a bug report, but "it hangs" with no further info rarely leads to a fix :)
[11:32] <Raim> what should I do if I want to move a subtree into its own repository? fast-export/import?
[11:33] <bialix> spiv: I hope it's lat time I've got this error
[11:33] <bialix> last
[11:33] <bialix> Bug #421860 marked as duplicate
[11:34] <spiv> bialix: I hope so too
[11:34] <bialix> Raim: only if you want to filter out history
[11:35] <bialix> spiv: but frankly: what kind of details you'd like to have?
[11:35] <spiv> vila: 405745 sounds like your territory
[11:36] <spiv> bialix: to debug the hang?  Where it's hung; and what threads are running.
[11:36] <bialix> spiv: it's a standalone script, I have no idea how to set BZR_PDB=1 and stop it without KeyboardInterrupt
[11:36] <spiv> Yeah, that's a pain.
[11:36] <bialix> wait a sec
[11:36] <Raim> bialix: no, I want to keep the full history of this subtree. what should I use then? already tried to find something in the wiki...
[11:36] <spiv> Normally I'd ask for a traceback from SIGBREAK, but some hacking would be necessary.
[11:36] <bialix> Raim: bzr split then
[11:36] <spiv> But I guess KeyboardInterrupt would give one.
[11:37] <bialix> spiv: on Windows there is no SIGBREAK
[11:37] <spiv> bialix: oh yes there is :)
[11:37] <lifeless> SIGBREAK will kill it though
[11:37] <lifeless> what you want is
[11:37] <lifeless> python -m pdb script.py
[11:37] <Raim> bialix: thanks, that seems to be what I am looking for!
[11:37] <lifeless> erm
[11:38] <lifeless> python -m pdb script.py URL
[11:38] <bialix> spiv, lifeless: there is indeed 2 threads
[11:38] <spiv> lifeless: (right, but inside bzr SIGBREAK on win32 does what SIGQUIT does on posix)
[11:39] <lifeless> spiv: yup; however we're not inside bzr;)
[11:39] <bialix> lifeless: -m pdb run it in the pdb
[11:39] <bialix> what's next?
[11:39] <vila> spiv: ooh, didn't notice the updates on the page, looking at it
[11:39] <lifeless> run it
[11:39] <bialix> c?
[11:39] <lifeless> and hit ctrl-C once it hangs
[11:39] <spiv> bialix: ok, and I guess thread2.isDaemon() == False ?
[11:39] <lifeless> that should leave you in pdb
[11:40] <spiv> bialix: (for future reference, jam and I recently added SIGBREAK support to main bzr, so you can hit Ctrl-Break (IIRC) on windows to get dropped into a pdb prompt)
[11:40] <spiv> bialix: (unfortuately not helpful for this script)
[11:40] <bialix> f*** pdb does not understad backslashes
[11:41] <lifeless> gnight
[11:41] <bialix> lifeless, spiv: http://pastebin.com/m2ff23706
[11:41] <bialix> pdb is not much help
[11:42] <spiv> Interesting.
[11:42] <bialix> spiv: this does not work on WIndows
[11:42] <bialix> Ctrl+Break simply stops the script
[11:42] <vila> spiv: humpf, hang on *server* close !
[11:42] <spiv> bialix: it stops the script, but not bzr
[11:42] <bialix> ot does not matter
[11:42] <bialix> it
[11:43] <spiv> bialix: try "bzr log lp:bzr", and hit Ctrl-Break
[11:43] <bialix> it just kill bzr or script
[11:43] <spiv> bialix: it's a handy trick to have
[11:43] <bialix> maybe it's  FAR use Ctrl+Break
[11:43] <spiv> jam definitely tested it :)
[11:44] <spiv> FAR?
[11:44]  * bialix trying
[11:44] <bialix> interesting
[11:44] <bialix> it works now
[11:44] <bialix> with log
[11:44] <spiv> bialix: anyway, with that pdb prompt from the script, please try:
[11:44] <bialix> but I'm sure in most situation it just kill the process and all
[11:45] <spiv> import threading
[11:45] <spiv> pp [t.daemon for t in threading]
[11:45] <spiv> bialix: yep, in most situations it does, but for bzr we've set it to drop into pdb instead :)
[11:46] <spiv> (bzrlib.breakin has the magic)
[11:46] <bialix> *** TypeError: TypeError("'module' object is not iterable",)
[11:46] <spiv> Oh, oops:
[11:46] <spiv> pp [t.daemon for t in threading.enumerate()]
[11:46] <spiv> That's what I get for typing untested code into IRC :(
[11:46] <bialix> *** AttributeError: AttributeError("'Transport' object has no attribute 'daemon'",)
[11:46] <spiv> !
[11:47] <bialix> ?
[11:47] <spiv> That's a weird error.  I guess pdb isn't very good with list comprehensions.
[11:47] <spiv> Ok, just "pp threading.enumerate()"
[11:47] <maxb> bzr: ERROR: Tree transform is malformed [('overwrite', 'new-27', u'branch-format'), ('overwrite', 'new-29', u'branch-lock'), ('overwrite', 'new-34', u'README'), ('overwrite', 'new-9', u'.bzr')]       <---- umm, eek! What is bzr trying to tell me?
[11:48] <bialix> [<paramiko.Transport at 0x15d4150L (cipher aes128-cbc, 128 bits) (active; 1 open channel(s))>,
[11:48] <bialix>  <_MainThread(MainThread, started)>]
[11:48] <spiv> pp threading.enumerate()[0]
[11:48] <bialix> <paramiko.Transport at 0x15d4150L (cipher aes128-cbc, 128 bits) (active; 1 open channel(s))>
[11:48] <spiv> pp threading.enumerate()[0].daemon
[11:49] <bialix> *** AttributeError: AttributeError("'Transport' object has no attribute 'daemon'",)
[11:49] <spiv> Oh!
[11:49] <spiv> Huh.
[11:49] <bialix> yeah
[11:49] <spiv> pp threading.enumerate()[0].isDaemon()
[11:49] <spiv> (hope springs eternal)
[11:49] <bialix> False
[11:49] <spiv> Ok, it is the paramiko thread, as I speculated.
[11:49] <bialix> cool
[11:50] <spiv> I'm not sure why that would be different for the script vs bzr.
[11:50] <bialix> pdb-over-irc in action!
[11:50] <spiv> Yeah.  Painful :)
[11:50] <spiv> But it gets there in the end.
[11:50] <bialix> I think it should be in Standard Python library
[11:51] <bialix> spiv: I think bzr does not use threads?
[11:51] <spiv> Normally not.
[11:51] <spiv> "bzr serve" does.
[11:52] <spiv> And dependencies like paramiko sometimes do.
[11:52] <bialix> so this is difference between script and bzr
[11:52] <bialix> or not
[11:52] <bialix> do you want me other testing?
[11:53]  * bialix bbiab
[11:53] <spiv> bialix: no, I want dinner :)
[11:54] <spiv> I can't really see why a script would behave differently to bzr here.
[11:55] <spiv> Oh, ugh, garbage collection.
[11:55] <spiv> Normally a __del__ triggers the disconnect method.
[11:55]  * bialix back
[11:55] <spiv> I have no idea why the script is *less* likely to allow that to happen.
[11:56] <spiv> Perhaps "del b" at the end of the script would do it.
[11:56] <bialix> script does os.exit
[11:56] <spiv> Or perhaps putting the Branch.open line inside main would.
[11:57] <spiv> Oh yeah, that's right, the 'bzr' script does do os._exit, which would conveniently sidestep the problem of daemon threads.  Heh.
[11:57] <spiv> That probably does explain it.
[11:57] <spiv> Either that, or the fact that the open branch object is a module global in the main script might.
[11:58]  * bialix trying
[11:58] <bialix> does not help
[11:58] <bialix> hang anyway
[11:58] <spiv> Sheese.
[11:58] <spiv> Sheesh, rather.
[11:58] <bialix> after moving b into main() and del b in finally
[11:58] <bialix> what?
[11:59] <spiv> Not sure why it's not gc'd.
[11:59] <spiv> Try "import gc; gc.collect(); print gc.garbage" at the end of the script.
[11:59] <bialix> non-daemon threads never
[11:59] <bialix> on windwos
[11:59] <bialix> AFAIK
[11:59] <bialix> and in my programs it's always problem
[11:59] <spiv> There's a __del__ that normally takes care of this thread.
[11:59] <bialix> so in my multi-threaded programs I'm always force daemon mode
[12:00] <spiv> Sure, but this thread is supposed to be stopped by the normal garbage collection.
[12:00] <spiv> (I mean, __del__ is evil and should die, but that's a separate matter...)
[12:01] <bialix> I dunno
[12:01] <spiv> (And really, this __del__ could be replaced by a weakref callback, which would be more reliable)
[12:01] <bialix> spiv: I think I'd better stop here. Enjoy your dinner, I'm going to lunch
[12:01] <poolie> vila, hi, still here?
[12:01] <spiv> bialix: ok.  Thanks for digging into this mystery.
[12:01] <poolie> hi spiv :)
[12:01] <bialix> I hope it was helpful
[12:01] <spiv> poolie: hello, goodbye ;)
[12:01] <spiv> bialix: it was
[12:02] <bialix> poolie: pretty awful?
[12:02] <spiv> bialix: it's nice to slowly get closer to understanding mysteries :)
[12:02] <vila> poolie: yup
[12:02] <poolie> good night, i'm just trying to catch ... vila
[12:02] <poolie> bialix: the instructions to set up a win32 build environment seem complicated
[12:02] <bialix> spiv: thanks
[12:02] <poolie> that's not the fault of their authors
[12:02] <bialix> pretty or awful? ;-)
[12:02] <bialix> heh
[12:03]  * bialix really wanna lunch
[12:03] <poolie> vila, see PM
[12:03] <bialix-lunch> poolie: maybe you don't trust, but I've tried to simplify things
[12:04] <poolie> heh
[12:04] <bialix-lunch> though cog must die today
[12:04] <poolie> hopefully soon we'll have a machine image that people can use to test it
[12:04]  * bialix-lunch don't think it complicated
[12:05] <bialix-lunch> :-P
[12:10] <crisb> spiv: seems to be hanging while doing setattr during close on the socket
[12:14] <Raim> is there a way to preview the diff of shelved changes?
[12:14] <Raim> I mean, without applying them
[12:15] <Raim> I ran into a state where the shelved changes cannot be applied again... "bzr: ERROR: No final name for trans_id 'new-1'"
[12:23] <vila> crisb: as commented in the bug, the close comes after a shutdown()....
[12:27] <bialix> Raim: I don't find the way, maybe unshelve --dry-run -v does?
[12:27] <Raim> bialix: unfortunately not
[12:28] <bialix> if it's not I'd suggest to file a bug and ensure abentley will see it.
[12:34] <vila> crisb: still there ?
[12:39] <crisb> vila: yep sorry, was just trying out some simple python socket stuff to check it was ok
[12:40] <vila> crisb: great, and the answer is ?
[12:40] <crisb> vila: cant get it to happen with just a simple listen/accept/shutdown/close program
[12:41] <vila> right, so close() shouldn't hand after shutdown() sounds like a valid assumption to you ?
[12:41] <vila> s/hand/hang/
[12:42] <crisb> vila: yeah, as far as I know its good to do shutdown before close :)
[12:44] <vila> crisb: so back to my first question: Is that behaviour new or are you trying selftest for the first time under AIX ?
[12:45] <crisb> vila:think its been that way ever since i've been building bzr on aix..
[12:45] <vila> crisb: well, I kind of prefer  that :-/
[12:46] <crisb> vila: however since I started doing my bzr for unix page I wanted to get the selftests working. (i've never had any problems with general usage of bzr on aix - but I dont do much http serving stuff)
[12:47] <vila> can you re-rerun 'bzr selftest -s bt.test_http -v' and attach  the result to check what tests pass before the hanging one ?
[12:47] <vila> crisb: You have my strong sympathy for doing that and I hope I can help you succeed in making the full test suite running there
[12:48] <vila> crisb: keep in mind though that selftest is a very special case when in comes to hanging threads, bzr is normally run as a client XOR a sever
[12:48] <vila> server
[12:50] <vila> and there are some gremlins in python related to the socket stack when using multiple threads AND having clients doing weird stuff with servers AND servers trying to kick clients when they do weird stuff :)
[12:50] <crisb> vila: :)
[12:51] <crisb> vila: plus the fact that AIX is a great example of 'old IBM' :)
[12:51] <crisb> ie. hmmm everyone does it like this.....lets do it OUR way
[12:51] <vila> i.e. it's very unfortunate that *you* can't (yet !) use the test suite to get confidence that stuff works, but this bug... smells just like that
[12:52] <vila> well, bzr is supposed to shielded by python for those grey areas :D
[12:52] <crisb> vila: have to admit I've built python too !
[12:53] <vila> crisb: do you think you used controversial settings ?
[12:54] <crisb> vila: not really.  few patches for aix weirdness of building shared libraries, but nothing really naughty.
[12:54] <vila> crisb: do you have ssl support ?
[12:55] <crisb> vila: i do
[12:55] <vila> ok
[12:55] <vila> can you re-rerun 'bzr selftest -s bt.test_http -v' and attach  the result to check what tests pass before the hanging one ?
[12:56] <vila> attach to the bug for the record I mean
[12:58] <crisb> vila: done
[12:59] <vila> rats, all my bets are off so far, I was more or less hoping to see pycurl there :-/
[13:00] <crisb> :(
[13:00] <vila> This test does really.... nearly nothing, start the server, stop the server, nobody connects
[13:00] <crisb> vila: sorry will have to continue later..gf is kicking me out ;)
[13:00] <vila> crisb: last thing !
[13:01] <vila> crisb: what you can try is: 'bzr selftest -s bt.test_http --list >all.tests'
[13:01] <vila> and from there use: 'bzr selftest --load all.tests' deleting all hanging tests as you encounter them....
[13:01] <vila> that may give us more hints...
[13:01] <vila> crisb: when you're back :-)
[13:01] <crisb> vila: aha - will do :)
[13:01] <vila> crisb: ^
[13:01] <vila> crisb: thanks !
[15:07] <maxb> Is there any way to be notified when a pull results in *tags* being transferred?
[15:28] <maxb> If you "bzr branch -r some_earlier_revision", the new branch will include all tags from the parent, even ones pointing at revisions that it does not have ..... bug?
[17:02] <garyvdm> Hi jam.
[17:02] <jam> hi garyvdm
[17:02] <ctrlsoft> hi garyvdm, jam
[17:03] <ctrlsoft> jam: thanks for the review!
[17:03] <garyvdm> Jelmer?
[17:03] <garyvdm> Hi
[17:03] <jam> hey jelmer. Surprised to see your other nick
[17:03] <jam> ctrlsoft: nice to have you back, too :)
[17:04] <garyvdm> I got qlog using KnownGraph. I did not result in a performance increase. :-)
[17:04] <jam> garyvdm: well, if you are using stuff like "branch.iter_merge_sorted_revisions()" before, that has already been taught to use KnownGraph under the covers
[17:05] <ctrlsoft> heh, at the current pace of development it's hard to catch up with even two weeks of changes :-)
[17:05] <jam> I don't really know what you do directly, versus indirectly
[17:05] <jam> It also depends on if the bottleneck is in the Qt portions, versus the bzr loading portions.
[17:06] <garyvdm> jam: .iter_merge_sorted_revisions is a big portion
[17:06] <garyvdm> about 50% of the load time
[17:06] <garyvdm> So I am going to peruse just loading the mainline first, and there rest of the graph when the expands a node.
[17:06] <garyvdm> *when the user..
[17:07] <garyvdm> And when bzr can store the gdfo, then I will make it only load the bits of the graph needed.
[19:13] <trondn> why do bzr upgrade leave a backup.bzr directory in my repository ?
[19:14] <beuno> trondn, in case you need to revert
[19:14] <beuno> if something breaks, etc
[19:15] <trondn> well, if bzr upgrade succeeds, why do I want to revert?
[19:15] <trondn> seems to me that I should create a clone before trying to upgrade if I wanted to revert...
[19:15] <beuno> trondn, it's a fantastic question
[19:16] <beuno> I'm an advocate of removing the backup dir once it has upgraded
[19:16] <beuno> but some developers feel that we may get into a situation where things fail, and the dir gets deleted anyway, leaving you with data loss
[19:17] <trondn> well I wouldn't try upgrade on my master repository without having a backup first...
[19:17] <trondn> pretty much the same they tell you to when you upgrade your os ;)
[19:17] <beuno> yeah, I've been nagging to at least have an --delete-after-upgrade option
[19:53] <tbradshaw> hello, is it appropriate to ask end-user questions about bzr in here?  Or, perhaps, should all questions be asked on launchpad?
[19:54] <LarstiQ> tbradshaw: that's appropriate
[19:55] <tbradshaw> thanks
[19:56] <tbradshaw> I'm having issues where I'm trying to commit to a svn branch, and it's informing me that my svn version is out of date, when that doesn't appear to be the case:
[19:56] <tbradshaw> http://pastebin.projects.quakecon.org/65
[19:57] <tbradshaw> of note, I'm on OSX
[19:57] <LarstiQ> tbradshaw: is subvertpy compiled against that svn though?
[19:58] <tbradshaw> Hmmm, good point and likely not
[19:58] <tbradshaw> I'm pretty sure that I just fetched the OSX latest binaries from the bzr site
[19:58] <tbradshaw> I'll confirm
[19:59] <LarstiQ> tbradshaw: so, with an svn working copy, the data structures system svn 1.6 stores may not be readable by subvertpy libsvn 1.5
[20:00] <LarstiQ> tbradshaw: one option is to bzr branch, commit in that, push
[20:00] <tbradshaw> Forgive my naivety, I'm a bit new at bzr
[20:00] <LarstiQ> avoids having to muck with svn working copy formats
[20:00] <LarstiQ> tbradshaw: np
[20:00] <tbradshaw> I had attempted to follow the instructions to do just that.
[20:00] <tbradshaw> these: http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#using-a-central-repository-mirror
[20:01] <tbradshaw> and I was a bit surprised when a commit immediately triggered a push
[20:02] <LarstiQ> the commands listed there can't get you in the situation you're in
[20:02] <tbradshaw> no, I'm wrong
[20:02] <tbradshaw> I followed my history
[20:02] <tbradshaw> and I used "checkout" instead
[20:02] <LarstiQ> tbradshaw: what does `bzr info` say in the branch you tried to commit in?
[20:02] <LarstiQ> tbradshaw: right, that makes more sense
[20:03] <tbradshaw> I'll get a fresh branch made and give it another shot
[20:03] <tbradshaw> thanks for your time LarstiQ, I appreciate it. :)
[20:04] <LarstiQ> tbradshaw: let me know how things work out :)
[20:04] <tbradshaw> I will!
[20:08] <lifeless> moin moin
[20:08] <lifeless> jam: hi
[20:26] <lifeless> jam: ping
[20:45] <tbradshaw> LarstiQ: while I did end up with a different workflow, the core issue didn't resolve
[20:46] <tbradshaw> it appears that the bzr 1.17 disk image provided for Mac OSX is insufficient for now. :(
[20:48] <LarstiQ> tbradshaw: hmm
[20:51] <tbradshaw> LarstiQ: would you be familiar with the differences in the osx disk images?  For instance, would you expect some sort of incompatibility with using an image intended for an older version of OSX?
[20:51] <tbradshaw> it appears that the 10.4 images are kept very up to date
[20:52] <tbradshaw> in comparison with 10.5
[20:52] <tbradshaw> hmmm, I guess those are unstable anyway
[20:53] <tbradshaw> I'll try reinstalling, just in case it does any rebuilding that could resolve this for me
[20:54] <LarstiQ> tbradshaw: I'm not really familiar with them, no
[21:00] <tbradshaw> perhaps I can just rebuild subvertpy
[21:01] <ronny> sup
[21:02] <ronny> where is jelmer?
[21:02] <ctrlsoft> back from vacation as of yesterday!
[21:03] <ronny> im tring to allocate all the guys from the different svn interaction projects in order to get a single svn history analysis lib that can deal with most of the broken fucked up svn repos out there
[21:04] <ronny> (kida selfish, i need such a thing for anyvc)
[21:05] <ronny> and meh, i dont want yet another one, svn is pain enough on its own
[21:06] <jelmer> can you explain a bit better what you're looking for exactly?
[21:06] <jelmer> bzr-svn has functionality for this, but it makes assumptions about the sort of history changes that can happen and honors bzr-svn-specific revision/file properties to cope with things that can't be represented in svn natively
[21:07] <ronny> jelmer: i want something that can view messed up svn histories (unfortunately those exist all over the place) as something semilar to a dvcs dag
[21:07] <jelmer> ronny: so, subvertpy could take care of some of this but it would need hooks in various places so bzr-svn can still do its magic
[21:07] <ronny> (and i'd like the possibility to dump enough metadata at svn to make it easyly usable by stuff like hgsubversion and bzrsvn)
[21:33] <lvh> Hi!
[21:33] <lvh> I'm using Packs 6 (uses btree indexes, requires bzr 1.9)
[21:33] <lvh> is updating to 2a a good idea?
[21:33] <beuno> lvh, yes. Major performance wins, and some space savings as well
[21:33] <beuno> keep in mind, you'll need to upgrade all your branches
[21:34] <lvh> Okay. It is in a state that I can expect my repos to not be eaten?
[21:34] <lvh> Oh.
[21:34] <beuno> yes it is  :)
[21:34] <lvh> Well, it's a branch of twisted
[21:34] <lvh> In that case i need to wait for them to move to 2a
[21:34] <lvh> beuno: Thanks for the quick answer :-)
[21:34] <beuno> welcome'
[21:37] <ronny> lifeless: on a sidenode, for me bzr something is still constantly at least 0.2 seconds slower than hg something (usually 0.4-0.5 vs 0.2-0.3 seconds) when will that be fixed (cause its the difference between noticable to my attention span)
[21:38] <lifeless> ronny: it'll be 0.1 faster or so if you run with --no-plugins I suspect ;)
[21:39] <ronny> lifeless: i got tonns of plugins on hg and none of bzr
[21:40] <lifeless> ronny: how long does 'time bzr --no-plugins info' take
[21:41] <ronny> real	0m0.843s
[21:41] <ronny> user	0m0.419s
[21:41] <ronny> sys	0m0.146s
[21:42] <ronny> bzr v 1.18, old format branch
[21:42] <ronny> it takes about 0.1 seconds less outside of a bzr dir
[21:42] <ronny> hmm
[21:42] <ronny> it goes down 0.3 after the caches are hot
[21:44] <lifeless> so how long?
[21:45] <ronny> real	0m0.550s
[21:45] <ronny> user	0m0.429s
[21:45] <ronny> sys	0m0.120s
[21:45] <ronny> on a small vellum branch
[21:45] <lifeless> right
[21:46] <lifeless> thats just info, no -v
[21:46] <lifeless> ?
[21:48] <ronny> lifeless: just info
[21:50] <lifeless> ok
[21:50] <lifeless> so this is basically your lower bound for bzr on your machine
[21:50] <ronny> lifeless: its a laptop
[21:50] <lifeless> now try with 'time bzr --no-plugins info'
[21:50] <ronny> and no sdd
[21:50] <lifeless> ronny: its not IO, not once the cache is hot
[21:50] <ronny> real	0m0.547s
[21:50] <ronny> user	0m0.381s
[21:50] <ronny> sys	0m0.143s
[21:50] <lifeless> info doesn't write
[21:51] <lifeless> bzr plugins
[21:51] <lifeless> I bet you have 2 or 3 installed
[21:52] <ronny> launchpad, netrc_credential_store, qbzr
[21:52] <lifeless> :)
[21:52] <zsquareplusc> http://bazaar-vcs.org/Scenarios has some empty pages, like "Share common versioned code (e.g. standard utilities) between multiple projects" is there some other documentation about this?
[21:53] <lifeless> so, I'd like to make the overhead of loading code lower
[21:53] <lifeless> but its so far proved fairly resistant to cheap fixes
[21:53] <lifeless> zsquareplusc: doc.bazaar-vcs.org has a comprehensive user guide
[21:54] <ronny> lifeless: my lower bounds for hg are around:
[21:54] <ronny> real	0m0.271s
[21:54] <ronny> user	0m0.179s
[21:54] <ronny> sys	0m0.082s
[21:55] <ronny> lifeless: and thats with with 14 extensions
[21:55] <lifeless> ronny: yes, hg's code is extremely pithy
[21:55] <ronny> 'pithy' ?!
[21:56] <ronny> i quite like it, most of the anyvc stuff for hg was done in fractions of the time i needed for bzr
[21:56] <jelmer> ronny:
[21:56] <jelmer>        adj : concise and full of meaning; "welcomed her pithy comments";
[21:56] <jelmer>              "the peculiarly sardonic and sententious style in which
[21:56] <jelmer>              Don Luis composed his epigrams"- Hervey Allen [syn: {sententious}]
[21:56] <ronny> jelmer: ah, thanks
[21:57] <lifeless> ronny: pithy - small, compact.
[21:57] <jelmer> ronny: that's mainly dependent on what you're familiar with though, I suspect
[21:57] <ronny> lifeless: but that quite fits the most important rule 'to be fast, do less'
[21:58] <ronny> jelmer: well, hg is something i can keep i my head as whole, bzr isn't
[21:59] <ronny> and that results in a direct massive productivity gain
[21:59] <jelmer> ronny: I'm working on bzr-hg and for me it's the other way around
[21:59] <ronny> hg's model is absolutely simple
[22:00] <ronny> you got a store of revlogs, some represent files, then there is the manifest, and the changelog,
[22:01] <ronny> one of the thing that might be bugging is stuff like infering directory-renames
[22:01] <lifeless> ronny: so its bzr's: you have a byte store, files, inventories & commits.
[22:02] <ronny> i came to the conclusion that cimplex inventories are no real gain
[22:02] <ronny> they never catch the intresting details
[22:02] <ronny> cause thats file-level refactorings
[22:03] <ronny> lifeless: bzr's model is not that appearant from how one codes for it
[22:03] <jelmer> ronny: where are inventories significantly different from manifests?
[22:04] <ronny> jelmer: i think the main difference is dont care about directories
[22:04] <ronny> also there is no inode id maping
[22:04] <jelmer> ronny: inode id mapping?
[22:04] <ronny> (god how i hate that path2id stuff on memorytrees)
[22:15] <ronny> jelmer: another issue with bzr is, all those inheritance tres that distribute meanings across the whole source tree
[22:17] <ronny> jelmer: btw, whats driving you to do bzr-hg, and whats missing to make a hg-bzr as well?
[22:19] <jelmer> ronny: being able to "bzr branch hg://foo" and natively push/pull hg repo's
[22:20] <jelmer> I'm not sure what would be necessary for a hg-bzr
[22:20] <zsquareplusc> don't you get that for free then? when you can push to empty hg repo you have the conversion?
[22:21] <zsquareplusc> lifeless: is scrolled through the contents of the user guide but i don't see anything about that topic.
[22:21] <ronny> jelmer: from the bzr codebase side, is there any diffence to it where the bzr repos are?
[22:21] <ronny> jelmer: i think the only thing really missing is some quick wraper around hg's localrepo
[22:21] <zsquareplusc> is there a workflow that helps where svn:externals are used in the other VCS?
[22:22] <lifeless> zsquareplusc: not currently
[22:22] <lifeless> zsquareplusc: we haven't finalised our equivalent to externals, they aren't supported today. You can use an external tool, such as config-manager, instead.
[22:23] <lifeless> http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#workflows
[22:23] <zsquareplusc> but is it possible to to a bzr checkout of one branch within an other? running ci/update etc on the "sub repo" would be to bad
[22:23] <lifeless> is the workflows stuff you were asking about
[22:23] <lifeless> you can checkout Foo ; cd foo; checkout bar
[22:23] <lifeless> that works fine, you just have to commit bar and foo separately
[22:24] <zsquareplusc> ok :-)
[22:26] <ronny> jelmer: my ideal goal would be to have n-way integration between all reasonable vcs's on anyvc, but thats pretty much a pipedeam for now
[22:30] <lifeless> jelmer: hi
[22:30] <lifeless> jelmer: is bzr-svn supporting concurrent access to the same svn /repo/ ?
[22:35] <jelmer> lifeless: as much as svn itself is
[22:36] <lifeless> jelmer: in #twisted, a sqlite3 operationalerror was encountered by exarkun
[22:36] <jelmer> lifeless: ah
[22:36] <lifeless> pushing and pulling at the same time to svn
[22:36] <jelmer> lifeless: using tdb should work around that
[22:38] <jelmer> ronny: in that regard anyvc provides the same sort of abstraction as bzr does
[22:40] <ronny> jelmer: i thing bzr's abstractions are layered a bit weird, a vcs shoudl be a vcs first, not a abstraction lib
[22:57] <poolie> hello jelmer, welcome back
[22:58] <poolie> hello jam?
[22:58] <lifeless> morning mr poolie ;)
[23:03] <jam> hi poolie
[23:05] <poolie> hi, shall we talk?
[23:05] <jam> poolie: yeah, can you call the house? I just got the new laptop so not everything is set up yet.
[23:06] <poolie> sure
[23:09] <poolie> sorry, sound troubles...
[23:09] <jam> np
[23:43] <lifeless> jam: whats the new laptop?
[23:45] <jam> lenovo t500
[23:46] <jam> 2.8GHz cpu, 3GB ram, etc
[23:46] <lifeless> nice
[23:47] <lifeless> hmm fastexport-hg is kinda slow
[23:47] <lifeless> about 5revs a sec
[23:53] <lifeless> jam: when you are around, I want to talk realtime about this
[23:53] <lifeless> grouping issue