[00:00] <mwhudson> jelmer: how much of a good idea is upgraded dulwich?
[00:01] <lifeless> igc: thanks
[00:01] <poolie> wow, vila went crazy on the bugs
[00:01] <poolie> hello igc
[00:01] <poolie> want to catch up some time?
[00:02] <lifeless> spm: ping
[00:02] <lifeless> spm: balleny's pqm is dying
[00:03] <lifeless> Permission denied (publickey).
[00:03] <jam> igc: think you could look at https://code.edge.launchpad.net/~jameinel/qbzr/bug_430232_early_qapp/+merge/11831 ?
[00:03] <lifeless> I think the backtrace is a furfy
[00:03] <jam> I'd like to get it into a bzr installer tonight if at all possible
[00:03] <igc> jam: shall do
[00:03] <jam> mmmmmm furfy
[00:04] <igc> poolie: let me look into these bugs for jam. Call around lunch time ok?
[00:04] <poolie> fine with me
[00:05] <thumper> jelmer: why is the trunk dulwich branch on LP registered as remote?
[00:08] <SamB> thumper: most of jelmer's branches are ;-)
[00:09] <SamB> he likes to keep them on samba.org for some reason
[00:09] <poolie> who does the os x installers now? guillermo?
[00:12] <jam> SamB, thumper: I'm pretty sure jelmer wants people to get "the absolute latest" when they do "bzr branch lp:dulwich" and not a potentially 5-hours out-of-date mirror
[00:12] <jam> That was the argument he gave earlier for bzr-svn, IIRC
[00:12] <jam> since he doesn't want to directly host them on lp
[00:14] <thumper> why ever not? :)
[00:14] <thumper> we're open now :)
[00:16] <SamB> most of *my* mirrored branches are supposed to update hourly
[00:16] <SamB> thumper: probably he likes having direct access to the part of the filesystem on which he keeps them ?
[00:17] <SamB> well, more direct, I mean
[00:17] <lifeless> jml: Around?
[00:17] <poolie> emmajane: btw if you're around i have checked the moderation queues and there's nothing interesting held there
[00:17] <SamB> of course, 2/3 of my mirrored branches are mirrors of SVN branches
[00:18] <SamB> and the other one of a branch that launchpad never manages to pull
[00:19] <SamB> well, that's calculated by project and not by branch, actually
[00:20] <jml> lifeless, yes
[00:20] <SamB> ... though *one* of those SVN mirrors is not strictly read-only
[00:20] <SamB> ... if anyone has any dosemu branches they'd like merged, don't hesitate to submit a merge request ;-)
[00:26] <igc> jam: that patch looks good to me
[00:26] <jam> igc: so do you know what the 0.14 branch is for?
[00:26] <jam> Is qbzr going to be doing a stable branch as well?
[00:27] <igc> jam: 0.14 is the branch for karmic
[00:27] <igc> jam: and the Windows 2.0.0 release as well
[00:27] <jam> igc: sure, I was just wondering if the plan was for 0.14.x to be part of the 2.0.1+ releases as well
[00:28] <igc> jam: I suspect 2.0.1 with go out with qbzr 0.15 but that's up to bialix and garyvdm to make that call
[00:28] <lifeless> jml: http://rbtcollins.wordpress.com/2009/09/16/back-from-hiatus/
[00:29] <jam> igc: well technically it is probably up to me, since I'll likely be doing the packaging :)
[00:29] <igc> jam: I'm certainly planning for explorer 0.9, not 0.8.x, to go out with 2.0.1
[00:29] <igc> jam: :-) :-)
[00:29] <lifeless> jml: I thought you might either a) know of something, or b) have thoughts on the proposition
[00:29] <jam> but usually I just follow the recommendations
[00:29] <poolie> rebooting for karmic
[00:30] <igc> jam: do you want me to merge that change to 014? Or is your connectivity good enough?
[00:30] <jam> igc: I'm landing it now
[00:30] <jam> I'm not sure what it will take to do a 0.14.2, though
[00:30] <jam> so I may just take it and do 0.14.1-win32-1
[00:31] <jam> igc: is dancingmonkeys continually updated?
[00:32] <igc> jam: what do you mean by that?
[00:32] <igc> it's just a branch I push after making edits
[00:32] <jam> igc: how often does http://people.canonical.com/~ianc/dancingmonkeys/ update
[00:32] <igc> whenever I manually update it
[00:33] <igc> emmajane has the master branch - my stuff is just suggestions/experiments
[00:34] <jml> lifeless, looking...
[00:44] <lifeless> jml: thanks
[00:44] <spm> lifeless: should be happening again
[00:50] <lifeless> spm: what is needed for subunit in the chroot ?
[00:51] <spm> lifeless: aiui, a package built; but I'm not across all the details; so that's a pretty handwavy response.
[00:51] <lifeless> spm: all we need is python-subunit
[00:51] <lifeless> you have packages of that :)
[00:51] <spm> not for dapper, aiui
[00:52] <lifeless> shouldn't matter
[00:54] <lifeless> spm: you should be able to just dpkg -i the python-subunit package
[00:58] <lifeless> spm: can you do a manual push from balleny +trunk ?
[00:59] <spm> lifeless: I believe it also had a requirement on python-central which also wasn't in dapper. tbh, these may be trivial workarounds. I know that lamont and tom have been working on this stuff, so I'm kinda coming in with a fraction of the picture here.
[00:59] <spm> bzr trunk? sure. one sec.
[01:00] <lifeless> spm: did it have any revisions to push ?
[01:00] <spm> lifeless: Pushed up to revision 4690.
[01:00] <lifeless> 5 commits old ><
[01:00] <spm> it had had a push branch location of you@escudero if that helps?
[01:00] <lifeless> no
[01:01] <lifeless> thats the old location
[01:01] <spm> k
[01:01] <lifeless> you should save the new ones
[01:01] <spm> did on this case; it seemed the right thing to do :-)
[01:01] <lifeless> pqm uses the configured value in the pqm.conf though, so that shouldn't have mattered
[01:02] <spm> hang a sec.... $ bzr push --remember bzr+ssh://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev ;; yet still shows: push branch: sftp://robertc@escudero/srv/www.bazaar-ng.org/rsync/bzr/bzr.dev
[01:02] <spm> is that an issue? or did I syntax it?
[01:02] <lifeless> check ~/.bazaar/locations.conf
[01:03] <spm> ahhh. right. I see - I guess THAT should also be updated.
[01:03] <lifeless> or removed
[01:03] <lifeless> [the stanza not the file]
[01:03] <spm> :-)
[01:04] <lifeless> statik: http://elliotmurphy.com/ is down?
[01:05] <spm> lifeless: that stanza has post_commit_to bits; I assume that no longer matters now via LP
[01:05] <lifeless> correct
[01:05] <lifeless> uhm
[01:05] <lifeless> actually
[01:05] <lifeless> lp's pqm uses lp notifications
[01:05] <lifeless> I think we still get the ones to bazaar-commits.
[01:05] <lifeless> whats the stanza? [paste it somewhere]
[01:06] <spm> [/home/pqm/archives/thelove/bzr/+trunk]
[01:06] <spm> post_commit = bzrlib.plugins.email.post_commit
[01:06] <spm> post_commit_to = bazaar-commits@lists.canonical.com
[01:06] <spm> push_location = sftp://robertc@escudero/srv/www.bazaar-ng.org/rsync/bzr/bzr.dev
[01:06] <spm> small enough to go here
[01:06] <lifeless> delete the post_commit and push_location lines
[01:06] <spm> kk
[01:06] <lifeless> the former is deprecated the latter wrong :P
[01:06] <spm> heh
[01:07] <spm> info -v looks much happier. ta
[01:14] <BasicOSX> bzr.dev/bzrlib/osutils.py:928: UserWarning: bzr: warning: Failed to load compiled extensions: <snip> how do I compile these extensions?
[01:16] <lifeless> BasicOSX: 'make'
[01:17] <BasicOSX> pages and pages of errors under os x :-(
[01:17] <lifeless> hmm
[01:17] <lifeless> there is an installer for os x
[01:17] <lifeless> you might want to look at the docs on how that is built, and follow that process
[01:17] <BasicOSX> defeats the purpose for running bzr.dev by using installer :-)
[01:18] <lifeless> nono
[01:18] <lifeless> I'm not saying use the installer
[01:18] <lifeless> I'm saying follow the docs on how to build it
[01:18] <lifeless> to get a built bzr
[01:20] <BasicOSX> That doesn't seem very pythonic  ... whole reason I picked bzr was simple install and go. If I wanted to compile stuff I would have picked git :-( I hope there was magnitude performance increases by going with .pyx
[01:20] <verterok> poolie: hi
[01:20] <lifeless> BasicOSX: so, I think you can squelch that warning
[01:21] <lifeless> I think poolie: ^ might know
[01:21] <lifeless> BasicOSX: and yes, _huge_ performance differences
[01:21] <lifeless> BasicOSX: we do run fine without the extensions.
[01:21] <BasicOSX>   yes, done already, just venting on simple (slow) vs complicated and fast
[01:21] <poolie> hi verterok
[01:22] <lifeless> BasicOSX: my personal vent is on python being slow :)
[01:22] <verterok> poolie: re: os x installers, what's up?  :)
[01:22] <poolie> BasicOSX: 'echo ignore_missing_extensions=True >> ~/.bazaar/bazaar.conf' should do it
[01:22] <igc> hi verterok
[01:23] <poolie> BasicOSX: it is much faster so the point is to just make sure people are making an informed choice to do without them
[01:23] <verterok> poolie, igc: btw, I'm trying to build a Bazaar.app bundle (without much success :()
[01:23] <verterok> igc: hi
[01:23] <poolie> if you can think of a better way to handle it i'm all ears
[01:23] <poolie> verterok: it sounds like a great idea, i wish you luck!
[01:23] <verterok> poolie: igc idea
[01:24] <BasicOSX> raw point right now, getting a hard time from the git people on the GPGMail project about bzr is a moving target and "broken" many times
[01:24] <verterok> I'm having some issues to make py2app include all the packages/modules
[01:24] <verterok> s/to make/making/
[01:25] <igc> verterok: the *really* big issue from my perspective on OS X is getting PyQt bundled in our installer
[01:25] <poolie> BasicOSX: i'm hoping that will be much more stable with bugfixes only into 2.0
[01:26] <BasicOSX> I'm sending you feedback :-)
[01:27] <verterok> igc: would be really cool to include it (bzr-explorer, etc), but with the current installer it's a bit difficult, a.k.a: I don't know if it's going to work at all. The bundle approach is a lot more promising
[01:29] <verterok> igc: the main issue is that we must include Qt too, and it's going to be a *really* big dmg
[01:29] <jam> igc: if you are around I'd like to chat about something
[01:29] <igc> jam: yep
[01:29] <jam> igc: so I just sent an email updating bug #430311
[01:29] <jam> igc: but basically, I think lightweight checkouts + bzr-explorer + qbzr are a pretty bad idea
[01:30] <jam> bzr-explorer always spawns a subprocess to do anything
[01:30] <jam> and *so does qbzr*
[01:30] <igc> verterok: I wasn't suggesting it would be easy, but I feel
[01:30] <jam> which means that to go from viewing your tree
[01:30] <poolie> spiv, hi?
[01:30] <verterok> igc: :)
[01:30] <jam> through commit and back
[01:30] <jam> connects 4+ times
[01:30] <igc> verterok: that 90% of mac users will end up using the GUI before long
[01:31] <igc> jam: :-(
[01:31] <jam> and in my testing here with an Ubuntu server
[01:31] <jam> the ssh handshake is *super* slow
[01:31] <jam> like >1s on the local network
[01:31] <jam> I assume this is something about security issues
[01:32] <jam> (I've also noticed it when using openssh to connect from an Ubuntu desktop...)
[01:32] <spiv> poolie: oh, hi!
[01:32] <jam> hey spvi
[01:32] <jam> spiv:
[01:32] <verterok> igc: fully agreed
[01:32] <jam> igc: so... I have to wonder if we want to make "Checkout" heavy by default in bzr-explorer
[01:33] <lifeless> BasicOSX: broken in any particular way?
[01:33] <jam> I know we have the whole discussion about what things should be
[01:33] <lifeless> BasicOSX: or just that the OSX installers weren't always polished?
[01:33] <jam> but the alternative is trying to find a way to share connections between subprocess
[01:33] <BasicOSX> Maybe poolie  can forward your my email :-)
[01:33] <jam> or teaching bzr-explorer + qbzr to be done using threads ??
[01:33] <poolie> i don't have any mail from you (yet)
[01:35] <BasicOSX> Sent to sourcefrog email, just resent to canonical
[01:35] <poolie> jelmer, hi?
[01:35] <poolie> it may just be delayed somewhere
[01:35] <igc> jam: I personally think 'checkouts' are only sensible when pointed to a local branch, preferably disk path accessible
[01:36] <spiv> poolie: I'm finishing that userdir patch atm.
[01:36] <igc> jam: so a bound branch is the answer IMO
[01:36] <poolie> yay
[01:36] <igc> jam: I'm looking to change the branch dialog so ...
[01:36] <igc> (1) it has a 'bind this branch to parent' checkbox
[01:36] <jam> igc: so... in a corporate setting, we'd like to say that all commits are auto-mirrored to the central location where everything is backed up
[01:37] <jam> having a lightweight checkout pointing at a local bound branch is....
[01:37] <igc> (2) warns you if the destination isn't in a shared repo
[01:37] <igc> (3) opens the created location implicitly on completion
[01:37] <igc> jam: but it was too risky to do before 0.8
[01:37] <BasicOSX> well, will run with ignore_missing_extensions=True since depends for getting things compiled for os x are long and many :-(
[01:39] <igc> jam:is ... ?
[01:39] <jam> igc: a bit odd at best
[01:40] <igc> jam: why do you think it's odd?
[01:40] <jam> I realize it probably works, but a checkout of a bound branch is hard to give as a recommendation
[01:40] <igc> jam: hmm
[01:41] <igc> jam: I think checkouts are the current answer to 'shared tree' ala git
[01:41] <igc> jam: bound branches are quite independent IMO
[01:41] <igc> jam: and mixing the two is fine as far as I'm concerned
[01:42] <igc> jam: at least conceptually - I don't know how reliable it is
[01:42] <jam> igc: so internally I'm pretty sure it all works
[01:43] <jam> probably conceptually the largest problem is that both are currently called "checkouts"
[01:43] <igc> jam: not in epxlorer :-)
[01:43] <jam> igc: well, since it doesn't have "Bound branches"
[01:43] <jam> nor heavyweight checkouts
[01:43] <jam> (I think)
[01:43] <igc> jam: it has bound branches
[01:44] <igc> jam: it's just 2 steps to set up currently: branch then bind
[01:44] <igc> jam: hence my wish for a checkbox in the branch dialog
[01:45] <jam> igc: so I assume you are already aware of the "Branch" should automatically open the target bug
[01:45] <igc> jam: yes, I wanted to fix it for 0.8 but ran out of time
[01:45] <jam> also... what about "create a working tree"
[01:45] <jam> at the moment the way to create a tree in a treeless branch is to run the checkout dialog
[01:45] <jam> with a target of '.'
[01:45] <igc> jam: 0.8.1 already refreshes the repo view btw
[01:46] <jam> which oddly, then opens the checkout in a new tab... :)
[01:47] <igc> jam: we'll need to trap the '.' case
[01:47] <igc> jam: 0.8 got auto-opening working for Init and Checkout but not Branch
[01:47] <jam> sure, but it seems like "Work" could have a "create a working tree here" case...
[01:47] <jam> at least, maybe
[01:47] <jam> igc: so if you want to have a "and bind to parent"
[01:48] <jam> then I have a workflow suggestion for you
[01:48] <igc> fire away
[01:48] <jam> which is "create a remote branch on the server, create a local branch of that, bind it, and switch my lightweight checkout to point at the local branch"
[01:48] <jam> Which should really be 1 action
[01:49] <igc> jam: sounds good
[01:49] <jam> I also find that I really wish something like "qlog" was as directly visible as the working tree...
[01:49] <jam> Possibly with just a summary of the last few revs, etc.
[01:49] <igc> jam: the repo view does exactly that
[01:50] <jam> I personally find the Collaborate / Explore / Work distinction difficult to track
[01:50] <igc> jam: but you don't have repos there
[01:50] <igc> jam: the 'virtual repo' (r workspace or whatever we call it) will too
[01:50] <jam> igc: well, if we're going to switch to repos + bound branch + checkouts then maybe we will
[01:51] <jam> though I just got a traceback trying to open a repository
[01:51] <igc> jam: btw, try the 'extended' toolbar - it has log directly on the toolbar
[01:51] <igc> jam: I use it 90% of the time
[01:52] <igc> jam: I'll explain Collaborate, etc. in the User Guide when I get to it
[01:53] <igc> jam: basically, one is for working with others, one is for looking at information and one is for 'local' actions that do something
[01:53] <jam> igc: I like the expanded form... though I wonder why you don't think it should be the default
[01:53] <igc> jam: it was orginally
[01:54] <jam> igc: I guess my point for '"qlog" was as directly visible ' is that when I open up a branch
[01:54] <jam> well a working tree
[01:54] <jam> I have ... 90% whitespace on my screen
[01:54] <jam> and digging down to find 'log' is uncomfortable
[01:54] <igc> jam: I found it too busy when explaining explorer to solo developers that don't use the collaborate actions
[01:56] <igc> jam: so the UI challenge w.r.t. stuff like qlog embedded is performance
[01:56] <igc> jam: it's easy enough to launch and then hit refresh
[01:57] <igc> (within the qlog window)
[01:57] <jam> igc: ... sort of
[01:57] <jam> it isn't how I would use it as a user
[01:57] <igc> jam: but opening qlog every time someone opens a branch scares me
[01:58] <jam> igc: faster than an ssh handshake for me... :)
[01:58] <jam> 5s for bzr.dev
[01:58] <igc> jam: :-)
[01:58] <jam> but my specific point is that you could do the trivial view first, with only the last 10 mainline commits, with swivels that didn't do anything yte
[01:58] <jam> yet
[01:58] <jam> since you very quickly know the last few revs and their revnos, and whether they are merges
[01:59] <igc> jam: right
[01:59] <jam> igc: if I decided to spend some time on it... where would you put it to make visual sense?
[01:59] <igc> jam: hmm
[01:59] <jam> (i also still find that I'd prefer the working tree view to show colored status rather than having that as textual info in the left pane...)
[02:00] <igc> jam: explorer has an extension mechanism right now where plugins can register 'panels' to display for various types
[02:00] <igc> jam: you could do a qlog panel
[02:01] <igc> that displayed for things with a working tree
[02:01] <igc> or any type for that matter
[02:01] <igc> jam: working tree love is coming
[02:02] <igc> jam: keep in mind that explorer *code development* has mainly been an out of hours project!
[02:02] <jam> well, my stomach is telling me that I better go hit the dining room or I'll be starving in another hour when they close... :(
[02:02] <igc> jam: I reply to bugs on work time of course
[02:02] <jam> igc: yeah... the main issue I see is that if we are going to have a gui under support
[02:02] <jam> we better be able to expense some developer time to work on it
[02:02] <igc> jam: and we can post 2.0
[02:02] <igc> I believe
[02:03] <jam> I know the whole "not a gui dev shop" thing...
[02:03] <igc> jam: pre 2.0, the team focus was different as you know
[02:04] <igc> jam: but I really felt passionate about having a nice GUI as well - hence my many late night these last few months
[02:05] <igc> jam: grab some food - we can chat more later
[02:05] <jam> well, I know wavesat is a bit concerned about using the gui...
[02:05] <jam> they seem to be willing to switch to recommending the command line
[02:05] <jam> I think the segfault was the big scare
[02:05] <igc> jam: it would have been
[02:06] <jam> well, mostly I'm saying they were thinking that switching to the command line would be a reasonable trade, rather than thinking to abandon bzr
[02:06] <jam> which I was happy about
[02:07] <igc> jam: I'd see how tomorrow goes with your fix landed
[02:08] <igc> jam: thanks for all the feedback btw
[02:09] <jam> be back later
[02:30] <igc> jam: is using a smart server without ssh an option?
[02:52] <SamB> oh, what was that loom alternative ?
[02:53] <spiv> jelmer: ping?  It looks very much to me like the --protocol option to bzr serve has never worked?
[02:53] <spiv> jelmer: which seems improbable, given that bzr-svn has code to use it, but the code in trunk is clearly broken...
[02:56] <spiv> jelmer: (specifically, if --protocol is given on the command line, the code tries to use that value directly without looking it up in the registry)
[02:58] <spiv> jelmer: Oh, nevermind, I think I see.
[03:04] <lifeless> SamB: pipes
[03:04] <SamB> lifeless: isn't it called pipeline ?
[03:04] <SamB> I must have been blind when was looking at the plugins page to try to spot the name earlier ...
[03:15] <SamB> lifeless: now where's a good tutorial ?
[03:17] <jam> igc:  maybe, but I think they want some level of access control, like having only 1 gatekeeper able to commit to the 'trunk' branch
[03:18] <igc> jam: that access control is independent of ssh vs bzr isn't it?
[03:18] <jam> igc: it is filesystem based, but if you are using 'bzr serve' then it runs as the server user
[03:18] <lifeless> SamB: no idea sorry ;P
[03:18] <jam> versus bzr+ssh running as the ssh users
[03:18] <igc> jam: ah - didn't know that
[03:18] <jam> igc: since bzr:// doesn't do auth itself
[03:19] <SamB> hmm, how to set the submit branch ?
[03:24] <jam> igc: what do you think about having "cmd_explorer" subclass "QBzrCommand" ?
[03:24] <igc> jam: I'm ok with that
[03:24] <jam> I think at one point you wanted to be toolkit agnostic
[03:24] <jam> but you seem pretty tied to qt now
[03:25] <igc> jam: I think it caused some exception in my early Qt hacking days so I went another path at the time
[03:25] <igc> jam: it's toolkit agnostic w.r.t. launching dialogs
[03:26] <igc> jam: the core code needs to be in some toolkit and Qt seemed a good choice
[03:26] <jam> igc: yeah, but if you are already depending on qt... it seems a bit silly to the depend on gtk at the next level
[03:26] <jam> that, and you don't actually support bzr-gtk in the drop down list anymore .. :)
[03:26] <igc> jam: right, so bzr-gtk is optional; qbzr is required
[03:26] <igc> jam: if bzt-gtk is installed, it will appear in the list
[03:27] <jam> ah, k
[03:27] <jam> I guess i mostly played with the installer
[03:27] <igc> jam: some users prefer the bzr-gtk dialogs and that's fine by me
[03:41] <AfC> Notably anyone running a GNOME Desktop
[03:41] <AfC> and who doesn't have any Qt or KDE libraries on their system
[03:46] <SamB> AfC: that's going to work real well with bzr explorer!
[04:01] <igc> jam: rev 275 of explorer has a few of your bugs fixed
[04:02] <igc> jam: I'll release a 0.8.1 later today if they are useful enough to include in your new installer
[04:03] <jam> igc: checking
[04:06] <jam> igc:  I think the "create if missing" fix is worthy
[04:06] <jam> since it will make a difference for a lot of use cases
[04:07] <jam> igc: any chance you could do 0.8.1 now so I can build -2 before I sleep?
[04:08] <jam> igc: also http://paste.ubuntu.com/271819/
[04:08] <jam> fixes some of the "prompted for password on console rather than via dialog" that I've run into
[04:08] <jam> I haven't 100% validated it yet, which is why it isn't a submitted patch
[04:11] <jam> igc: well, actually I did just test it, and everything seems to work, so I'll push it up as a branch for you to merge
[04:12] <jam> is bzr-explorer in 2a or 1.9 format?
[04:14] <igc> jam: 1.9
[04:17] <AfC> SamB: bzr-explorer ... that's for Microsoft Windows, right?
[04:17] <AfC> (ie's a Windows Explorer plugin like Tortise, isn't it?)
[04:17] <SamB_XP> AfC: anything with Qt, AIUI
[04:17] <lifeless> AfC: nope; its a gui for doing bzr stuff, AIUI
[04:17] <AfC> uh
[04:17] <igc> AfC: explorer runs on Windows, GNOME, KDE and OS X
[04:18] <AfC> igc: it has a GTK back end?
[04:18] <SamB_XP> AfC: hahahaha
[04:18] <igc> AfC: it can call out to either QBzr or bzr-gtk
[04:18]  * AfC is confused
[04:18] <SamB_XP> you think you can't run a Qt app in GNOME ?
[04:18] <igc> AfC: the app itself is Qt
[04:18] <AfC> SamB_XP: you can't run KDE apps on a box that doesn't have Qt installed, no
[04:19] <SamB_XP> it's not a "KDE App"
[04:19] <SamB_XP> though sadly qt4 is rather huge :-(
[04:19] <AfC> igc: then it would be inaccurate to say it's a GNOME app [yes, you said something a bit different, but the point remains]
[04:19] <jam> igc: lp:///~jameinel/bzr-explorer/dialog_for_password
[04:19]  * SamB_XP finds himself looking for the archive button on a google code issue
[04:21] <jam> igc: if you like that, then I'd like to build a 2.0.0-rc2 with your fixes and mine tonight
[04:21] <jam> I could possibly do it early tomorrow am if that works better for you
[04:22] <igc> jam: my today is better - I'm on leave tomorrow :-)
[04:23] <igc> jam: rev 276 has your fix
[04:23] <igc> I'll package 0.8.1 in the next 30 minutes
[04:23] <igc> jam: how late is it there for you?
[04:23] <jam> igc: 11:30pm
[04:25] <igc> jam: ok, I'll package now. Won't take long
[04:28] <jam> igc: well, all *I* need is a tag on your trunk :)
[04:33] <igc> jam: done. The tag is release-0.8.1. The rev is 277.
[04:35] <igc> jam: just double-check buildout pulls down the latest stuff - that's been playing up for me on Windows at least
[04:35] <jam> sure
[04:36] <sidnei> jam, igc: i believe you just need to pass '-n' to the buildout invocation
[04:37] <sidnei> in case it's defaulting to 'newest=false'
[04:41] <igc> thanks sidnei
[04:42] <sidnei> igc: of course setting 'newest=true' in buildout.cfg might be even better
[04:42] <igc> jam: if the installer needs that, can you push the fix?
[04:42] <jam> igc: I can't commit on Kerguelen...
[04:42] <jam> well, I could but I can't push
[04:42] <jam> anyway, for now I can manually update subdirs
[04:42] <jam> but I'll poke at it over the next whil
[04:43] <igc> jam: thanks. I can push the fix if I know it works
[04:46] <lifeless> poolie: I think you may be going off on a tangent, or thinking I am proposing something ugly, or something.
[04:47] <lifeless> poolie: if my reply doesn't sit right, lets talk.
[04:53]  * igc lunch
[04:57] <poolie> lifeless: do you mean about the test base classes?
[04:57] <lifeless> yes
[04:58] <poolie> it may be a tangent if you're not proposing to use this any more than is there at present
[04:58] <lifeless> I'm just proposing to clean up a little of what we have
[04:58] <poolie> ok
[04:58] <lifeless> we have 4 official base classes
[04:58] <poolie> incremental cleanups++
[04:58] <lifeless> I'd like to split things out some more, to 5, or may be 6
[04:58] <lifeless> so they are smaller and more managable
[04:59] <poolie> ok
[04:59] <lifeless> its *easier* to migrate a collection of tests by changing their base class than by other means.
[05:00] <poolie> do you have an example of a particular set of tests where you'd like to make this change?
[05:00] <poolie> biab
[05:01] <lifeless> poolie: no, this comes from looking at the various test support code
[05:06] <poolie> lifeless: back now
[05:08] <lifeless> poolie: I do want to transition to a testresources style thing. If I can convince you to allow the extra dependency, some nice things can be done :)
[05:09] <lifeless> brb
[05:09] <SamB_XP> heh
[05:10] <SamB_XP> what is this, tag-team IRC ?
[05:20] <poolie> lifeless: can you point me to a conflict checker i could run against our ppa?
[05:20] <poolie> and/or run it yourself
[05:38] <lifeless> poolie: https://edge.launchpad.net/conflictchecker
[05:39] <lifeless> poolie: it is probably not what you are looking for though
[05:39] <lifeless> poolie: what sort of issues do you want detected?
[05:39] <poolie> i want to say "could i simultaneously install everything from this ppa?"
[05:39] <poolie> things like bzrtools have a deb-level conflict with bzr
[05:39] <lifeless> ok, its not what you want :)
[05:40] <poolie> is there some other tool?
[05:40] <lifeless> conflictchecker answers 'are things that claim to be concurrently installable concurrently installable' - e.g. 'are the packages lying'
[05:40] <lifeless> I'd write a little one using python-apt
[05:42] <poolie> ok
[05:42] <poolie> or i could just test them in a chroot i guess
[05:43] <lifeless> sure
[05:43] <lifeless> a python apt script would be sufficient I think
[05:43] <lifeless> its that sort of thing it can do very well
[05:45] <AfC> Could write a package that depends on all those things and then get launchpad to attempt to build it?
[05:45] <AfC> [or use that chroot-build-environment I've heard people talking about?]
[05:45] <poolie> afc, that's a nice idea
[05:45] <poolie> the first one
[05:46] <poolie> but if someone then later uploads something that breaks it, i don't think we'll find out
[05:46] <poolie> and ..
[05:46] <poolie> i don't think we'd want it to reject the upload, just to tell us to get back in sync later
[06:06] <AfC> What's a simple (and mean stupid simple, like as in doesn't even exist in Java space) Python web server thingy? I want to do up something as tiny as  `bzr cat | web page` then add a little syntax highlighting and line numbering.
[06:06] <AfC> Any suggestions?
[06:07] <AfC> I could just call `bzr cat` from PHP, but...
[06:08] <lifeless> spiv: where did we put that experiment :P
[06:08] <lifeless> AfC: twisted has a _very_ simple static web server, I don't recall the mojo for it though
[06:08] <AfC> Hm. Now that I think of it, I could use `source-highlight` and just rsync the resultant HTML pages.
[06:08] <AfC> [instead of maintaining a working tree in the target branch on the server]
[06:09] <AfC> lifeless: ok, I'll look there, then [assuming the brute force approach doesn't work]
[06:11] <lifeless> if you want to show bzr stuff though, with source highlighting etc, why not just use loggerhead?
[06:11] <lifeless> bzr serve --http
[06:11] <AfC> um
[06:11] <AfC> that's integrated in bzr's core now?
[06:12] <AfC> bzr: ERROR: no such option: --http
[06:12] <AfC> apparently no
[06:12] <lifeless> you have to install loggerhead
[06:12] <lifeless> but thats how its exposed now, yes.
[06:12] <AfC> lifeless: admittedly I've only used it on Launchpad, but loggerhead has struck me as bloated, slow, and cumbersome.
[06:12] <AfC> s/used/seen/
[06:13] <lifeless> AfC: the lp instance is serving 60K branches or so, many huge or in inefficient formats.
[06:15] <AfC> lifeless: "admittedly ... Launchpad"
[06:15] <AfC> lifeless: so yeah
[06:15] <poolie> igc: around? want to catch up?
[06:16] <AfC> lifeless: though, I must admit the part that it fails on for me is how much work it is to show the work of the people who actually contributed, rather than all the merges by the gatekeeper person / bot
[06:16] <igc> poolie: yep. now is good for me
[06:16] <poolie> k
[06:18] <fullermd> poolie: Does that imply the tarball is being cut?
[06:38] <poolie> it's been cut for a week now
[06:39] <lifeless> 'I'll cut you *****'
[07:01] <fullermd> Eh?  No it hasn't...
[07:04] <fullermd> Oh, you mean rc2.  I mean bzr-2.0.0.tar.gz.
[07:29] <vila> hi all
[07:31] <lifeless> hi vila
[07:31] <vila> poolie, spiv : Does http://paste.ubuntu.com/271887/  rings a bell
[07:31] <vila> hi lifeless
[07:31] <spiv> vila: that does ring a bell
[07:32] <spiv> vila: I dimly recall that was happening to me for a while
[07:32] <vila> just occured on gentoo, can that be related to a timing issue ??
[07:33] <spiv> vila: I guess that it's something like:
[07:33] <lifeless> spiv: oh interesting that pathfilter permitations are testable
[07:33] <lifeless> spiv: +1 on the thing then
[07:34] <spiv> vila: while iterating the transport_list_registry a module import is triggered that registers a new transport, which then causes that error.
[07:35] <vila> spiv: excellent, sounds very likely, now to isolate that...(I will wait for more occurrences anyway)
[07:35] <poolie> fullermd: maybe it's unclear, i meant that 2.0rc2 shouldn't change before final
[07:35] <spiv> lifeless: interesting?  I seem to recall you made the chroot test permutation work in the first place, so it's essentially your work there :)
[07:36] <lifeless> spiv: :)
[07:36] <lifeless> pathfilter != chroot
[07:36] <lifeless> anyhoo go land it ;)
[07:37] <spiv> vila: another possibility, unlikely I hope, is that some errant thread does a transport registration during that iteration...
[07:37] <poolie> vila, i've seen it, not recently
[07:37] <poolie> oh...
[07:37] <spiv> lifeless: thanks :)
[07:37] <vila> poolie: but you couldn't reproduce it right ?
[07:37] <poolie> i don't think it's thread related
[07:37] <poolie> i have fixed one of these, but i can't remember why, sorry
[07:38] <lifeless> probably want to not use iteritems
[07:38] <spiv> A __del__ that triggers a registration somehow (again via an import?) would be another theoretical cause for this to happen intermittently?
[07:39] <poolie> bug 277048?
[07:39] <spiv> It's weird to me that it's intermittent, unless there's something causing dict order to change from run-to-run.
[07:39] <poolie> igc, what was the bug you mentioned on the phone please?
[07:40] <vila> reported by pva ! Our gentoo usual suspect, interesting...
[07:41] <vila> poolie: and threads can be involved as soon as an http 1.1 server is involved
[07:41] <vila> or even any http server
[07:42] <vila> why they should import a transport lately though is another question
[07:42] <lifeless> anyone seen these before:
[07:43] <lifeless> Exception RuntimeError: 'maximum recursion depth exceeded in __subclasscheck__' in <type 'exceptions.RuntimeError'> ignored
[07:43] <vila> lifeless: quite often yes
[07:43] <poolie> yes
[07:43] <poolie> i don't recall why
[07:43] <lifeless> chroot and memory servers register transports
[07:43] <lifeless> they could be the cause of the size change
[07:43] <vila> last I tracked it I seem to recall that it was expected by the test (but I may be wrong)
[07:44] <vila> lifeless: their late registration shouldn't forbid using items() instead of iteritems() though right ? Well, better try than discuss in the wild...
[07:45] <lifeless> vila: items() would be fine
[07:45] <spiv> lifeless: yes, I've seen that, I have no insight into it though.
[07:45] <lifeless> vila: can you arrange for a buildbot slave to run selftest --subunit, once a day?
[07:45] <vila> lifeless: already replied to your mail :)
[07:45] <lifeless> oh cool
[07:46] <vila> yes I can, I also think hudson will give us that for free, but I can still add it temporarily
[07:46] <vila> lifeless: you're ok for a snigle slave to run it right ?
[07:46] <lifeless> yup
[07:46] <lifeless> ideally one without too much noise
[07:47] <lifeless> I want to be able to wget a compressed copy of the log, process it for timing data
[07:47] <lifeless> and e.g. report top 10 culprits, total time etc
[07:47] <vila> well, I tend to consider having a 8-way host as good enough to avoid noise, and it seems to be quite a vliad assumption so far
[07:48] <lifeless> sounds fine to me
[07:48] <vila> at least if it run all days at the same time, the noise should be quite the same
[07:54] <lifeless> EODing, SMS/ping me if needed
[07:57] <igc> poolie: bug 418469
[07:59] <spiv> vila: oh, on that dict size change
[08:00] <spiv> vila: it's a bzr+http test, so there will be a chroot-..:// transport registered by the server thread.
[08:01] <vila> as lifeless hinted just before yes
[08:01] <spiv> Hmm.
[08:02] <spiv> I suppose this means it could happen in production if one thread is creating a chroot (for handling a new connection) while another is doing BzrDir.open.
[08:03] <spiv> Which wouldn't be an issue for bzr serve TCP or bzr serve --inet, but some forms of HTTP deployment could theoretically do that.
[08:03] <vila> spiv: hmm, looks like you're on the right track to write a reproducing test :D
[08:03] <spiv> vila: it's getting late in the day here, why don't you do it?  ;)
[08:03] <vila> spiv: I just receive another more problematic test failure :-)
[08:04] <spiv> Lucky you! :)
[08:04] <spiv> I'll file a bug, at least.
[08:04] <vila> poolie: http://paste.ubuntu.com/271900/
[08:04] <poolie> vila :/
[08:05] <poolie> can we get it to compile the extensions?
[08:05] <vila> spiv: kidding, that sounds a bit complicated to set up, but I was about to send a submission s/iteritems/items/ based on the discussions here
[08:05] <poolie> it's a bit gross it fails like this without them
[08:05] <vila> poolie: jam asked for tests without extensions, it's not even occurring then...
[08:05] <poolie> oh ok
[08:06] <vila> we say we support running without extensions
[08:06] <poolie> sure, so we should pass tests without them
[08:06] <poolie> file a bug, assigned to me?
[08:06] <poolie> i thought we'd have some fallout there
[08:07] <vila> it's triggered by leopard again because the laptop sleeps at night (lazy guy) and run the build in the morning with a more recent bzr.dev
[08:07] <vila> which certainly means that I will get a fully red botnet tomorrow if not fixed...
[08:08] <vila> poolie: tell you what, I fix that one and you review the shell-like tests  ? :D
[08:08] <poolie> :)
[08:08] <poolie> deal
[08:08] <vila> YES
[08:08] <poolie> i'm sending things of mine already approved
[08:09] <poolie> hopefully after that
[08:09] <poolie> oh i need to file one more bug too
[08:10] <igc> poolie: can I email bzr-windows asking for testers on the new installer?
[08:10] <poolie> of course, why not?
[08:10] <lifeless> hmm, ~ 500 tests that read from the local filesystem - aren't properly isolated.
[08:10] <igc> poolie: and maybe put up a wiki page collecting test status across various windows versions?
[08:11] <igc> poolie: well, we're yet to announce 2.0.0rc2
[08:11] <poolie> well, probably we should ask for testing before the announcement
[08:12] <igc> polie: ok, sounds good
[08:12] <igc> poolie: I'll email now
[08:12] <poolie> lifeless: we should try to get apport and subunit and maybe other things into the pqm chroot
[08:12] <poolie> or is there already an rt?
[08:12] <lifeless> theres an rt on subunit aready
[08:13] <poolie> still waiting?
[08:13] <vila> mwhahahah: * Don't call iteritems on transport_list_registry, because it may
[08:13] <vila>   change during iteration.  (Martin Pool, #277048)
[08:14] <vila> Except that the underlying implementation still use iteritems(), oh the irony....
[08:15] <spiv> vila: yeah
[08:16] <vila> I'm not throwing stones, I was just choked to follow the track and... wtf ???
[08:16] <spiv> vila: fundamentally I think Registry should cope better here (by not using self._dict.iteritems()); https://bugs.edge.launchpad.net/bzr/+bug/430509
[08:16] <vila> I was about to do exactly the same...
[08:16] <mtaylor> lifeless: are you waiting on me for anything these days?
[08:17] <vila> #430510 sorry spiv I didn't realize you were filing it :-/
[08:17] <spiv> Heh.
[08:18] <vila> I was about to use list(registry.items()) for transport though, I think deprecating iteritems() is excessive...
[08:19] <vila> In principle we should favour iteritems(), we found an exception, I'd prefer handling the exception that changing a good rule, objections ?
[08:21] <poolie> vila:heh
[08:21] <poolie> i think it's a bit bogus that we're registering and deregistering things this way
[08:21] <lifeless> mtaylor: autoconf archive pandora cleanups;
[08:21] <lifeless> mtaylor: not panicly
[08:21] <mtaylor> lifeless: k. cool
[08:21] <poolie> like why can't memory be memory://1234/aothuetue
[08:22] <lifeless> poolie: huh? thats what the registration does
[08:22] <spiv> lifeless: not quite
[08:22] <lifeless> poolie: the alternative is memory etc to all manage their own registration of live servers
[08:22] <poolie> i think some of them register new schemes not new hosts
[08:22] <poolie> imbw
[08:22] <spiv> lifeless: it registers memory-1234:///....
[08:22] <lifeless> spiv: sure, 6-of-1 though, they are all prefixes ;P
[08:23] <spiv> lifeless: we could perhaps just have memory:/  registered, and then have a separate MemoryServer registry with the netlocs as the keys.
[08:23] <lifeless> I think what we do is elegant and reuses the code
[08:23] <lifeless> rather than duplicating effort
[08:23] <spiv> But that does shift the same problem to that secondary registry.
[08:24] <lifeless> poolie: yes there is an rt for subunit, not for apport, and its in progress (something about needing a dapper package..)
[08:24] <vila> spiv, lifeless, poolie : quite likely the bug will not trigger in that case, but anyway, I don't think a single exception is enough to require separating very similar intents
[08:28] <vila> pfffff
[08:28] <vila> Conflict: can't delete doc/en/developer-guide because it is not empty.  Not deleting.
[08:28] <vila> poolie: now I understand your question from yesterday...
[08:28] <poolie> that's it :)
[08:28] <poolie> i think that's a sore point for jml, and some other users
[08:31] <vila> but we still haven't decide how to address IIRC, we can't just delete HACKING.html there
[08:31] <poolie> vila: i think most ignored files are safe to delete
[08:31] <poolie> i think most of the time that's what people want
[08:31] <vila> "think" and "most" ... twice.... :D
[08:31] <poolie> possibly the other cases could be handled by moving them to either a backup file in a parent directory
[08:32] <poolie> or say .bzr/trash
[08:32] <vila> yeah, right ! Far better
[08:32] <bialix> hi guys
[08:32] <bialix> bonjour vila
[08:32] <poolie> hi bialix
[08:32] <vila> hello bialix
[08:32] <poolie> or should i say privet?
[08:32] <garyvdm> Hi all
[08:32] <poolie> hi garyvdm
[08:32] <igc> hi vila, bialix, garyvdm
[08:32] <bialix> vila: I'll leave my chatzilla working as you teach me
[08:32] <vila> bialix: hurrah !
[08:32] <vila> :D
[08:32] <bialix> but may be will not answer instantly
[08:33] <vila> welcome to our 24/7 online world :)
[08:33] <bialix> poolie: privet-privet
[08:33] <vila> bialix: sure
[08:33] <spiv> poolie: moving to a lost+found-ish directory sounds good to me; as you say often you just want to delete them so a single dir you can rm -r would be good.
[08:33] <bialix> poolie: hi is fine too
[08:33] <bialix> hi garyvdm, igc
[08:33] <bialix> vila: I don't promise 24/7
[08:33] <vila> bialix: I was joking :D
[08:33] <bialix> ah
[08:34] <bialix> nice
[08:34] <spiv> poolie: I actually think a dir in the working tree root, rather than in .bzr, would be good
[08:34] <bialix> jam is flloding qbzr with bug reports!
[08:34] <poolie> .bzr-trash?
[08:34] <spiv> poolie: because we don't want to train poeople to dig in .bzr to find their files
[08:34] <bialix> garyvdm: did you see this?
[08:34] <poolie> +1
[08:34] <poolie> bialix: jam is doing some commercial training this week
[08:34] <poolie> and i guess getting a lot of feedback
[08:34] <garyvdm> bialix: Yip
[08:34] <bialix> poolie: that's nice
[08:34] <garyvdm> poolie: Thats cool
[08:35] <bialix> poolie: getting feedback is cool
[08:35] <bialix> poolie: unfortunately we can't fix all this bugs as quickly as jam reported them
[08:35] <vila> spiv, poolie : remember the bug number where we can add these useful remarks ?
[08:35] <spiv> I'm not sure that hidden-by-default is even necessary, why hide the junk?  I don't, though...
[08:35] <garyvdm> poolie: Knowing software that you have written is being used is coll!
[08:35] <spiv> vila: one with a low number, IIRC ;)
[08:36] <poolie> it is good
[08:36] <poolie> about directory conflicts?
[08:36] <spiv> vila: I'm off; happy bug-squashing!
[08:36] <poolie> nup
[08:36] <vila> #102001 ?
[08:37] <poolie> i was thinking about a crusade against four-digit bugs
[08:37] <poolie> it'd be a bit arbitrary
[08:37] <poolie> some are still marked inprogress though
[08:37] <poolie> vila, ok, really reading it now
[08:38]  * vila enters bersek mode
[08:38] <vila> bug #102001
[08:38] <vila> Hello ubottu ?
[08:39] <vila> bug #344013 too and may be more directly related
[08:53] <bialix> how it's possible that jam filed bug report which is not bug report?
[08:53] <vila> bialix: you'll have to explain a bit more here :)
[08:54] <bialix> jam said that quncommit works wrong while it works as plain uncommit
[08:54] <bialix> vila: it was rhetorical question actually. I simply can't believe
[08:54] <vila> ha, that kind of  'not' :-) ok
[08:55] <bialix> kind of 'nbot'?
[08:55] <bialix> kind of 'not'?
[08:55] <vila> bialix: that's why there is a "Won't fix" option :)
[08:55]  * bialix perhpas looks stupid
[08:55] <bialix> actually I've used Invalid
[08:55] <vila> you said "is not bug report" I imagined you received a mail but couldn't find it back on lp...
[08:56] <vila> so "not" a real bug report
[08:56] <bialix> wow, what a wonderful bug Bug 430382
[08:57] <bialix> and why there is no tree.conf???
[09:11] <poolie> vila, review sent
[09:11] <vila> thanks
[09:12] <poolie> it's looking good but i have some questions
[09:12] <vila> expect another one shortly then :)
[09:21] <vila> poolie: right, so some answers are based on usage in my conflict-handling branch, where I have ~20 tests using ~20 scripts,
[09:21] <vila> poolie: overall that's a needs fixing as in resubmit right ?
[09:21] <poolie> pretty much
[09:21] <poolie> obviously you're welcome to answer the questions other than by changing the code
[09:22] <poolie> like if experience in using it has shown you that it works best as it is
[09:22] <vila> sure, I intend to for some parts giving explanations why
[09:22] <vila> exactly, separating output and errors, not checking output by default are two such examples
[09:24] <garyvdm> poolie: As you are the author of Merge3, I think you are the best person to ask this. :-)
[09:24] <garyvdm> poolie: http://paste.ubuntu.com/271945/ - Why does that result in a conflict?
[09:25] <poolie> i forget what the argument order is
[09:25] <poolie> is it base, a, b?
[09:25] <garyvdm> yes
[09:25] <garyvdm> I would expect the result to be ["c"]
[09:28] <poolie> hm
[09:29] <poolie> maybe it should be
[09:29] <poolie> the basic idea is, this is a region that has changed, they disagree, therefore it conflicts
[09:29] <poolie> this might be a place where reprocessing will trim it down
[09:29] <poolie> perhaps it's more reasonable to say there are actually conceptually two regions here
[09:29] <garyvdm> poolie: but it should be 2 regions?
[09:29] <garyvdm> yes
[09:29] <poolie> [a, b] => [a, b] | []
[09:30] <poolie> and [] => [c] | []
[09:30] <garyvdm> yes
[09:30] <poolie> it would be interesting to try it at least
[09:31] <poolie> i think i'd like to find a case where this occurred in real code
[09:31] <poolie> does it only happen when one side is empty entirely?
[09:31] <poolie> and how far do you take it?
[09:32] <poolie> [a b c] => [a x b y c z] | []
[09:32] <poolie> it would be a bit of a stretch to say that should be [x y z]
[09:32] <garyvdm> yes
[09:32] <poolie> are you looking at a real case?
[09:32] <garyvdm> This is where I encounter it: I'm hacking qcommit to requery generate_commit_message_template when the file selection changes.
[09:33] <garyvdm> "a", "b" = the base message
[09:33] <garyvdm> The user (me) added "c"
[09:34] <garyvdm> Then unchecked debian/changelog
[09:34] <garyvdm> so the new message from generate_commit_message_template = []
[09:36] <poolie> right, interesting
[09:37] <poolie> this is a bit like some conflicts i see where one side has deleted a test (or other method), and another has added a new test just after it
[09:37]  * garyvdm tries with reprocess=True
[09:37] <poolie> clearly you want to keep the addition and keep the deletion
[09:38] <garyvdm> reprocess=True dose not help
[09:38] <igc> night all
[09:39] <igc> I'll be offline a few days so see you all next week
[09:39] <garyvdm> igc: Have a good rest!
[09:39] <igc> thanks garyvdm!
[09:41] <bialix> garyvdm: can we use our own templates for qcommit?
[09:41] <bialix> igc: bye
[09:41] <philn> hi
[09:42] <garyvdm> bialix: ?
[09:42] <philn> quicky one: on win32, how can i import bzrlib?
[09:42] <philn> i have bzr installed system-wide
[09:42] <garyvdm> philn: how did you install bzr?
[09:42] <bialix> garyvdm: some people like vila often use list of changed files in commit message with some specific commetns
[09:43] <bialix> philn: are you using bzr.exe installer?
[09:43] <bialix> aka standalone installer?
[09:43] <philn> bialix: err, don't remember
[09:43] <philn> how can i check?
[09:43] <bialix> show me output of `bzr version`
[09:43] <bialix> pastebin it
[09:43] <poolie> garyvdm: it's definitely worth filing a bug on it
[09:44] <bialix> philn: but more importantly: why you want import bzrlib?
[09:44] <poolie> tagged conflicts
[09:44] <garyvdm> poolie: ok - Thanks
[09:44] <philn> http://pastebin.com/m606b7b23
[09:44] <garyvdm> bialix: He could write a plugin that implements a commit_message_template hook. When I have finished my hack, it will also work with qcommit.
[09:44] <philn> bialix: i need it to call bzr commands from a python script
[09:45] <bialix> philn: you have bzr.exe install, and very old (1.12)
[09:45] <philn> i don't use that box daily, hopefully ;)
[09:45] <bialix> philn: you either should install python-based version, see corresponding installers for your python version
[09:45] <bialix> philn: what is your python version?
[09:46] <philn> 2.5.2 ;)
[09:46] <bialix> philn: are you one of that win32-haters?
[09:46] <garyvdm> bialix: can't you add "C:\Program Files\Bazaar\lib\library.zip\bzrlib" to sys.path
[09:46] <philn> hater no, but i'm not a lover either
[09:47] <bialix> philn: install bzr from corresponding specific to 2.5 installer
[09:47] <bialix> garyvdm: you can
[09:47] <bialix> I mean *you* can
[09:48] <garyvdm> bialix: Why won't that help philn?
[09:48] <bialix> philn: use this installer http://launchpad.net/bzr/1.18/1.18.1/+download/bzr-1.18.1-1.win32-py2.5.exe
[09:49] <bialix> garyvdm: it might help
[09:49] <philn> my python is not installed system-wide, it is part of the big deps environment we use
[09:50] <garyvdm> philn: try this then http://paste.ubuntu.com/271959/
[09:53] <philn> garyvdm: yep, works
[09:53] <philn> ok, so i can work with a try/except
[09:54] <philn> thx
[09:54] <garyvdm> :-)
[09:54] <bialix> I don't recommend to hardcode C:\Program Files\Bazaar\lib\library.zip path there
[09:54] <bialix> you can read actual path from registry
[09:55] <bialix> on installation we wrote under HKLM\SOFTWARE\Bazaar\2.0 its InstallPath
[09:56] <philn> err, okay
[10:02] <philn> i don't have that "2.0" .. my bzr is really very, too oold ;)
[10:04] <bialix> philn: and what you have?
[10:05] <bialix> maybe 2.0 is unneccasary, I may forget some details
[10:05] <philn> HKLM\SOFTWARE\Bazaar
[10:07] <bialix> OK
[10:07] <bialix> so use it
[10:07] <bialix> is there InstallPath available?
[10:07] <philn> yes
[10:08] <philn> i'll ask people in the office to test...
[10:08] <bialix> InstallPath should be C:\Program Files\Bazaar
[10:09] <bialix> you just need os.path.join(InstallPath, 'lib\\library.zip')
[10:09] <jszakmeister> jelmer: just a quick question for you... bzr-svn doesn't need the bzr: revprops for anything right?
[10:09] <philn> it is on my machine yes
[10:09] <jszakmeister> I mean it doesn't break anything not to have them, and doesn't interefere with the operation of bzr-svn at all?
[10:10] <jszakmeister> Or does it limit you in some way if they're missing?
[10:11] <bialix> garyvdm: finished to triage bugs, oh
[10:11] <garyvdm> bialix: cool.
[10:12] <bialix> jam is just like a bomb
[10:12] <bialix> exploding
[10:13] <garyvdm> bialix: lp:~garyvdm/qbzr/read_commit_message_hook/
[10:14] <garyvdm> bialix: I need to work on how it merges things...
[10:14] <bialix> merges things?
[10:14] <bialix> sorry, I'm in dumb mode today
[10:14] <bialix> garyvdm: sorry, I probably won't have a time to seriously looking at your branch till evening
[10:14] <garyvdm> When you change the file selection, it updates the template
[10:15] <garyvdm> bialix: cool. just for your information.
[10:15] <bialix> ok, thanks
[10:15] <bialix> ETTOMUCHSTUUF here
[10:15] <garyvdm> vila may be interested :-)
[10:15] <bialix> rats
[10:15] <bialix> hate when typos ruined the joke (c) vila
[10:16] <garyvdm> bialix: err - I know how feel.
[10:16] <vila> bialix: :-)
[10:18] <vila> garyvdm: I'm already bit overcommitted today :-/ Is that a merge proposal ?
[10:19] <garyvdm> vila: no - something that will scratches and itch you have...
[10:19] <vila> which one ?? :)
[10:19] <garyvdm> vila: It makes qcommit get commit message templates
[10:20] <garyvdm> And it updates it when you change the file selection.
[10:20] <garyvdm> So we can me a commit message template that contains the list of files to be commited.
[10:20] <garyvdm> Vila: which Alex said you often use...
[10:21] <vila> ooh, not an itch of mine then :-) I use a different workflow: I prepare my commit message in a file in advance, sometimes I even revert/merge/shelve/do crazy stuff, while still retaining my file with the commit message
[10:22] <vila> diff /diff -rsubmit:/commit are actions I do from emacs and the integration here fully fill my needs, so I'm a really hard sell for qcommit :) (or gcommit or whatever for that matter)
[10:23]  * fullermd . o O ( ecommit )
[10:23] <jszakmeister> I love qcommit.
[10:24] <jszakmeister> I haven't tried the commit message templates though... I really should.
[10:24] <vila> fullermd: I use DVC for that matter and my "file" is ChangeLog :)
[10:25] <fullermd> Yeah, DVC means something very different to me probably   :p
[10:26] <philn> thx for the help
[10:27] <vila> fullermd: it's an emacs package in my case the acronym being... Distributed Version Control indeed :)
[10:28] <fullermd> Yeah, I read it and think Diligentia, Vis, Celeritas   :p
[10:44] <vila> fullermd: oh, in that sense, yeah, that's so me :-D
[10:53] <lifeless> slowest tests today:
[10:53] <lifeless> bzrlib.tests.test_bundle.V4WeaveBundleTester.test_last_modified 25.085
[10:53] <lifeless> bzrlib.tests.test_bundle.V09BundleKnit2Tester.test_bundle 30.755
[10:53] <lifeless> bzrlib.tests.test_bundle.V4WeaveBundleTester.test_bundle 39.020
[10:53] <lifeless> bzrlib.tests.test_source.TestSource.test_no_asserts 54.165
[10:53] <lifeless> bzrlib.tests.test_hashcache.TestHashCache.test_hammer_hashcache 69.739
[10:55] <fullermd> I guess that counts as hammering it...
[10:58] <vila> lifeless: and the later is timing dependant (I got a failure yesterday or the day before)
[11:00] <SamB_XP> vila: have you had any issues with DVC ?
[11:01] <vila> lifeless: http://paste.ubuntu.com/271990/
[11:01] <vila> SamB_XP: apart from making it available to all my VMs without installing and recompiling ?
[11:01] <vila> SamB_XP: no :)
[11:02] <SamB_XP> 'kay.
[11:02] <vila> SamB_XP: well, I lied.
[11:02] <SamB_XP> 'cause if you were, I was going to ask you to file bugs ;-)
[11:02] <vila> I had some problems, but I'm so used to work around them that I forget what they were
[11:02] <SamB_XP> lol
[11:02] <SamB_XP> typical
[11:03] <vila> SamB_XP: But you're right, I should file them when I recall
[11:03] <SamB_XP> maybe it wasn't taking bugs on launchpad last time you tried ;-)
[11:04] <vila> SamB_XP: Certainly the biggest one is that the diff mode doesn't include the status mode, so I still ends up forgetting to add some files
[11:04] <vila> SamB_XP: I started using DVC when I started using bzr, so neither of them used lp for bug tracking at that time I think :)
[11:05] <vila> lifeless: http://paste.ubuntu.com/271990/
[11:05] <SamB_XP> the former could be said of me, but the latter could not
[11:05] <vila> lifeless: sorry, thought I didn't paste that :-/ Low glycemy (sp?) , lunch time :
[11:05] <SamB_XP> though it would be more accurate to put it the other way 'round
[11:06] <vila> SamB_XP: you lost me there :)
[11:06] <SamB_XP> I started using bzr when I started using DVC ;-)
[11:06] <vila> Oh, I see
[11:07] <SamB_XP> and the dvc launchpad project wasn't accepting bugs, and there wasn't really anywhere else to send them but the DVC mailing list ...
[11:07] <SamB_XP> which wasn't all that easy to find, either, iirc ;-)
[11:07] <vila> SamB_XP: I remember your arrival :)
[11:07] <lifeless> vila: it shouldn't fail though; what platform/fs was that on?
[11:08] <vila> lifeless: karmic happened only once
[11:08] <SamB_XP> did the test time out from being so slow ?
[11:09] <lifeless> vila: what file system?
[11:10] <vila> lifeless: ext4
[11:10] <SamB_XP> !!!
[11:10] <SamB_XP> why that ?
[11:10] <vila> err, wait, no /tmp right ?
[11:10] <vila> so tmpfs
[11:10] <SamB_XP> only crazy people use that, I thought!
[11:10] <SamB_XP> like ext[234] devs
[11:11] <vila> lifeless: errr, maybe not, let me check the dates
[11:11] <vila> I just recently switch to a real mptfs for the karmic VM
[11:12] <vila> lifeless: right, it was still ext4
[11:16] <NET||abuse> hey guys. i have a project i'm versioning with bzr on my laptop(ubuntu), bit i have some image work i'm doing on a windows machine (bloody flash and photoshop requirements) so i wanted to checkout the branch onto the windows machine and then commit and push images and swf's back up into the linux laptop
[11:16] <NET||abuse> how do i branch from linux to windows?
[11:17] <NET||abuse> ssh+bzr:// doesn't work in the bzr interface on windows :)
[11:18] <NET||abuse> nevermind, gotit
[11:19] <NET||abuse> ahh, ok, next question, how do i avoid having to enter my ssh password 7 times.
[11:19] <garyvdm> authentication.conf
[11:22] <vila> NET||abuse: use an ssh agent
[11:22] <vila> garyvdm: authentication.conf doc states that the aim is *not* to replace ssh agents which are: 1) better suited, 2) more secure :-D
[11:23] <NET||abuse> ok,, putty an ssh agent?
[11:23] <vila> NET||abuse: I can never remember :-/
[11:25] <NET||abuse> boy, my bzr usage is a little fuzzy,, i added an image from a tmp directory, the tmp directory is needed but the jpg's in it are not.. can i just add jpg's to the .bzr/.ignore file?
[11:25] <NET||abuse> or where is the ignore file usually located?
[11:25] <NET||abuse> or what is the right way to remove the already added random images from being tracked and then ignore them?
[11:32] <jszakmeister> jelmer: Another quick question... what if my layout has multiple tag areas?  For instance, a number of our projects have both tags/ and releases/ where the latter has only tags that correspond to official releases.
[11:32] <jszakmeister> And more specifically: what happens when I say to tag something from Bazaar?  How does it know which location to record the tag?
[11:44] <NET||abuse> hmm, i branched / checkedout from a remote bzr location in windows, and bzr isn' showing it as a bzr tracked tree
[11:49] <NET||abuse> hmm, i am confused, on command line i can manage the branch on the windows machine, i guess the explorer shell extension just isn't working.
[11:50] <NET||abuse> well, i added the image i wanted to the branch, and commited, it asked me for ssh login to commit so i was thinking is it commiting directly back to the linux machine?
[11:50] <NET||abuse> or how do i get the image into the linux bzr repo?
[11:51] <NET||abuse> hmm, ok, even doing bzr st on the local windows branch directory required ssh login.
[11:51] <NET||abuse> what have i done here?
[11:55] <vila> NET||abuse: start with 'bzr info'
[11:56] <NET||abuse> that also required ssh login.
[11:56] <vila> whether you use a standalone branch or a checkout will lead to different behavior, you have to learn them both if you want to use them both
[11:58] <NET||abuse> ah, ok
[11:59] <NET||abuse> it says Standalone tree       push branch: master      parent branch : bzr+ssh://route_to_mylinuxbox     stacked on: bzr+ssh://route_to_mylinuxbox
[11:59] <NET||abuse> on the linux box bzr info shows Satndalone tree,   location branch root: /home/me/devel/site.com/src
[12:00] <NET||abuse> so what's happening,, the image doesn't seem to appear on my linux machine.
[12:01] <NET||abuse> bzr st on windows says unkown: master/
[12:01] <NET||abuse> i may have bzr push master by mistake to try getting it up to the linux box, but that was a mistake.
[12:02] <gabriel_> hiya
[12:03] <gabriel_> i've been trying to get bzr working over smbfs...
[12:03] <gabriel_> Permission denied: "lock/uogwua8c74.tmp/info": [Errno 13] Permission denied: '/media/henry/dev.www.windsor-telecom.co.uk/.bzr/branch/lock/uogwua8c74.tmp/info'
[12:03] <gabriel_> any help would be great!
[12:14] <NET||abuse> hmm, i find that weird, that you should bzr init-repo dirname   before branching from somewhere else..??
[12:15] <NET||abuse> would the act of branching from somewhere else not make the destination of the branching operation an active repo no?
[12:15] <Daviey> Hi, is it possible to have many local commits, but then when pushed elsewhere fold them to a single changeset?
[12:18] <NET||abuse> it should be..
[12:18] <NET||abuse> i heard that you can do that when folding commits into an svn commit.
[12:19] <Daviey> NET||abuse: i can't think how to, without a wrapper scrip
[12:19] <NET||abuse> one sec,, have to read the docs on commiting to svn from local bzr branch.
[12:21] <Daviey> Thanks.
[12:22] <lifeless> vila: would be good to know if we can trigger that failure on ext4
[12:22] <Daviey> The only way i could think, was to bzr diff to upstream branch revision, then bzr revert to that, then apply the diff and recommit
[12:22] <NET||abuse> i'm still working on how to push my change back up to the linux box.
[12:22] <lifeless> vila: Its possible either ext4 is breaking one of our assumptions, or has a bug.
[12:22] <NET||abuse> i've redone the whole seutp, according to the sharing-with-peers workflow guide
[12:23] <NET||abuse> i did init-repo, then branched from my linux repo over bzr+ssh://   did my local commit, even did a merge on the windows box.. but that doesn't push the changes back up to the linux machine.
[12:23] <NET||abuse> how do i get the code back up to the linux machine?
[12:37] <NET||abuse> Daviey, try reading though the http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#bzr-svn   section of docs on commit style up to svn, it may be parallel when working with centralized bzr repo ?
[12:49] <jam> garyvdm: I think what you are asking about is what "--reprocess" gives
[12:49] <jam> but I don't think Merge3 directly supports it?
[12:49] <garyvdm> Hi jam. I was very intrested to read about your demo.
[12:51] <garyvdm> jam: I don't think reprocess would do what I want. I think I'm going to have to write a custom version of Merge3.find_sync_regions
[12:51] <vila> lifeless: 1) it occurs only once 2) I may add an additional build specifically for ext4 3) but given that using tmpfs didn't provide the expected benefits, I may as well revert that change so karmic always run on ext4
[12:53] <jam> garyvdm: it works in text files...
[12:53] <vila> garyvdm: be sure to respect alphabetical order in NEWS sections (I just fixed one in bzr.dev)
[12:54] <vila> morning jam !
[12:54] <garyvdm> vila: Did I make a mistake?
[12:54] <garyvdm> vila: alphabetical order *with in* NEWS sections?
[12:54] <jam> garyvdm: http://paste.ubuntu.com/272053/
[12:55] <jam> hi vila
[12:55] <vila> look at lp:~vila/bzr/integration
[12:55] <vila> garyvdm: to reduce the potential conflicts there
[12:58] <garyvdm> jam: In your example, base=[] this=[ab] other=[abc]. My example was base=[ab] this=[abc], other= []
[12:59] <jam> garyvdm: .... then that should conflict for the hole region...
[13:00] <jam> but ... ok
[13:00] <garyvdm> jam: should be 2 regions...
[13:01] <garyvdm> [ab], [ab], []
[13:01] <jam> garyvdm: i disagree
[13:01] <garyvdm> [], [c], []
[13:01] <jam> but I can see how you would want that
[13:01] <garyvdm> base, this, other
[13:01] <jam> garyvdm: consider how that would look in a real file
[13:02] <garyvdm> jam: Yes - I think for how I want to use it, it is a special use case.
[13:02] <jam> garyvdm: http://paste.ubuntu.com/272059/
[13:03] <garyvdm> jam: This is for automatically updating the message template in qcommit. (https://code.edge.launchpad.net/~garyvdm/qbzr/read_commit_message_hook)
[13:04] <garyvdm> jam: I plan to have it automaticly use the text from THIS where there are conflicts.
[13:04] <garyvdm> jam: hence my conclusion that I am going to have to write a custom version of Merge3.find_sync_regions...
[13:07] <garyvdm> jam: Anyway, if it split it up into 2 regions, then the result would be [c], with no conflicts, not like http://paste.ubuntu.com/272059/
[13:11] <jam> garyvdm: merging is a bit of an art, but there is an argument that deleting a and b should conflict with the insertion of c
[13:11] <jam> if you consider the actions as their "edges" or the pairing of a line with the previous and next line
[13:11] <garyvdm> jam: Yes
[13:11] <jam> with extra 2 "lines" for the beginning of file and end of file
[13:12] <jam> I realize that for your specific case, you may not want that
[13:13] <NET||abuse> hmm, ok i've a checkbox on a list of db entries,, the html is <input class="pressactivecheckbox" type="checkbox" checked="checked" name="active" rel="7"/>    i want to do an ajax request to set the value 1 or 0 in the db, this is the jquery i'm trying to use.. http://paste.pocoo.org/show/140038
[13:13] <NET||abuse> at the moment it is showing undefined for the checkboxes rel attribute
[13:13] <NET||abuse> i tried it as just this.rel when building ajurl   and got the same.
[13:14] <muffinresearch> Quick question does anything exist in terms of commit hooks on a bound central repo? I have a need to set something up to watch for changes on a centralised repo.
[13:14] <NET||abuse> what am i doing wrong here?
[13:14] <garyvdm> NET||abuse: I think you got the wrong channel. You are in #bzr atm...
[13:14] <NET||abuse> garyvdm, hahahah oh god, i am and all,, cheers ;)
[13:15] <NET||abuse> :P
[13:15] <garyvdm> muffinresearch: Yes - but you need to think about weather you want it to fire server side, or client side.
[13:16] <garyvdm> muffinresearch: post_change_branch_tip
[13:16] <garyvdm> muffinresearch: you can see the list of hook by running bzr help hooks
[13:18] <garyvdm> muffinresearch: post_change_branch_tip
[13:18] <garyvdm> muffinresearch: you can see the list of hook by running bzr help hooks
[13:18] <garyvdm> muffinresearch: If you are not running a bzr server, then it will have to be client side.
[13:28] <muffinresearch> garyvdm: yep I'd be looking for this to run from the server
[13:29] <muffinresearch> garyvdm: ok thanks for the pointers - cheers
[13:30] <vila> fullermd: mwhaaaaaa, Fatal trap 12: page fault while in kernel mode
[13:33] <fullermd> vila: That'll teach ya.
[13:34] <vila> fullermd: I don't mind rebooting, just wanted to know if it was worth reporting and how ?
[13:34] <vila> fullermd: given that I have no idea about how to reproduce....
[13:35] <fullermd> Well, it Shouldn't(tm) happen.  Did it dump a core or anything?  Just the panic message usually doesn't tell too much by itself, though the IP could be poked at maybe.
[13:35] <vila> fullermd: but noting that the VM is spinning on the 4 virtual cores like hell (like it does when halt'ing), which is really bad taste in a VM :)
[13:35] <fullermd> (think dumps might be off by default)
[13:36] <fullermd> (in b4 I mean)
[13:57] <maco> i did "bzr init" and "bzr add" on some files in a directory and have worked on them and commited a few times. i just realized i should've done it one directory up. is there a way to move the root of it?
[13:59] <muffinresearch> Having had more of a read of the docs it's not clear where I could put a plugin so that it can be "seen" by bzr smart server when using bzr+ssh://
[14:02] <muffinresearch> Aha looks like I might be able to use bzrlib/plugins
[14:16] <jam> well, I'm off to work, see you all in the evening (they block IRC)
[14:30] <Pilky> is there a reason smart_add() will accept absolute paths but commit() doesn't seem to want to?
[15:54] <Pilky> *sigh* now it seems I can't get smart_add() to accept relative paths
[15:55] <Pilky> anyone around who can tell me why if I have a working tree called wt
[15:56] <Pilky> wt.has_filename("somefile.txt") returns true
[15:56] <Pilky> but wt.smart_add(["somefile.txt"]) gives a PathNotChild exception
[15:57] <james_w> why not use wt.add() ?
[15:58] <Pilky> I was under the impression wt.add() required more work
[15:58] <Pilky> eg recursing yourself into directories
[15:58] <james_w> it does
[15:58] <james_w> my guess is that wt isn't rooted at your cwd
[15:59] <james_w> and the path is taken relative to your cwd, and so isn't seen as being in the wt
[15:59] <Pilky> ah
[16:00] <Pilky> yeah
[16:00] <Pilky> I hate dealing with command line stuff sometimes
[16:00] <Pilky> james_w: thanks
[16:12] <Pilky> james_w: can you then think why wt.commit() would work with relative but not absolute, no matter what the cwd?
[16:13] <Pilky> I get a PathsNotVersionedError
[16:13] <james_w> not too sure
[16:13] <james_w> not *smart*_add
[16:13] <james_w> so I wouldn't be surprised if it worked differently to everything else
[16:13] <james_w> but I'm not sure what would make commit not like absolute paths at all
[16:17] <Pilky> well bzr itself seems to handle it, guess I'll have to have a look at the source
[17:13] <naoki_> Good evening.
[17:13] <naoki_> I'm trying bzr-2.0rc2
[17:13] <naoki_> I faced error "bzr: ERROR: Cannot commit from a lightweight checkout to a stacked branch."
[17:15] <naoki_> I just use a stacked branch and didn't use lightweight checkout.
[17:15] <naoki_> Is this intended behavior?
[17:15] <naoki_> What I did:
[17:16] <naoki_> bzr init foo
[17:16] <naoki_> bzr branch --stacked foo bar
[17:16] <naoki_> cd bar
[17:16] <naoki_> echo foo > foo.txt
[17:16] <naoki_> bzr add foo.txt
[17:16] <naoki_> bzr commit
[17:17] <fullermd> Does it work if you make a rev in foo before you branch bar from it?
[17:18] <naoki_> doesn't
[17:19] <fullermd> Shucks.  I woulda looked real smart if it had...
[17:19] <naoki_> I'm trying bzr-2.0rc2-2-setup.exe on WinXP SP3.
[17:21] <naoki_> http://paste.ubuntu.com/272229/
[17:23] <naoki_> and -Derror
[17:23] <naoki_> http://paste.ubuntu.com/272231/
[20:12] <phinze> so maybe someone can help me figure out if i understand this correctly: if i make a commit that becomes r4 and then a commit that becomes r5 in a task branch, and i realize that though the task branch is off 'feature-foo' branch that r4 should really get merged back into 'trunk'
[20:12] <phinze> since i have another commit sitting on top of r4 that does *not* belong in 'trunk' yet
[20:12] <phinze> my only option is a dumb cherry pick (i.e. no knowledge of merge source)?
[20:13] <LarstiQ> no, you can merge up to r4
[20:14] <LarstiQ> phinze: the other way around you would be right, r5 needs to be in trunk but r4 not
[20:14] <phinze> but since the task branch has many changes from 'feature-foo' branch won't those all come in with the merge?
[20:16] <LarstiQ> ah, yes
[20:16]  * LarstiQ missed that in the description
[20:16] <phinze> so i am stuck with just diff/patch for grabbing those changes, eh
[20:16] <phinze> since the cherry-picking use case in bzr doesn't do much more than that for me at this point
[20:17] <phinze> is that accurate?
[20:19]  * phinze reads bzr wiki CherryPick and DaggyFixes article linked from there
[20:19] <LarstiQ> phinze: hmm, I really wouldn't use diff/patch
[20:20] <phinze> LarstiQ: well, i suppose i meant 'bzr diff -c4'/patch
[20:20]  * LarstiQ would really just use `bzr merge`
[20:21] <phinze> fair, but in this particular use case, it wouldn't gain me anything functionally?
[20:21] <LarstiQ> for one thing, it would gain you using the same interface
[20:22] <fullermd> diff/patch do poorly at dealing with renames, and will fail unless the raw patch applies perfectly cleanly.
[20:22] <LarstiQ> phinze: your understanding is correct that it under the hood the operations basically boil down to that
[20:22] <LarstiQ> phinze: but with more risk
[20:22]  * mneptok summons lifeless 
[20:23] <phinze> fullermd: good point, LarstiQ: okay, thanks, i was really mostly concerned with understanding it properly anyways :) i'll stick with bzr merge
[20:29] <phinze> what i really need to do is fix my bzr workflow to account for the fact that i often find myself in a task branch with some code that should land in trunk and some that should land in 'feature-foo
[20:29] <phinze> '
[20:44] <LarstiQ> phinze: shelve, merge uncommitted, more branching?
[20:45] <Tak> phinze: you and me both
[20:46] <phinze> LarstiQ: yeah that's what i've been working on smoothing over
[20:46] <LarstiQ> k
[20:46] <phinze> shelve, switch, interactive-commit... trying to figure out best way to combine
[20:47] <phinze> and just making sure that "just commit and figure out later" should be closed off as an option
[20:47] <LarstiQ> the _best_ way of course is by doing the work where you want to have it in the end ;)
[20:47] <LarstiQ> phinze: don't forget rebase
[20:48] <phinze> LarstiQ: i was under the impression that rebase was bad voodoo ...?
[20:48] <LarstiQ> phinze: okay, maybe you _should_ forget ;)
[20:48] <LarstiQ> phinze: well, since we're enumerating all the options
[20:48] <phinze> so i am on a project team and i spend most of my time knocking down issues that fall under project namespace, but sometimes i need to edit code that is already in production and should be landing in trunk
[20:49] <phinze> so it's the workflow of a bunch of tasks on project branches and, oop! a task that needs to be done and pushed to trunk
[20:49] <phinze> s/project branches/my project's branch/
[20:50] <LarstiQ> right
[20:50] <phinze> and sometimes i'll figure out halfway through a given task for my project that, oh actually i'll need to change some library code to finish this
[20:51] <tsmith> i canNOT get bzr-svn installed on gentoo
[20:51] <tsmith> whenever i run "sudo layman -a bazaar" it says "* Overlay "bazaar" does not exist!
[20:51] <tsmith> "
[21:02] <phinze> tsmith: compile it from source? :)
[21:02] <LarstiQ> tsmith: try 'bzr'?
[21:02]  * LarstiQ has no clue about gentoo
[21:02] <phinze> LarstiQ: /me neither
[21:06] <verterok> bzrtools subversion bzr-svn
[21:06] <verterok> oops
[21:06] <verterok> tsmith: it's easy to build bzr-svn
[21:07] <verterok> tsmith: also you can add the overlay manually
[21:10] <shikibu> I want to move something like this: bzr mv --after src/classes/Cache.cls LiveRelease/5106-Utility/src/classes/Cache.cls, but bzr complains "bzr: ERROR: Could not move Cache.cls => Cache.cls: LiveRelease/5106-Utility/src/classes is not versioned."  However if I do "bzr add LiveRelease/5106-Utility/src/classes/" and then try to move Cache.cls, bzr will complain that LiveRelease/5106-Utility/src/classes/Cache.cls is already versioned. How do
[21:10] <shikibu> bzr what I want here?
[21:13] <LarstiQ> shikibu: bzr add --no-recurse
[21:13] <shikibu> tnx let me try that
[21:13] <LarstiQ> shikibu: and then do the mv --after as you tried it at first
[21:13] <phinze> LarstiQ: hmm rebase *does* look like bad voodoo... but it might be just the right kind of bad voodoo for me! ;)
[21:13] <shikibu> yes, I see
[21:14] <shikibu> LarstiQ: works very nicely; thanks for your help
[21:14] <LarstiQ> phinze: if you know what you are doing (and certainly what the impact of rebase can be on other people), it can be a handy tool
[21:14] <LarstiQ> shikibu: gladly :)
[21:16] <phinze> LarstiQ: yeah i generally find myself ending up in the role of Keeper of the Intergity of the Repository anyways... so this might be a good secert weapon to know how to use
[21:17]  * LarstiQ nods at phinze 
[21:18] <phinze> is the plugin on a trajectory towards landing in core?
[21:19] <phinze> jelmer: ^^ perhaps you'd know best? :)
[21:23] <tsmith> the documentation is flawed
[21:24] <tsmith> https://launchpad.net/bzr-gentoo-overlay/
[21:24] <tsmith> between step 1 and 2 it is *imperative* that the user run $ sudo layman -L
[21:26] <Pilky> If there are any mac users around, I've just pushed the source for the "nearly 0.1" of BazaarX to launchpad: https://launchpad.net/bazaarx
[21:28] <phinze> Pilky: will share with mac users in my office -- thanks
[21:28] <Pilky> cool
[21:28] <Pilky> only does status, commit, add and rm at the moment but it's a start :)
[22:17] <jam> spm: are you around?
[22:17] <jam> I seem to have something that successfully merged into the 2.0.0 pqm branch, but did not get pushed to launchpad
[22:17] <jam> At least, when I try to submit it, I get "Nothing to do" but when I try to pull it, I don't get my change
[22:19] <tsmith> how do you create a branch using tortoisebzr? ???? I don't see the command ANYWHERE
[22:20] <jam> sidnei: I tried setting "newest = True" in the config file, and my first attempt seemed to get to "Installing Templates" and then hung for a very long time
[22:22] <tsmith> how do you create a branch using tortoisebzr? ???? I don't see the command ANYWHERE
[22:23] <jelmer> phinze: I'm not aware of any plans to get rebase into core
[22:35] <sidnei> jam: well, its pulling every branch, that's why. if you give it '-vv' it should print some debugging info
[22:36] <jam> sidnei: it isn't hanging on pulling a given branch
[22:36] <jam> it is hanging at "Installing Templates"
[22:36] <jam> as in... about 20-30 min at just that step before I cancelled it
[22:36] <jam> maybe I'm wrong about what is going on
[22:37] <jam> I'm used to seeing it say "connecting to X", "connecting to Y" etc
[22:37] <jam> and hanging a long time on the initial
[22:37] <sidnei> jam: that sounds odd. i can give it a try later, but im leaving for dinner right now
[22:37] <jam> cd build-win32 && bin/buildout
[22:37] <jam> sidnei: no prob
[22:37] <jam> enjoy your dinner
[22:37] <jam> for now, I'm just running again with newest = false
[22:37] <sidnei> jam: you're running bzr-windows-installers or bzr?
[22:37] <jam> and see if that gets something built
[22:37] <jam> sidnei: bzr-windows-installers
[22:38] <sidnei> jam: trunk?
[22:38] <jam> sidnei: yes
[22:44] <sidnei> ok, its running, bbl
[23:11] <mwhudson> is making bzr's command line parsing stuff more resuable in other scripts seen as a worth goal?
[23:22] <jam> mwhudson: I think jml has wanted to do that a few times
[23:22] <jml> heh
[23:22] <jam> I think we would be willing to merge patches to that effect
[23:23] <mwhudson> basically, i've found something that makes it awkward and i'm wondering if i should file a bug
[23:23] <jam> mwhudson: explicit bugs are more likely to be looked at... the 2.1 series is a good target for big code cleanups
[23:24] <mwhudson> this thing is very tiny :)
[23:48] <lifeless> 36million rows imported
[23:48] <lifeless> mwhudson: it is reusable - commandant reuses it.
[23:49] <lifeless> mwhudson: patches to make it more reusable++
[23:49] <mwhudson> lifeless: well, yes, but there seem to be a few warts still
[23:49] <lifeless> mwhudson: but if you tell me whats grating I may be able to help
[23:49] <mwhudson> lifeless: Fail
[23:49] <mwhudson> heh heh heh
[23:49] <mwhudson> entertaining mispaste there
[23:49] <mwhudson> lifeless: https://bugs.edge.launchpad.net/bzr/+bug/431054
[23:50] <lifeless> jam: I'll get spm to push the branch; pqm had trouble when code hosting failed late last week
[23:50] <jam> lifeless: thanks
[23:50] <lifeless> spm: ^ just what you did for +trunk, on 2.0 and 2.0.0
[23:52] <lifeless> mwhudson: anything else?
[23:53] <mwhudson> lifeless: not yet, i was trying to ask if reports like this were of interest
[23:53] <lifeless> mwhudson: they definitely are
[23:53] <mwhudson> lifeless: now that i know that they are, i'll continue to produce them :)
[23:53] <lifeless> mwhudson: I may be wrong to suggest a helper method; my reasoning is that command objects themselves are not intended to be reused willynlly
[23:53] <mwhudson> my code is still a bit of a mess, i'll be in a better position to file sensible reports when i've cleaned it up a bit
[23:55] <RenatoSilva> verterok: Hi Gullermo, I pushed a new revision yesterday. I also added a test for non-ascii-terminated urls
[23:56] <lifeless> mwhudson: if this is ec2 stuff.. consider txaws :)
[23:57] <verterok> RenatoSilva: cool, I'll take a look to the branch tonight
[23:57] <jfroy|work> Is there a way for the command line to print the metadata recorded by the --fixes commit option?