[00:04] <Noldorin> jelmer: hrmm. where is this 'contrib' dir that the README mentions?
[00:18] <Noldorin> lifeless: hi
[01:48] <Noldorin> no-one around? :(
[01:49] <bob2> lots of people
[01:49] <Noldorin> bob2: you don't know that ;)
[01:50] <bob2> yes i do
[01:50] <Noldorin> prove it
[01:51] <Noldorin> exactly.
[01:51] <bob2> what?
[01:52] <Noldorin> ha
[01:57] <lifeless> Noldorin: pong
[01:57] <Noldorin> oh
[01:57] <Noldorin> hi lifeless
[01:58] <Noldorin> lifeless: read the README for the bundled bash-completion plugin earlier. i'm slightly confused
[01:58] <Noldorin> especially w.r.t. http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/revision/5240
[01:59] <lifeless> what about it ?
[01:59] <Noldorin> i see you made that commit
[02:00] <Noldorin> lifeless: readme suggest to use contrib/bash/bzr for lazy loading…but that loks like an old/obsolete version
[02:00] <Noldorin> no longer rlevant
[02:00] <Noldorin> certainly not included
[02:01] <lifeless> I didn't write it
[02:01] <lifeless> martin von gagern did the work
[02:01] <lifeless> I just landed it
[02:02] <lifeless> I've no memory of what was in it
[02:03] <Noldorin> lifeless: oh okay
[02:04] <Noldorin> lifeless: any thouhgts nontheless?
[02:06] <lifeless> not really no :) sorry!
[02:06] <lifeless> what are you trying to do ?
[02:06] <Noldorin> lifeless: get lazy loading working for bash completion
[02:06] <lifeless> ah
[02:06] <lifeless> uhm
[02:07] <Noldorin> lifeless: eval "`bzr bash-completion`" in my .bash_profile just does normal loading
[02:07] <Noldorin> slows down my shell load time
[02:07] <Noldorin> :(
[02:07] <lifeless> I don't know enough about how bash completion works to offer advice sorry
[02:07] <Noldorin> that's okay
[02:07] <lifeless> bzrlib.commands is probably a key thing for doing lazy-inspection of stuff
[02:08] <lifeless> it has a pretty solid incremental-use api
[02:08] <Noldorin> yeah… i don't want to go messing with the code though
[02:08] <lifeless> you might look at the deletion of the contrib script
[02:09] <lifeless> it probably explains where its gone (e.g. bash upstream)
[02:09] <Noldorin> lifeless: that commit is the deletion
[02:09] <Noldorin> no mention there
[02:11] <Noldorin> lifeless: incidentally, can bzr tell me the URL for a lp:foo branch?
[02:17] <lifeless> yes, but I don't think its exposed to the command line
[02:17] <Noldorin> ah
[02:17] <lifeless> its an xmlrpc lookup though
[02:17] <Noldorin> i see
[02:17] <lifeless> not local
[02:17] <Noldorin> right
[02:18] <Noldorin> lifeless: the lp: prefix is built into the launchpad plugin though i guess. are there other prefixes?
[02:19] <lifeless> yup
[02:19] <lifeless> theres an address book one for instance
[02:19] <Noldorin> oh?
[02:19] <lifeless> its in a plugin
[02:20] <Noldorin> what's the idea behind it?
[02:20] <Noldorin> google doesn't find it
[02:21] <lifeless> bzr-bookmarks
[02:22] <Noldorin> oh :P
[02:22] <Noldorin> you called it an address book
[02:22] <Noldorin> but yeah
[02:22] <Noldorin> i'm familiar with that
[02:22] <Noldorin> hm
[02:24] <Noldorin> lifeless: btw is von gagern still around?
[02:24] <Noldorin> either here on irc or contactable via some other mes
[02:24] <Noldorin> means*
[02:25] <lifeless> I think so
[02:30] <Noldorin> ok
[03:14] <Noldorin> lifeless: btw why do colocated branches still use the ,branch= syntax? surely a simple , is good enough?
[03:15] <lifeless> Noldorin: touch foo,bar; ls
[03:15] <lifeless> Noldorin: or less snidely - the branch= syntax is std66 blessed
[03:15] <lifeless> messing with it seems risky
[03:15] <Noldorin> hah
[03:15] <Noldorin> okay
[03:15] <Noldorin> fair enough
[03:16] <Noldorin> lifeless: are there any non-URL chars or char sequence that would work here?
[03:17] <lifeless> given that branch urls are, by definition urls
[03:17] <lifeless> no
[03:17] <lifeless> but where is 'here' ? that you refer to.
[03:17] <Noldorin> in the case of colocated branches :P
[03:18] <Noldorin> lifeless: i mean a pseudo-url, but okay...
[03:18] <lifeless> sure, but where in the UI ?
[03:19] <lifeless> like, I'm sure we can pass separate options around and htings like that
[03:19] <Noldorin> hmm?
[03:19] <Noldorin> don't geto u
[03:19] <lifeless> the ,branch= is the machine interface
[03:19] <Noldorin> not talking about ui here
[03:19] <lifeless> just like file:///home/username/branches/foo is the URL for 'foo' locally.
[03:28] <Noldorin> hm
[03:29] <Noldorin> lifeless: fair enough. no big deal, ceratinly for now :)
[03:29] <Noldorin> night
[03:29] <lifeless> night
[08:15] <mgz> morning!
[12:40] <abentley> jelmer: In your MP comment, are you saying that foreign branches should only implement public methods, not private ones?
[12:48] <jelmer> abentley: that's how it is at the moment
[12:50] <abentley> jelmer: Well, I can turn those into public methods, but I wouldn't want normal API users calling them.
[12:51] <abentley> jelmer: them= _get_uncommitted, _put_uncommitted
[12:54] <jelmer> abentley: why not?
[12:54] <abentley> jelmer: Because those methods accept raw files, but only shelves should be stored there.
[12:55] <abentley> jelmer: GitBranch implements _get_checkout_format, _get_nick, _basic_push, so ForeignBranches do seem to implement private methods from Branch.
[12:56] <jelmer> abentley: _basic_push  and _get_nick are just private methods, helpers for push() and nick (the property) respectively
[12:57] <jelmer> not sure about _get_checkout_format
[12:57] <abentley> jelmer: Right, just as _put_uncommitted is a helper for store_uncommitted, and _get_uncommitted is a helper for get_unshelver
[12:58] <mgz> I'm torn on the proposal as well
[12:59] <jelmer> abentley: except _put_committed and _get_uncommitted are on the base Branch object, not on BzrBranch or anything like that
[12:59] <mgz> on the one hand, it'd be useful to have shelves on the actual branches they relate to rather than on my lightweight checkout
[12:59] <jelmer> abentley: _basic_push and _get_nick are called by the bzr-git branch implementation itself
[13:00] <mgz> but I do hack-on-branch, then remember to switch -b later quite a lot
[13:00] <abentley> jelmer: The implementation on the base Branch object raises NotImplementedError.
[13:01] <abentley> jelmer: The functional implementations *are* on BzrBranch.
[13:03] <jelmer> abentley: so if the thing that the interface requires is really the presence of store_uncommitted, has_stored_uncommitted and get_uncommitted
[13:03] <jelmer> can't we just have that in the Branch, and the bzr-specific implementation (which uses _get_uncommitted and _store_uncommitted) in BzrBranch ?
[13:04] <abentley> jelmer: I think you mean "get_unshelver", not "get_uncommitted"?
[13:04] <jelmer> abentley: euhm, yes
[13:05] <abentley> jelmer: You mean, provide implementations of store_uncommitted, has_stored_uncommitted and get_unshelver on Branch that raise NotImplementedError?
[13:06] <abentley> jelmer: And then provide the real implementation on BzrBranch?
[13:06] <jelmer> abentley: yeah
[13:06] <abentley> jelmer: Forcing you to rewrite (complicated) get_unshelver instead of (simple) _get_uncommitted?
[13:08] <abentley> jelmer: And meaning we need to move tests of get_unshelver/store_uncommitted/has_stored_uncommitted to the per-branch tests?
[13:09] <jelmer> abentley: it doesn't make sense to store a (bzr-specific) serialization of a tree transform in a foreign branch
[13:09] <jelmer> abentley: I think those tests need to be in per_branch anyway, as they can be overridden by the implementation
[13:10] <jelmer> abentley: the other thing is that it simply won't be possible to support this for most of the foreign formats - svn nor git support per-branch metadata like this
[13:10] <abentley> jelmer: That's a good point.  I was trying to avoid burdening you.
[13:11] <abentley> jelmer: Okay, I'll do that.
[13:11] <jelmer> abentley: Perhaps it would be possible to allow implementations to raise something if they don't support storing uncommitted changes?
[13:12] <abentley> jelmer: Yes, that makes sense.
[13:15] <abentley> jelmer: So rick_h told me that when you try to switch with uncommitted changes in git, you get "error: You have local changes to "X"; cannot switch branches.".  Is that right?
[13:16] <jelmer> abentley: no, it works fine here
[13:17] <jelmer> abentley: perhaps he has extra options for that enabled in his config?
[13:17] <abentley> jelmer: Odd.  This StackOverflow article also says that's the behaviour: http://stackoverflow.com/questions/1304626/git-switch-branch-and-ignore-any-changes-without-committing
[13:19] <jelmer> abentley: maybe that behaviour changed at some point? I don't have anything in my gitconfig as far as I can tell
[13:44] <abentley> jelmer: It seems the behaviour I described is from /git checkout/, not /git switch/.
[13:45] <abentley> jelmer: Or maybe the behaviour I described only happens when the changes would conflict?
[13:46] <jelmer> abentley: the behaviour I described is from 'git checkout', I'm not sure about 'git switch' (didn't even realize that existed)
[13:46] <jelmer> abentley: Yes, I could imagine changes conflicting being cause for an error
[13:48] <abentley> jelmer: That seems to be it.  So the difference between bzr and git would be in the handling of conflicts.
[14:37] <abentley> jelmer: So RemoteBranch isn't a descendant of BzrBranch, which means it won't automatically get get_unshelver/store_uncommitted/has_stored_uncommitted.  I could write a mixin, but it feels... dirty.  Thoughts?
[14:49] <jelmer> abentley: I see two options: 1) provide smart verbs for fetching/storing uncommitted changes 2) add three stubs that call out to self._real_branch
[14:52] <abentley> jelmer: I had actually started on 3) extract get_unshelver/store_uncommitted/has_stored_uncommitted to a component, i.e. UncommittedManager.  Maybe I'll go for 2.  Smart verbs don't seem worth it yet, since it's just 1 or 2 vfs operations.
[14:52] <mgz> this isn't normal is it:
[14:52] <mgz> $ bzr merge --preview -r15645..15644 .
[14:52] <mgz> [14:53] <mgz> things the file needs changing, no content changes, no x bit changes...
[14:53] <mgz> *thinks
[14:54] <abentley> mgz: No, but TransformPreviews don't necessarily detect when a file-level merge produces no change.  What does an actual merge do?
[14:56] <mgz> nothing.
[14:56] <mgz> `bzr st` returns blank
[14:56] <abentley> mgz: And presumably "bzr st -r15645..15644" lists security.cfg?
[14:57] <mgz> and a whole bunch of other stuff, as r-1 is the revert of that
[14:57] <mgz> but for some reason that file doesn't think the revert was complete
[14:58] <jelmer> abentley: I'd rather leave the RemoteBranch ignorant of the actual underlying logic, which is already present in the actual branch
[15:48] <maxb> mgz: Thanks for forwarding that email from Thorsten. It only went to admins of ~bzr, not members, it seems. (jelmer: <- fyi)
[15:48] <maxb> I guess I should send a reply
[15:50] <mgz> he's replied to your post on the list now
[15:50] <mgz> so would make sense to respond there I think
[15:51] <mgz> still don't really understand why using a newer LTS isn't an option :)
[15:51] <jelmer> maxb: ah, urgh
[15:52] <jelmer> maxb: the web page says it would go to all *members*
[15:54] <abentley> jelmer: for me, it says "Contact this team's admins".  Or am I looking in the wrong place?
[15:54] <jelmer> abentley: https://launchpad.net/~bzr says "None, members emailed directly" near the email field
[15:55] <jelmer> the link in the right hand side column indeed does say "Contact this team's admins"
[15:56] <abentley> jelmer: This spamming of team admins seems to be a new phenomenon.  I don't think it had ever happened to me two months ago.
[17:19] <maxb> jelmer: You *are* an admin, so for you it contacts the members
[17:22] <jelmer> maxb: I have no idea how it would actually contact the members though
[17:22] <jelmer> maxb: I don't have a link for that..
[17:23] <maxb> ?
[17:23] <jelmer> maxb: It doesn't provide me with a way to actually contact all members as far as I can see
[17:24] <maxb> If I look at a team page for a team of which I am admin, the right hand portlet says "Contact this team's members". For a team I'm not admin, it says "Contact this team's admins"
[17:28] <jelmer> maxb: ah, you'r eright
[17:28] <jelmer> also, I can't spell
[20:50] <Noldorin> hi jelmer
[22:06] <Noldorin> jelmer: you around bychance?
[22:11] <thomi> In Quantal, it seems bzr bisect doesn't work due to "AttributeError: 'CHKInventoryRepository' object has no attribute 'iter_reverse_revision_history'" - does anyone know if this is a simple patch, or a more involved fix?
[22:14] <thomi> submitted as https://bugs.launchpad.net/bzr-bisect/+bug/1026827
[22:27] <thomi> I have a branch that seems to fix the issue for me: https://code.launchpad.net/~thomir/bzr-bisect/fix-for-quantal/+merge/115847
[22:41] <jelmer> Noldorin: hi
[23:43] <Noldorin> jelmer: was just trying out bzr-git again (on my mac)
[23:44] <Noldorin> noticed a new error
[23:44] <Noldorin> well, it may not be new
[23:44] <Noldorin> bzr: ERROR: The file id "None" is not present in the tree <bzrlib.inventory.CHKInventory object at 0x105dc4950>.
[23:47] <Noldorin> jelmer: other hting was… does bzr-git support rmbranch?