=== fta_ is now known as fta [02:57] is it necessary to specify a branch name when doing a push to launchpad, or is "bzr push lp:~myname/myproject" enough to push it to the trunk? [02:58] pattern: specify the branch [02:58] pattern: if you pass --remember, bzr will remember the branch and you can then just 'bzr push' after that [02:58] ah, ok [02:58] thank you === JaredWigmore is now known as JaredW [03:53] hm, bzr-git overrode co and makes it fail "bzr: ERROR: Push is not yet supported for bzr-git. Try dpush instead." [03:58] for everything? [04:00] hm, seems to happen if cwd is inside a git checkout (however deep) [04:03] file a bug [04:03] yeah, just reproducing in /tmp [04:35] * SamB wonders if it's possible to run bzr under gud/Emacs [04:51] Well, from my understanding it's turing-complete, so it should in theory be possible [07:40] conflict behaviour wrt pyc files in otherwise empty to-be-removed directories sucks. [07:55] jml: That confused everyone in my team when we moved to bzr. [07:55] Took a while to work out what was going on... [07:55] yeah. [07:56] it's a pain. [10:45] I suspect bzr-git isn't supposed to consume 2GiB memory when dpushing. [10:46] I suspect your'e right :) [10:48] bob2: are you perhaps branching into a git repository? [13:21] Hi [13:30] So, have I understod bazaar correctly: Parents know nothing about theit child branches -- only the children know who their parent is? [13:32] DaffyDuck_: yes, but parents can be replaced. [13:33] DaffyDuck_: all branches are equally independent, multiple different relationships can exist (submit, parent, push, public, etc) [13:33] LarstiQ: So you essentially tell the child branch to "re-attach" to another parent? [13:34] DaffyDuck_: yes, although "attached" gives impression of a stronger bond then there is. [13:34] DaffyDuck_: it's just the default location for several operations, like pull. [13:34] I understand. [13:36] Is there a concept of "switching" a branch from one to another, you check out the code to a new directory? [13:37] (I may be confusing people with my terminology, but I'm new to bazaar, so be patient with me). [13:40] What's the "best" reasonably stable storage format? [13:55] DaffyDuck_: switching a working tree between branches you'd do with `bzr switch` [13:56] DaffyDuck_: personally I prefer just cding around in the filesystem [14:16] when I used revert to go back to say -r 1 it still shows the files from the newer versions when I export the files.... I don't know why that is. How would I revert to a previous version and then export it in the state it the project was in in version 1? [14:17] oh, wait I guess when I revert to an older version I need to issue commit ... [14:33] export doesn't export the current stuff on disk [14:33] it exports the current commit [14:34] so you want export -r ... [14:39] okay, thanks === JamalFanaian|afk is now known as JamalFanaian [16:53] Hi, I am trying to configure a repository to send email everytime a commit occurs [16:53] but am not succeeding [16:53] bzr plugins list email as being installed [16:53] but how do I configure the address that should be sent to? [16:54] wildfire: post_commit_to iirc, if `bzr help email` doesn't mention, have a look at its README [16:57] LarstiQ, the readme says 'post_commit_to' but where / how do I configure that setting is what has me confused [16:57] wildfire: ah, ok [16:58] wildfire: one of several places, depending on what you want to accomplish [16:58] wildfire: I use ~/.bazaar/locations.conf to manage that, but ~/.bazaar/bazaar.conf or .bzr/branch/branch.conf are other candidates [16:59] wildfire: also see `bzr help configuration` [17:02] LarstiQ, thanks - will check those out [17:02] wildfire: locations.conf is good for pattern matching whole hierarchies of branches [17:09] LarstiQ, thanks for you help, have now got it working [17:11] wildfire: cool [18:04] jelmer: bzr-svn 0.6.3 uploaded to bzr-beta-ppa, I'll copy them over to bzr-ppa tomorrow if I don't see any complaints [18:05] jelmer: https://edge.launchpad.net/bzr-svn/0.6/0.6.3 doesn't exist yet, but I don't have access to create it [18:22] LarstiQ: I wonder what contact I need to change for that [18:23] jelmer: don't know if it would help, but I'm not in ~bzr-svn [18:24] LarstiQ: you are now >-) [19:17] Hello, are any of the developers here? [19:20] parolang: hi [19:21] Hey, I wanted to know if you guys were interested in the documentation being in texinfo format? [19:21] Personally I would like, and would help with that, but only if you guys were interested. [19:23] parolang: Perhaps better ask on the mailing list ? I would expect there to be some interest in having the docs available in texinfo, but there aren't a lot of developers around at the moment. [19:23] Yeah, I'll try that. Right now it's in some python format isn't it? [19:24] yeah, it's in restructuredText [19:24] The main advantages to texinfo are two: better pdf/printed output, and a conveniant reader within emacs. [19:24] Do you know if that outputs in texinfo? [19:25] parolang: no idea, sorry [19:25] okay, thanks anyway [19:29] jelmer: have you seen the stuff about the pythonic fs api's? (there was a talk on europython) [19:30] jelmer: i intend to use that as api for accessing revisions/building commits in anyvc, so i'll probably end up inventing it for a set of vcs's [19:41] * SamB wonders where to get a recent bzr-gtk deb [19:48] SamB: unstable has one [19:48] jelmer: ah, nice [19:48] ronny: no, haven't seen that [19:48] * SamB hadn't looked very hard yet [19:48] * SamB wishes aptitude wouldn't thrash so much [19:48] ronny: is there a pep or something like that? [19:49] jelmer: currently they are a separate set of api's, not yet proposed for inclusion in python [19:49] the key part is, the api looks reasonable and can be implemented independ of the base lib [19:50] http://eagain.net/blog/ is a good starting point i think [19:50] brb, forgot to feed the rabbit [19:57] re [20:43] * SamB wonders what kind of support debian packaging has for running tests [21:24] SamB: how do you mean? [21:29] jelmer: well, it would be nice if the tests for e.g. subunit were run as part of the build, so that e.g. having a wrong XS-Python-Version: in debian/control would be caught ... [21:35] SamB: In this particular case that wouldn't help. python2.3 isn't installed by default [21:46] hmm. [21:47] jelmer: hmm. true, not in the build-deps... [21:47] * SamB wonders what to blame this on [21:48] SamB: You have python2.3 installed and subunit is currently setup to be pre-compiled for all python versions that are installed on the system [21:48] SamB: I'm uploading a new version that will only do so for python 2.4 and later [21:49] jelmer: btw, you don't need the python-all-dev dependancy in debian/control, according to http://wiki.debian.org/DebianPythonFAQ [21:50] which would make it easier for some of us to contribute merge requests ;-) [21:51] SamB: fixed now as well [21:51] SamB: how do you mean? [21:51] jelmer: for the packaging, I mean [21:51] it would be irresponsible to send you a patch that I hadn't tested, wouldn't it? [21:52] and it's nicer not to have to reinstall python 2.4 just to satisfy some overzealous build-dep [21:52] SamB: yes, but nothing stops you from removing that unnecessary dependency as well >-) [21:52] true [21:53] anyway, both should now be taken care of [21:53] I was about to ask if there's a way to commit just some of the changes in a file to that end, actually ;-) [21:54] but then I saw what you'd said about how running the tests at build time wouldn't have helped [21:59] * SamB is a bit amused that he apparantly doesn't have what it takes to satisfy the "automake" build-dep, given what he sees when he types automake ;-) [22:00] actually, I'm almost surprised there *is* an automake package [22:01] why not just have packages for each major.minor? [22:02] I mean, that's almost exactly what we have anyway ... [22:11] * SamB wonders why bzr builddeb is alarmed that he can't sign a package as jelmer [22:55] * SamB wishes something would run "bzr selftest" with all the Debian bzr packages installed, regularly [22:55] (at least "bzr selftest --list" would be good) [22:58] bzr-builddeb's tests are importing something that does not even exist [23:10] SamB: I posted a patch to the bzr list recently that should be the first step towards that [23:10] SamB: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C20090513223140.GB13847%40vernstok.nl%3E [23:13] jelmer: hi, I just reviewed the patch I just saw, it looks like a step backwards, to our 2003 loading code or so [23:14] lifeless: a step back in what sense? [23:14] likelyhood of bugs, strange interactions, and the ability to clearly describe what goes on when corner cases exist. [23:15] we used to use find_module and imp_module [23:15] it was very complex [23:15] now we just import [23:15] much simpler [23:15] yeah, but that makes it impossible to load individual modules.. [23:15] s/modules/plugins/ [23:15] 'import bzrlib.plugins.foo' [23:15] there, loaded. [23:16] lifeless: it doesn't allow you to specify a path to a plugin, for example [23:16] (which is what I'm after) [23:16] Ah! well thats a totally different thing, isn't it :) [23:17] ... in what context would this import appear? [23:17] SamB: at the moment there is a loop in the function that 'loads all plugins' that well, loads all the ones it found [23:17] * SamB is pretty sure he doesn't have a config file with 'import bzrlib.plugins.svn' in it anywhere ;-) [23:17] lifeless: yeah, sorry. I knew what I meant but that's not what I said :-) [23:18] I'd like us to add a filter to that, which allows saying 'only load svn' or 'load all but svn' [23:18] s/said/wrote/ [23:18] man, this is complicated :-P [23:18] lifeless: I'd like to be able to load plugins from arbitrary paths [23:18] I'm totally pro that, because: we say to people 'don't load that plugin and see if things get better' [23:19] jelmer: what name would you give the plugin in this arbitrary path? [23:19] lifeless: presumably the name would either come from the last component of the path, or be given along with the path [23:19] SamB: jelmer's code, I'd like jelmer's answer :P [23:19] I thought he hadn't written that bit yet [23:21] lifeless: Either the user should specify the name, or perhaps we could e.g. use bzr_plugin_name from setup.py if nothing was specified. [23:21] jelmer: but setup.py is for uninstalled plugins! [23:22] what is this setup.py you speak of ? [23:22] lifeless: well, perhaps if we end up putting that data in an info.py file or something.. :-) [23:22] * SamB would think __init__.py would be the place [23:22] jelmer: nearly-arbitrary paths are supported by BZR_PLUGINS_PATH already; why do you need to be more specific than that? [23:23] lifeless: that's the parent path of the plugin [23:23] SamB: thats a race condition, can't get data out of __init__.py without loading it [23:23] jelmer: yes, it is. [23:23] jelmer: *why isn't it specific enough for you* [23:23] lifeless: it means I have to create a parent plugin directory with a symlink every time. [23:23] every time what? [23:23] Users install plugins pretty rarely [23:23] lifeless: and you can get data out of some submodule without loading it? [23:23] lifeless: every time I want to run the testsuite of a plugin [23:24] maybe 0.0001 of the times they install plugins [23:24] SamB: I think you've lost track of the discussion :) [23:24] lifeless: maybe you should just use a text file? [23:24] SamB: plugins are imported into bzrlib.plugins.NAME [23:24] lifeless: I know *that* [23:25] I've seen enough tracebacks to have figured that out by now, I think ;-) [23:25] SamB: so, we can't use __init__ to figure out NAME :P [23:25] lifeless: ah. point. [23:25] if the plugin even has a directory [23:25] just require that ;-) [23:25] thats unpythonic [23:26] but where would they put the README if they didn't have a directory? [23:26] at the moment, and we worked hard to get it, bzr plugins are 'just python packages/modules in bzrlib.plugns' [23:26] SamB: in the module docstring [23:26] and, uh, how do you create a bzr branch which just stores a file ? [23:27] SamB: you probably don't, but thats a different discussion; people do create trivial single file plugins. [23:27] jelmer: so, I think the problem is, you're saying 'how do I load an arbitrary python module/package without changing the python path' [23:27] jelmer: and the answer is you don't. [23:28] well, just taking the name from the last component of the path, if the user doesn't specify one, should still work okay shouldn't it? [23:28] so we either need to change the identity that "bzr plugins are 'just python packages/modules in bzrlib.plugns'" [23:28] SamB: If that would work, setting BZR_PLUGINS_PATH + --only-plugins=svn, would work. [23:28] lifeless: ... or use import hooks to resolve their locations? [23:29] SamB: that is indeed another possibility [23:29] lifeless: I don't follow what the particular problem is with that though [23:29] jelmer: which 'that' [23:29] too many recent subjects [23:29] yeah ;-) [23:29] lifeless: with loading an arbitrary module/package without changing the python path. [23:30] lifeless: Are you concerned about the readability of the code, the ui, other issues? [23:31] Hi [23:31] I tried "bzr init-repo --git .git" "bzr pull git://git.sourceforge.jp/gitroot/msgpack/msgpack.git" [23:32] bzr pull stopped with "NotCommitError" [23:32] naoki: you'd probably want "bzr branch git://git.sourceforge.jp/gitroot/msgpack/msgpack.git" [23:33] naoki: otherwise the behaviour would be the same as "git clone git://git.sourceforge.jp/gitroot/msgpack/msgpack.git .git" [23:33] I want to try to pushing local git->remote git with bzr-git. [23:34] "git clone git://git.sourceforge.jp/gitroot/msgpack/msgpack.git" works fine. [23:34] naoki: in that case, probably try creating a local git branch first [23:34] "bzr init --git foo; cd foo; bzr pull git://..." [23:35] naoki: pushing between git repositories should generally work with bzr-git but probably isn't one of the best tested code paths. if you hit any issues, please file bugs. [23:36] lifeless: still there? [23:36] jelmer: I'm worried about conceptual clarity; code reuse; debuggability; compatibility with eggs and other extensions; documentation [23:36] lifeless: ok [23:37] all of where issues when we had a very path focused loader in the past [23:37] I _really_ don't want to go back to those days [23:38] * SamB wonders how to get http://bundlebuggy.aaronbentley.com/project/bzr/request/ fully-approved ... [23:40] and, hey, aren't <> banned from URLs? [23:41] they are in the escape set, yes [23:41] * SamB wonders why mozilla unescaped them [23:42] perhaps I'm wrong, std66 will say [23:42] std66 won't tell me why mozilla does this or that foolish thing ... [23:45] it will tell you whether < can be unescaped in a URL :P [23:49] its not in unreserved [23:49] so nor is it a delimiter [23:49] it must be escaped [23:49] lifeless: thanks for clarifying. I'm not totally convinced, but I also don't think this is a particularly useful feature for a lot of users other than me so perhaps it's better off in a plugin. [23:50] jelmer: You could create a plugin that acts as a symlink, replacing itself on load :P [23:51] jelmer: While I understand the use case, I still don't understand why its needed - I don't seem to have the problem you do [23:52] lifeless: When I work on plugins I tend to work in feature branches, and I often work on multiple features in parallel. [23:52] jelmer: do you use bzr switch? [23:53] lifeless: no, I'm not a big fan of lightweight checkouts because I have to change directories to manage branches [23:54] jelmer: what do you mean? [23:57] serious question - we have this big UI angst at the moment, and switch seems to be a key component in addressing a bunch of issues [23:58] if its worse for heavy users like you, thats a problem [23:59] lifeless: sorry, was taking a moment to think about what the core of the problem is for me [23:59] thank you ;)