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