| === fta_ is now known as fta | ||
| 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:57 |
|---|---|---|
| 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 | 02:58 |
| === JaredWigmore is now known as JaredW | ||
| bob2 | hm, bzr-git overrode co and makes it fail "bzr: ERROR: Push is not yet supported for bzr-git. Try dpush instead." | 03:53 |
| lifeless | for everything? | 03:58 |
| bob2 | hm, seems to happen if cwd is inside a git checkout (however deep) | 04:00 |
| lifeless | file a bug | 04:03 |
| bob2 | yeah, just reproducing in /tmp | 04:03 |
| * SamB wonders if it's possible to run bzr under gud/Emacs | 04:35 | |
| Toksyuryel | Well, from my understanding it's turing-complete, so it should in theory be possible | 04:51 |
| jml | conflict behaviour wrt pyc files in otherwise empty to-be-removed directories sucks. | 07:40 |
| 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:55 |
| jml | it's a pain. | 07:56 |
| RAOF | I suspect bzr-git isn't supposed to consume 2GiB memory when dpushing. | 10:45 |
| LarstiQ | I suspect your'e right :) | 10:46 |
| jelmer | bob2: are you perhaps branching into a git repository? | 10:48 |
| ndurner | Hi | 13:21 |
| DaffyDuck_ | So, have I understod bazaar correctly: Parents know nothing about theit child branches -- only the children know who their parent is? | 13:30 |
| LarstiQ | DaffyDuck_: yes, but parents can be replaced. | 13:32 |
| 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:33 |
| 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:34 |
| DaffyDuck_ | Is there a concept of "switching" a branch from one to another, you check out the code to a new directory? | 13:36 |
| DaffyDuck_ | (I may be confusing people with my terminology, but I'm new to bazaar, so be patient with me). | 13:37 |
| ndurner | What's the "best" reasonably stable storage format? | 13:40 |
| LarstiQ | DaffyDuck_: switching a working tree between branches you'd do with `bzr switch` | 13:55 |
| LarstiQ | DaffyDuck_: personally I prefer just cding around in the filesystem | 13:56 |
| 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:16 |
| SpinachHead | oh, wait I guess when I revert to an older version I need to issue commit ... | 14:17 |
| lifeless | export doesn't export the current stuff on disk | 14:33 |
| lifeless | it exports the current commit | 14:33 |
| lifeless | so you want export -r <X> ... | 14:34 |
| SpinachHead | okay, thanks | 14:39 |
| === JamalFanaian|afk is now known as JamalFanaian | ||
| 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:53 |
| LarstiQ | wildfire: post_commit_to iirc, if `bzr help email` doesn't mention, have a look at its README | 16:54 |
| 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:57 |
| 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:58 |
| LarstiQ | wildfire: also see `bzr help configuration` | 16:59 |
| wildfire | LarstiQ, thanks - will check those out | 17:02 |
| LarstiQ | wildfire: locations.conf is good for pattern matching whole hierarchies of branches | 17:02 |
| wildfire | LarstiQ, thanks for you help, have now got it working | 17:09 |
| LarstiQ | wildfire: cool | 17:11 |
| 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:04 |
| 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:05 |
| jelmer | LarstiQ: I wonder what contact I need to change for that | 18:22 |
| LarstiQ | jelmer: don't know if it would help, but I'm not in ~bzr-svn | 18:23 |
| jelmer | LarstiQ: you are now >-) | 18:24 |
| parolang | Hello, are any of the developers here? | 19:17 |
| jelmer | parolang: hi | 19:20 |
| 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:21 |
| 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:23 |
| 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:24 |
| jelmer | parolang: no idea, sorry | 19:25 |
| parolang | okay, thanks anyway | 19:25 |
| ronny | jelmer: have you seen the stuff about the pythonic fs api's? (there was a talk on europython) | 19:29 |
| 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:30 |
| * SamB wonders where to get a recent bzr-gtk deb | 19:41 | |
| 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:48 |
| 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:49 |
| ronny | http://eagain.net/blog/ is a good starting point i think | 19:50 |
| ronny | brb, forgot to feed the rabbit | 19:50 |
| ronny | re | 19:57 |
| * SamB wonders what kind of support debian packaging has for running tests | 20:43 | |
| jelmer | SamB: how do you mean? | 21:24 |
| 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:29 |
| jelmer | SamB: In this particular case that wouldn't help. python2.3 isn't installed by default | 21:35 |
| SamB | hmm. | 21:46 |
| SamB | jelmer: hmm. true, not in the build-deps... | 21:47 |
| * SamB wonders what to blame this on | 21:47 | |
| 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:48 |
| SamB | jelmer: btw, you don't need the python-all-dev dependancy in debian/control, according to http://wiki.debian.org/DebianPythonFAQ | 21:49 |
| SamB | which would make it easier for some of us to contribute merge requests ;-) | 21:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| SamB | but then I saw what you'd said about how running the tests at build time wouldn't have helped | 21:54 |
| * 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> ;-) | 21:59 | |
| SamB | actually, I'm almost surprised there *is* an automake package | 22:00 |
| SamB | why not just have packages for each major.minor? | 22:01 |
| SamB | I mean, that's almost exactly what we have anyway ... | 22:02 |
| * SamB wonders why bzr builddeb is alarmed that he can't sign a package as jelmer | 22:11 | |
| * 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:55 |
| SamB | bzr-builddeb's tests are importing something that does not even exist | 22:58 |
| 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:10 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| jelmer | lifeless: Are you concerned about the readability of the code, the ui, other issues? | 23:30 |
| naoki | Hi | 23:31 |
| naoki | I tried "bzr init-repo --git .git" "bzr pull git://git.sourceforge.jp/gitroot/msgpack/msgpack.git" | 23:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| * SamB wonders how to get http://bundlebuggy.aaronbentley.com/project/bzr/request/<E1MQZOB-0003MV-Id%40hydrogen> fully-approved ... | 23:38 | |
| SamB | and, hey, aren't <> banned from URLs? | 23:40 |
| lifeless | they are in the escape set, yes | 23:41 |
| * SamB wonders why mozilla unescaped them | 23:41 | |
| 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:42 |
| lifeless | it will tell you whether < can be unescaped in a URL :P | 23:45 |
| 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:49 |
| lifeless | jelmer: You could create a plugin that acts as a symlink, replacing itself on load :P | 23:50 |
| 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:51 |
| 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:52 |
| jelmer | lifeless: no, I'm not a big fan of lightweight checkouts because I have to change directories to manage branches | 23:53 |
| lifeless | jelmer: what do you mean? | 23:54 |
| 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:57 |
| lifeless | if its worse for heavy users like you, thats a problem | 23:58 |
| jelmer | lifeless: sorry, was taking a moment to think about what the core of the problem is for me | 23:59 |
| lifeless | thank you ;) | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!