[03:22] https://dev.launchpad.net/BuildBranchToArchive/NonNativePackages [03:23] jelmer ^ [04:19] james_w`: thanks! [04:21] np [04:22] james_w`: also, that apostrophe looks good on you ;-) [04:23] thanks :-) [05:21] Dear lazybzr, Could you please make `bzr update bzr+ssh://path/to/branch` work? Thanks! [05:21] :) [05:22] hey AfC [05:23] AfC: AFAIK that should already work (but be inefficient). doesn't it? [05:23] jelmer: hey dude [05:23] jelmer: oh? Didn't last I tried. [05:23] * AfC lokos [05:24] [slow, inefficient is fine. Just a lot easier than having to separately do an SSH invocation] [05:24] Hm [05:24] bzr: ERROR: is not a local path. [05:24] jelmer: guess not, at least not in released version. That a new feature? If so, you rick [05:24] (you'd rock if it was out. rick is the future tense, clearly) [05:25] :-) [05:25] * jelmer tries [05:27] yeah, it seems to work here when run against lp [05:28] jelmer: sweet! [05:29] Hey, who is maintaining bzr-gtk these days? Anyone? [05:30] AfC: unfortunately it's been a bit neglected [05:30] Gary is now working on qbzr, vila and I have been busy with other projects, Szilveszter is busy with real life [05:30] Hm. Pity. [05:31] Well, I'll grab the code and see if I can scratch my itch. Not that much of a python guy, but I can try. [05:32] AfC: I'm still doing urgent fixes and reviewing merge proposals but I haven't had time for other improvements. [05:32] jelmer: well that's good to know. I'll have a swat at it then === gthorslund_ is now known as gthorslund === frakturfreak_ is now known as frakturfreak [10:17] I'm trying to follow this blog post for bzr: http://www.taoeffect.com/blog/2009/06/using-bazaar-like-git-repoalias-plugin/. When I try "bzr ignore .bzr-repo" I get "bzr: ERROR: Not a branch: "/home/jamey/Sites/jamey.dev-bzr/". Am I doing something wrong? [10:21] Just had dinner with a friend who was telling me how much better bzr was than the other DVCSes he'd been using. :-) [10:21] Just thought you guys would like to know. :-) [10:32] I've figured out the previous issue I was having, I should have RTFM. [10:41] I'm following the guide at http://www.taoeffect.com/blog/2009/06/using-bazaar-like-git-repoalias-plugin/, all works as expected. But how do I get Bzr Explorer to show the graph of branching and merging in a logical manner? At the moment it only shows the current branch without relation to any of the other branches. [10:42] is it in fact a branch? [10:43] (also ignore only makes sense in a branch with a working copy, so check that, too) [10:45] well, after following that guide, bzr tells me that it's a lightweight checkout with the shared repository under .bzr-repo. [10:47] So when I've switched to another-branch, committed something, switched back to trunk and tried to merge these changes, it has worked but then the graph is still a straight line with a '+' for the revision I just committed. Whereas I was hoping for it to show first-branch with a line into trunk implying it was merged. === apw` is now known as apw [11:00] Can anyone help me understand getting cheap local branching working? I keep duplicating all my files and doubling the size of my new repo. [11:13] Any way to shelve only one of these changes, not both at once? http://pastie.org/1469439 [11:14] One change is to do with integrating a different debugger, the other change has to do with adding documentation support. [16:25] Hi all. I just created a branch from a lp project, made some changes, committed, and pushed. When I push, bzr warns me that I have uncommitted changes that won't get pushed -- but bzr st doesn't show any. Looking at my new branch's code on lp seems to show all my changes. Any idea what may be going on? === beuno is now known as beuno-lunch === beuno-lunch is now known as beuno [18:11] yshavit: can you pastebin the bzr st ? [18:11] showing the command and the output [18:41] lifeless: the command was "bzr st" and the output was nothing, just a bash prompt for the next command [18:42] lifeless: I've since made other changes, so we'll see if the problem persists. It's going to be a short-lived branch, so I'm fine dealing with spurious warnings. It hasn't happened on any other branches I've made on this project. [18:49] yshavit: that reminds me of a recent bug report [18:49] yshavit: but I don't remember the details [18:49] yshavit: possibly if you search the bug tracker you'll find it though... [18:50] spiv: alright, thanks -- I'll look around. [19:23] jelmer: If you're around - is it expected or weird that my sqlite tables for the RevisionInfoCache contain lots of rows for revisions where all the columns besides (path, revnum, mapping) are null? [20:16] is it possible to have a location-specific 'whoami'? [20:17] jml, bzr whoami --branch [20:17] jml, I don't know if you can do it in locations.conf [20:17] james_w`: yeah, that's what I'd prefer. [20:18] you can, I do [20:46] https://dev.launchpad.net/BuildBranchToArchive/NonNativePackages [20:51] Hi Jelmer, can I get your advice on some bzr-svn code? I've recently noticed that each of the 4 facets of the bzr-svn sqlite/tdb cache have "interfaces" defined in various python files outside the cache directory. [20:52] However, these "interfaces" aren't explicitly inherited from by the implementation classes, which makes them a lot less discoverable to people coming fresh to the code. [20:52] maxb: how do you mean? [20:52] I was thinking of moving them all into cache/__init__.py and making them actually be inherited from - in fact, I did that, but then ran into circular import problems. [20:53] For example, RevisionIdMapCache and RevisionInfoCache at the end of revids.py serve no purpose to the code [20:54] However, I've just noticed that they are in fact the "interface declaration" for the same named classes in tdbcache.py and sqlitecache.py [20:54] likewise, there are similar classes in logwalker.py and parents.py corresponding to the other parts of the cache [20:55] maxb: I'd prefer to keep those interfaces closes to the code they're related to [20:56] maxb: in particular since caches can choose to implement some of those interfaces [20:58] jelmer: The thing I find unhelpful at the moment is that there is nothing linking the implementations with these interfaces. The code is essentially "dead" right now [20:58] It's also not good that there are 3 copies of each of the method docstrings, which have got slightly out of sync [20:59] maxb: I'd be happy to have them inherit from those interfaces [20:59] maxb: and have only the interface have the docstrings [21:00] OK, I'll have a look if that can be done without other circular import pain [22:59] if anyone wants to fix https://bugs.launchpad.net/bzr/+bug/701940 and is in Dallas, I will provide you with many drinks. [23:00] it's breaking our build slaves every couple of days, requiring us to manually intervene (which is precious time) [23:00] jml: So it's fairly reproducible? [23:01] jml: Also, I would be rather careful with making that kind of announcement ;-) [23:01] jelmer: that's what I'm told [23:01] jelmer: and I announced with the greatest of care :) [23:05] jelmer, http://doc.bazaar.canonical.com/bzr.dev/developers/bug-handling.html [23:06] jml: You're in Dallas? [23:08] poolie: thanks [23:10] Peng: most of us are [23:10] Ah? [23:10] Event? [23:15] Peng: I am. [23:16] Peng: yeah, the Launchpad team is having its twice-yearly Thunderdome, with the Bazaar folk along as well. [23:16] by which I mean, Canonical Launchpad team & Canonical Bazaar folk. [23:17] maxb: hi [23:21] jelmer: hi [23:22] jml: your offer intrigues me! [23:36] spiv: you are welcome to take it up [23:53] * jasono is away: I'm busy [23:53] jasono: That's nice.