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