[00:07] james_w: yeah, certainly the tricky part will be coordinating all plugins to be compatible with bzr 1.3 and I will have to look into that the most. [00:11] well bzrtools and bzr-builddeb have just had releases, so should be fine. [00:11] bzr-svn just had an upload that jelmer acked as being compatible, so it's only bzr-gtk that I am unsure about. [00:15] hi, I try to integrate bzr in some of my scripts, is there an easy way to find out wheather a file/dir is in a bzr-branch or not? [00:15] and return the related branch object? [00:16] hmm, any reason why bzr-gtk in ubuntu hardy only seems to provide olive, no nautilus integration? [00:27] thekorn: 'from bzrlib import branch; b = branch.Branch.open(dir)' Does that do what you want? [00:27] thekorn: something like "errors.NotBranchError" is thrown if it's not a branch. [00:28] there's also open_containing if you may be given a path below a branch, this returns a tuple (branch, relpath). [00:28] thekorn: or do you have a branch and want to know if the given path is versioned in that branch? [00:29] abentley: still there? It seems to be dependant on the svn repo too, a push to a local file:// url worked fine. [00:29] yacc: kinda here. [00:29] james_w, yes, lets say I'm somewhere, and I want to now if this location is in a branch, and if so, get the branch root [00:30] I would expect it even works with more permissive SVN repos. [00:34] abentley: well, I'll be checking that now, gonna switch back first to bzr 1.3/bzr-svn stable for the experimenting. [00:35] thekorn: The branch root is Branch.base [00:35] thekorn: so you don't care what branch it's in, just that it is in one? [00:36] james_w, I would like to have a similar behaviour than 'bzr info' - if i call this somewhere in a branch i get the branch root, if I call this command outside a branch I get "Not a branch Error ...." [00:36] thekorn: do branch.Branch.open_containing(path)[0] then [00:37] that gets you the branch, if any, that contains path. You can then get the base. [00:37] If you want you can catch the NotBranchError. [00:37] do you also want to ensure that the path you were given is versioned by the branch that you get returned? [00:37] james_w, abentley , thanks alot this works [00:38] no i only need the branch root [00:38] thekorn: cool, you should be all set then. [00:38] thekorn: how are you finding it transitioning to use the API? [00:40] james_w, well I just started using bzrlib, [00:40] to be honest: it's hard without a real public API reference [00:41] but ipython does a good job [00:41] yeah, that's understandable. [00:41] #bzr is the API reference that I tend to reach for. [00:42] Ahhhh, how do I make bzr not check SSL certificates? [00:43] yacc: use urllib+ as a prefix for the URL. [00:43] yacc: although is this connecting to svn? [00:43] james_w, http://bazaar-vcs.org/Integrating_with_Bazaar is a good starting point to understand the general workflow, but needs some improvements [00:43] Oh, don't you curl is the solution :) [00:44] james_w: yeah, but I guess bzr checks the url first for a bzr target? [00:44] thekorn: yeah, I think it's quite new. It would be great to improve it. [00:44] yacc: yes I think so. [00:44] yacc: if you prefix the URL with svn+ then bzr doesn't probe it first. [00:44] for example the last part is switsching between 'branch' as a modul and 'branch' as a Branch-object [00:45] ah, that should be avoided. [00:46] Ok, it fails with my private https host too :( [00:47] thekorn: thanks, fixed. [00:48] james_w: what's the prefix for svn over ssh? [00:49] james_w, thanks, but same in "Getting a Revision object from a revision id" [00:50] yacc: svn+ssh:// I think [00:51] james_w: found it already ;) [00:51] abentley: svn+ssh:// does work against the same host where https:// does not work :( [00:51] thekorn: thanks again. [00:52] yacc: so you've actually got a solution, then? [00:52] No. [00:53] The svn repo I need to push to is hosted by a provider, so no ssh access ;( [00:53] But it might help figuring out why it does not work. [00:53] "the same host" as what? [00:54] abentley: I've tried it against a repo hosted on my private colo server, and it fails as usual against the https url, but works fine when doing the access over ssh. [00:54] Which suggests all kind of interesting things. [00:55] Seems quite strange. Maybe the security settings are different on ssh? [00:58] abentley: probably not. I have fine grained access controls on https, OTOH, svn+ssh has no access controls at all. [00:58] abentley: well, unix permissions, but if you don't have full write access to the whole repo, well, then usually even read-only operations break against that repo. [01:04] abentley: pong [01:04] yacc: hi [01:05] jelmer: yacc is running into some problems with bzr-svn and properties. [01:05] jelmer: I'm trying to track down the svn push problem. [01:05] I'm just pasting the apache logs from my server for the failing svn-push [01:07] jelmer: #190568 [01:07] The funny thing is that it's depending upon the transport layer. [01:07] Pushing to exactly the same repository via svn+ssh works fine. [01:07] Pushing via https breaks. [01:08] bug 190568 [01:08] Launchpad bug 190568 in bzr-svn "bzr-svn exception plugin error in commit" [Undecided,Incomplete] https://launchpad.net/bugs/190568 [01:08] yacc: interesting [01:08] yacc: do you have wireshark handy? [01:08] ethereal? [01:08] but it's https. [01:09] ah, ouch [01:09] I can install the repo on http too. [01:09] No sure, you are in the same timezone, how fresh are you. [01:10] btw, I've done the last tests with 1.3rc1 + tip of bzr-svn stable [01:10] but bzr 1.1rc1 + bzr-svn 0.4.7 has basically shown exactly the same behaviour through the day. [01:12] yacc: on windows ? [01:13] if so, you could use oSpy (and API level sniffer) to sniff https traffic [01:13] yacc: please update your bzr-svn checkout [01:13] yacc: and add -Dcommit during push [01:13] It's 2 hours or so old. [01:13] I've already done the -Dcommit. [01:14] It just produces the files + 3 properties. [01:14] jelmer: email address? [01:14] yacc: I just added the -Dcommit bit 5 seconds ago :-) [01:14] Well, def mutter checked for commit already in the old code? [01:15] yeah, but I just added some extra output for it [01:15] Ok, pulling the stuff. [01:16] I've changed the repo to http, so I can also run ethereal. :) [01:16] asabil: Technically, I've written an API level sniffer for Linux myself, but I don't like to use it, as I've written it for a customer so I cannot really distribute it, nor should I officially use it ;) [01:17] oh oki [01:18] asabil: well, at least the code generator for the intercepting stubs was written in Python ;) [01:18] jelmer: paste is ok for you? [01:19] yacc: yeah [01:19] http://rafb.net/p/Yy0yfm50.html [01:19] asabil: and guess what, the main usage was intercepting OpenSSL calls ;) [01:20] SSL can make debugging webstuff quite a PITA. [01:20] yacc: Ah, think I figured it out [01:20] jelmer: really? :)))))) [01:20] / is invalid in a file property [01:20] property name? [01:20] yeah [01:20] bzr-svn is using it [01:20] Why did it work via svn+ssh then? [01:21] *wonder* [01:21] subversion doesn't do validation [01:21] Oh, apache does ;) [01:21] probably because the name gets embedded somewhere in the URL ;) [01:21] And one / to much can break stuff. [01:21] but a / in a xml tag name messes with the subversion apache module [01:22] Anyway, any chance for a quick fix? [01:22] Just throwing a .encode("base64") would solve it in a completely incompatible way I guess ;( [01:26] I'm looking at it [01:26] yacc: it's not as simple as that [01:26] yacc: that will break older bzr-svn implementations [01:26] Yeah, I said incompatible. [01:27] but there is basically no way you can keep it compatible, because you cannot address these properties via http. So that calls probably for an config.ini option? [01:30] hmm, actually [01:30] this should be fixable without any changes [01:30] How so? [01:31] entity encoding in the XML? *wonder* [01:31] * yacc burns to test it out, I have four branches to deliver today ;) [01:36] jelmer? [01:37] Just curious what's your solution idea is. [01:41] yacc: trying to debug this, give me a few minutes [01:42] no problem :) [01:42] Anyway I can help? [01:45] jelmer: is there any bzr-svn to be used with 1.2 ? [01:59] yacc: not really atm [01:59] asabil: 0.4.7 [01:59] 0.4.8 you mean ? [02:00] jelmer: shall I also update the wiki page to add a link to 0.4.8 ? [02:00] asabil: 0.4.8 isn't out yet [02:01] asabil: I really mean 0.4.7 [02:01] http://samba.org/~jelmer/bzr/bzr-svn-0.4.8.tar.gz ? [02:01] Despite the fact that the wiki claims it's for 1.1 only? [02:01] asabil: Ah, crap [02:02] asabil: that should be gone now [02:02] asabil: It shouldn't be up there because it doesn't pass a few tests [02:02] yacc: yes, 0.4.7 works with 1.2 although it will warn you it may be out of date [02:02] :/ [02:02] asabil: you should be able to just use 0.4.7 though [02:02] jelmer: then the ppa package should be installable [02:04] asabil: I haven't had time for that, instead focussing on releasing a bzr-svn compatible with bzr 1.3 [02:04] okidoki [02:07] jelmer: as you are the source of all bzr-svn knowledge, is it useable for the daily usage as svn replacement? [02:07] When working against svn repos? [02:07] I think I've seen even support for svk:merge properties in the code :) [02:12] yacc: yeah, I use it for that [02:13] jelmer :) [02:17] jelmer: just wondering, on what time zone are you? [02:41] yacc: CET [03:11] I'll look into this further tomorrow === bigdo1 is now known as bigdot === bigdot is now known as bigdog === bigdog is now known as bigdogwithfourpa === bigdogwithfourpa is now known as bigdog === bitmonk is now known as nicbour [09:53] Hi all. [09:53] I'm trying to do bzr export planet http://www.gnome.org/~jdub/bzr/planet/2.0/ [09:54] But it dies with {{{ bzr: ERROR: Connection error: Couldn't resolve host 'www.gnome.org' (-2, 'Name or service not known') }}} after downloading a few files. [09:54] Why does it do another hostname lookup? [09:54] And it's very slow. [10:47] in bzr.dev lightweight checkout, I did "bzr --version" and it output "Bazaar (bzr) 1.4dev" then stalled and did much network access and then continued output. Can someone explain that? Is that unexpected? [11:09] which only has patches approved by the PQM: bzr.dev or lp:bzr? === kiko-afk is now known as kiko [11:40] i386: in bzr.dev lightweight checkout, I did "bzr --version" and it output "Bazaar (bzr) 1.4dev" then stalled and did much network access and then continued output. Can someone explain that? Is that unexpected? [11:40] i386: which only has patches approved by the PQM: bzr.dev or lp:bzr? [11:41] huh? [11:41] I dont know [11:45] i386: "huh?" did you not understand the first question? [11:45] dude, I dont know who you were talking to before [11:45] but it was not me [11:46] and I have jack idea about what your saying [11:46] I wasn't talking to anyone before. You're the first person to write anything to this channel since I 've been here. [11:46] right [11:46] I joined the room [11:46] nubbun: PQM is bzr.dev [11:47] And im not necessarily qualified [11:47] thanks dato [11:47] Perhaps ask your question of the mailing list? [11:47] dato: and lp:bzr is? [11:47] nubbun: and lightweight checkouts are not designed to be useful over network; mostly, to save space locally [11:47] nubbun: a mirror, I guess [11:49] I did a lightweight checkout of bzr.dev . When I do any operation using it, it accesses the network. [11:49] nubbun: dev versions of bzr always print some debugging info about the branch it's from [11:49] bzr version does a lot of network activity. [11:49] and to get that info from a lighweight checkout, it needs to ask the remote branch [11:49] it shouldn't do that much traffic, though [11:50] luks: do you know how I shut off network access from the dev branch? I'm usually offline. [11:50] don't use a lighweight checkout [11:50] or don't use bzr --version :) [11:50] or don't use the .dev branch :) [11:50] other operations also do network access, but not so much. bzr info also does network. [11:51] I think bzr version takes over a minute over dialup [11:51] only if you use a checkout of _your_ branch [11:51] bzr version is the same as bzr --version, which is about the bzr branch [11:52] I'm anticipating bzr branch lp:bzr will take forever. [11:52] really, if you are mostly offline, don't use checkouts [11:53] So I guess I just can't do it. I'll archive the .bzr directory, remove it and put it back when I wish to update. [11:53] nubbun: the dev branch talks to it's remote branch only on bzr --version [11:54] I guess you don't really need bzr --version for your work, do you? [11:54] bzr info also does net access. [11:54] for other comm [11:54] er [11:54] but that's expected [11:54] but that's not bzr.dev net access [11:54] well not really expected, but not surprizing. [11:54] that's network access for your branch [11:54] yes. [11:55] if you use lightweight checkouts, basically all commands will require network access [11:55] (not talking about bzr.dev and bzr --version here) [11:55] Thanks for your help, luks, nato! I'm going for now. [12:04] jelmer: Which version of pyrex are you using? [12:08] Hmph, obviously not 0.9.3, 0.9.6 works much better [12:10] awilkins: probably the most recent one [12:10] Yes, the most recent one actually manages to get to the hug elist of compiler errors [12:21] strings are immutable in python, so you can't adjust an array of them by doins for thing in array: sthing = sthing + 'stuff' no? [12:21] you can't modify an existing string (value) [12:22] but you can assign to a name a new value [12:22] so sthing = sthing + 'stuff' is legal [12:22] FOudn what I want, enumerate() [12:34] Hi all [12:35] I'm stuck with bzr 1.1~rc1-1... [12:36] New bug: #204607 in bzr "crash in 'bzr pull' when the network connection breaks" [Undecided,New] https://launchpad.net/bugs/204607 [12:38] (Due to more recent versions being incompatible with bzr-svn) [12:39] Lo-lan-do: guess who you have to prod :-P [12:41] I know, but I figure he's tired of being prodded. === doko_ is now known as doko [12:49] * yacc wonders if jelmer is a nightowl. [12:50] * grutte_pier has been wondering the same for some time [13:02] hmm, I'm experiencing some trouble with push, is there any way to increase the level of verbosity? [13:03] ~/.bzr.log might have more info [13:14] Only thing I'm seeing in the log is "45.348 not updating child fraction", but that's probably not what's causing my problems. [13:14] It's always like this: I push, have to ssh to my repository, break-lock and then push again and it works. [13:14] And I'm not getting any feedback that something's awry. [13:24] clarby: Those "-Dxxxx" parameters may be of use. [13:29] clarby: -Dlock -Devil -Dfetch [13:29] clarby: They're all listed in bzrlib/debug.py . [13:30] Ah, great [13:30] Thank you chad === kiko is now known as kiko-afk === bigdo1 is now known as bigdog [14:13] (and bzr help global-options) [14:44] abentley: ping [14:58] Unable to load plugin 'multiparent' from 'bzrlib/plugins' === mib_v2v62hnc is now known as ashyg [14:58] anyone ever see that? the bytecode file is in there [14:59] ashyg: the multiparent plugin was dropped a while ago [15:00] then why is it trying to load it/why did it pull it when i rsynces [15:00] rsynced [15:01] rsync -av --delete bazaar-vcs.org::bazaar-ng/bzr/bzr.dev bzr.dev [15:02] ls bzr.dev/bzrlib/plugins shows__init__.py __init__.pyc launchpad multiparent.pyc [15:03] running bzr whoami "myname " results in multiparent error [15:06] also can't bzr merge, says unable to load plugin multiparent [15:06] If I have a [15:06] bzr checkout http://bazaar-vcs.org/bzr/bzr.dev [15:06] why can't I do a [15:06] bzr pull lp:bzr [15:06] I get the error message [15:06] bzr: ERROR: Not a branch: "/path/bzr.dev/lp:/bzr/" [15:07] ashyg: are you specifically trying to use the multiparent plugin? [15:07] no [15:07] i just rsynced the latest version [15:07] do you have that plugin in the plugins directory? [15:07] yeah it came when i rsynced [15:07] should i rm it [15:07] the bzr.dev or 1.3? [15:08] i'm seeing usage of it other places though build/lib.linux-i686-2.5/bzrlib/versionedfile.py: mpvf = multiparent.MultiMemoryVersionedFile() [15:08] bzr.dev [15:09] i'll try 1.3 [15:09] ashyg: I think all the plugins have corresponding code in bzr even if they aren't shipped together. [15:09] as much as that is not what one would expect. [15:10] hey cool 1.3 works [15:10] alright thanks [15:10] ashyg: are you new to bzr? [15:10] The multiparent plugin has been gone for a long time. [15:10] (well, FSVO; a couple months, I think) [15:11] perhaps someone ( ashyg ) should file a bug? [15:12] yes i am new to bzr as of this morning, and yes perhaps a bug should be filed to have that pyc removed [15:12] I dunno. The bug might equally be that we still publish rsync instructions for it (if we do). [15:12] It's not standalone anymore. [15:13] ah. yes there are rsync instructions on the install wiki page [15:14] That's probably historical. Pull should be faster than rsync (at least, if the tree were still standalone, which is the main case where rsync made sense to begin with) [15:14] http://bazaar-vcs.org/Download [15:14] has instructions for rsync. Seems to be current use. [15:15] fullermd: pull not faster, but checkout --lightweight faster, right? [15:15] pull would get history info. [15:16] No, pull is faster than rsync on pack trees, because rsync ends up retransferring huge chunks of the history on a regular basis. [15:16] I guess it could still be faster if rsync also gets history inf. [15:16] bzr.dev used to be a standalone tree precisely SO that rsync would get the history down. [15:16] i don't have bzr on my system yet :) [15:16] oh, you mean for updates. [15:16] so i wget'd the tarball [15:17] Urf. Those rsync instructions SHOULD be dumped. The WT there is really, really, really old. [15:18] fullermd: do you know the answer to my question about pulling for a checkout? [15:19] Well, lightweight checkouts via a dumb server conceptually still require significant data transfer. Less than a full branch, but still a fair hunk. [15:19] If I have a [15:19] bzr checkout http://bazaar-vcs.org/bzr/bzr.dev [15:19] why can't I do a [15:19] bzr pull lp:bzr [15:19] ? I get the error message [15:19] bzr: ERROR: Not a branch: "/path/bzr.dev/lp:/bzr/" [15:19] A smart server can conceptually do it straight, but that cap isn't in place. [15:19] I wish to update my checkout from lp:bzr [15:20] because you hit a bug, that has been fixed in 1.3 [15:20] Well, pulling into a checkout is the wrong answer anyway. Even if it worked, it would fail. [15:20] but you really don't want pull in a checkout [15:20] just run "bzr update" [15:20] Why would you want to pull from the LP mirror in this case anyway? [15:20] luks: I just got the checkout of bzr.dev . Shouldn't it have the bugfix? [15:21] are you running bzr.dev? [15:21] yes. [15:21] hm, then yes [15:21] weird [15:22] I though the directory service stuff was added specifically to fix this [15:22] thought [15:24] in a checkout of bzr.dev, what _should_ a pull of lp:dev do? [15:24] I mean pull of lp:bzr [15:24] you shouldn't be pulling on a checkout [15:24] It would try to pull into the bzr.dev branch, which you can't write to, and so blow up. [15:25] but alas, you shouldn't have a checkout over a read-only transport in the first place [15:25] can't pull into because there is no working tree? [15:25] Oh, there are lots of good reasont to pull on a checkout; just none of them apply in this case :) [15:25] fullermd: yes [15:25] no, there is a working tree, but no history data [15:26] Why should one not do a checkout from a readonly transport? [15:27] (like https?) [15:27] One could. There's just rarely a particularly compelling case for it; the main use of checkouts implies writing. [15:28] I think the compelling case is that when you update, you don't need to re-download all files [15:28] * fullermd blinks. [15:29] That's like saying "We need pickles so that you don't die when falling out of an airplane" [15:31] There is a relation. To describe update from ro transport: read checksums or version identifiers or changesets or whatever. Compare with local archive to see what needs updating. Download what changed. [15:31] Er. pull doesn't "re-download" anything (well, nearly); it DOES grab just the updates since your last sync. [15:32] yes. That's what I said. [15:32] 'update' != 'pull' [15:33] pull affects versioning info & working tree, update only working tree, right? [15:33] Roughly, yah. [15:35] so a bzr update over http reduces data transfer compared to downloading a new version as an archive via http. That's the compelling reason to do a checkout over a readonly transport rather than other download via the readonly transport. [15:36] In that sense, maybe. But the usual question isn't "checkout vs. wget", it's "checkout vs. branch". [15:36] I'd lay odds the majority of published repos don't have WT's (or have wildly out of date WT's, like bzr.dev) in the first place. [15:36] to quote dato: but alas, you shouldn't have a checkout over a read-only transport in the first place [15:37] and I don't know why he would say that. [15:37] Because there's little point in using a checkout in that case; you'd just use branch. [15:37] the branch requires more downloading. [15:37] Oh, you're talking about a _lightweight_ checkout? [15:37] yes. [15:38] sorry [15:38] Doing that across the internet over a dumb server is suicide. You'll probably end up with MORE downloading over the long term. [15:39] Why? Wouldn't it mainly just retransfer changed files? [15:39] It has to read a potentially huge amoung of history information to find the changes. [15:39] (and even a huge amount, if ere khan tipe) [15:40] unfortunate. Not what I'd expect. [15:40] and there's no RO smart server? None is listed on the download page. [15:41] The smart server exists, but I don't know that any of the extant verbs help all that much in the lightweight checkout case. [15:41] Where they do, it's probably more fallout than intent; I don't think anybody's bothered trying to add to it for that use-case. [15:52] nubbun: The smart server is part of bzr and can be run in read-only mode [15:53] abentley: will updating a lightweight checkout via smart server reduce data transfer compared to downloading the next tar.gz? [15:54] For that matter will updating via HTTP? [15:54] abentley: hi [15:54] abentley: is there anything blocking Repository.get_revision_graph() from being deprecated in favor of Repository.get_graph() ? [15:54] nubbun: No one's run any tests on that. [15:56] jelmer: I don't know. [15:57] It get_revision_graph doesn't seem to be used in very many places. [15:58] If I have a lightweight checkout (say from bzr.dev) and I wish to update from another source, which may be another branch, is rebasing the right and only way to do that? [16:00] nubbun: Rebasing has nothing to do with checkouts or working trees. You want more like 'switch'. [16:00] fullermd: thank you. [16:04] nubbun: lightweight checkouts are intended to be used when you have local (LAN or hard disk) access to the source branch. Using them over the internet is going to be a world of pain. [16:13] jelmer: :) [16:14] jelmer: any hints how you plan to solve the / property problem? [16:17] Ah, something got commited to bzr-svn :) [16:17] The suspense is unbearable, ... [16:18] :( still an assert error :( [16:26] New bug: #183824 in bzr-svn "Use only one connection simultaneously to a Subversion repository" [Wishlist,Triaged] https://launchpad.net/bugs/183824 [16:27] hi all, I try to write sme scripts using bzrlib and i've got one question: [16:27] when should I /do i have to lock_read() a tree? [16:28] what's the reason behind this locks? [16:36] jelmer: could you please explain your ideas how to solve the bug in a compatible manner? This way I'd be able to quick&dirty code up something. [16:52] thekorn: I think they are to make sure that no-one messes the tree while you are reading it. [16:52] thekorn: I can't remember the current state of the lock infrastructure, but certainly at one point some of the lock_read() calls were no-ops. [16:57] james_w, whenever I do 'tree.get_file_text()' without the lock I get an Exception, so i added it there, [16:58] thekorn: it's probably a good idea to just grab the tree, and then lock it and try: finally: the rest of the code with the unlock in the finally block. [16:58] that should avoid you any problems. [16:59] right [16:59] ehm, i am reading bazaars sourcecode, and in msgeditor.py line 70 (in _run_editor), there is a check for an exit code of 127 (results in a continue statement, so that the next editor is tried). what does that code mean? as far as i know exit codes are not standardized, so --? [17:00] $ does-not-exist [17:00] $ echo $? [17:00] 127 [17:00] ah [17:00] I don't know if it's part of POSIX or something. [17:01] anyway, now it makes sense [17:01] bazaars source code is better than any book :) [17:02] oh and why does it else:break? shouldnt that be else:continue? [17:03] no it should not [17:03] nevermind [17:03] no, that's for the case when your editor runs but dies for some reason. [17:04] yeah, i had the weird idea of just trying another editor in that case. not a good idea... [17:05] nope [17:08] hi, can someone point me to the bits of the bzrlib API I'd need to extract metadata from a working directory? In particular, say to parse the log stream [17:09] http://bazaar-vcs.org/Integrating_with_Bazaar [17:09] walters: sorry, can you clarify what you mean by the log stream? [17:09] luks: that looks really useful, thanks! [17:09] james_w: output of "bzr log" [17:09] but if you have any specific questions, just ask [17:10] bzr log has fairly complex code behind it [17:10] james_w, Qhestion: I don't think "x == 127" is going to happen, call() would raise ENOENT instead [17:11] walters: so you can follow the revision pointers to get each individual revision and then read the message etc, or you can use show_log if you just want a formatted output like "bzr log". [17:11] walters: I'd be happy to give you pointers to help with either [17:11] hi dato [17:12] dato: it seems to check for ENOENT as well, so that's a little odd. [17:12] (well, it could happen if your editor is (as script that is) then exec'ing something which does not exist) [17:13] s/as/a/ [17:13] ah, thanks. [17:22] hm, how do i get the revision number from a Revision object? [17:23] walters: ah, that's harder, as a revision number is only defined relative to a particular mainline. [17:23] are you walking the mainline? [17:23] i have a working directory [17:23] anyway, give me one second and I should have a more helpful answer. [17:23] branch.revision_id_to_revno(r.revision_id) [17:23] i need to operate in terms of that, because my code is trying to generate statistics over the working tree for each revision [17:24] conceptually: for revision in reversed(revisions): bzr_revert(revision); generate_statistics() [17:24] luks: cool, thanks [17:24] where is "revisions" comming from? [17:25] walters: that's not the best way. [17:25] branch.revision_history() [17:25] then you don't need it at all [17:25] revision_history is linear [17:25] for revno, revision in enumerate(reversed(revisions)) [17:26] ah, that makes sense [17:26] hello [17:26] (or reversed, I'm not sure right now) [17:26] there's also iter_reverse_revision_history [17:27] which will return the first one to you quicker. [17:28] luks: did you see that jam put a version of your patch up for review? [17:28] yes [17:28] are you happy with how it ended up? [17:29] heh, no I was unhappy for very different reasons [17:29] the patch was there since december last year, completely ignored [17:29] yeah, I just wondered if you had any opinions on the final version. [17:29] now emacs developers complained how slow it is [17:29] and things happen... [17:29] yeah [17:30] but yeah, the patch looks much better than mine version [17:31] cool, at least we get a good improvement in the end, so it's not all bad. [17:51] jelmer: I got those pyrex bindings to build [17:52] Now to test the buggers..... [17:53] awilkins: nice work. [17:58] james_w: You have to hold it's hand and feed it all the library includes manually because Win32 doesn't have LOADLIB or whatever it is Linux uses [17:59] 403 Forbidden - Reading tree failed [18:00] there's still a pristine-tar branch there though, is that just old? [18:00] oops, sorry, wrong channel. [18:01] james_w, luks: thanks for the help, got my script working [18:02] walters: great. [18:06] jdong: bzr 1.3 just got ACCEPTED. [18:06] jdong: bzr 1.3-1 in Debian (currently in incoming.d.o). you'll have to check with james_w/jelmer what's up with bzr-svn [18:06] thanks dato [18:06] james_w: gaah, I was typing :-P [18:06] :-) [18:14] awilkins: ah, cool [18:16] jelmer: hi. Would you be happy for the latest bzr-svn in Debian to go in to Hardy? [18:17] jelmer: Alas, it doesn't complete the selftest [18:17] jelmer: It seems to have a deadlock in bzrlib.plugins.svn.tests.test_commit.RevpropTests.test_change_revprops [18:17] james_w: hardy has sid's [18:17] james_w: Yeah, that'd be fine [18:17] james_w: 0.4.8 hasn't been uploaded yet [18:17] jelmer: this is with 1.3 btw. [18:18] james_w: oh, there is nothing compatible with 1.3 out yet [18:18] james_w: 0.4.7 does not work with 1.3 [18:18] it breaks in quite a few cases [18:18] ah, ok, sorry. [18:18] 1.2 should be fine though [18:19] we'll wait for you then. [18:19] awilkins: oh, I'm not aware of any deadlocks [18:19] awilkins: it just segfaults here at the moment [18:19] I've got a patch waiting to be sponsored that removes the warning when used with 1.2, so either way hardy will end up with a working set. [18:23] james_w: yeah, I noticed. thanks for taking care of that [18:26] jelmer: no problem. It would be good to get this round of updates in, but if it doesn't at least it should all work well together. [18:29] dato / james_w: thanks for the update. Let me know how the plugins go :) [18:29] I know bzrtools is ready [18:31] jdong: yeah, we'll wait a few days to see if a 1.3 compatible bzr-svn arrives in time for it to be reasonable for hardy. [18:32] that sounds like a plan. [18:39] jelmer: That's odd, if you run just the test on it's own, it breaks into the debugger, but it just locks solid as part of the suite [18:39] Is it supposed to break into the debugger? [18:39] Or is that the CPython Win32 equivalent of a SEGFAULT [18:39] I may've left a "import pdb; pdb.set_trace()" statement somewhere [18:40] Aha, yes [18:40] Is that why the suite locks solid? [18:41] * awilkins starts suite again [18:47] New bug: #204759 in bzr-svn "AssertionError when committing" [Undecided,New] https://launchpad.net/bugs/204759 [18:52] jelmer: Are tests run sequentially from the source? [18:54] awilkins: yes [18:55] Just hit a segfault (or whatever causes a process to die) [18:56] that's a known issue [18:56] But I can't seem to reproduce it - would something that causes a "WindowsError" exception do that? [18:56] I actually also know what is causing it but I haven't found a way around it yet [18:56] awilkins: Not sure, I don't have too much experience with python on windows [18:56] And do the test names show up before or after they execute? Because the test named on STDERR passes if you run it solo [18:57] The one after causes a WindowsError [18:57] test names show up before they execute [18:57] That's weird then [18:58] it may not have printed all test names yet though [18:58] are you running with -v ? [18:59] no [19:00] I'm just running the whole of TestFetchWorks now [19:04] Ok, it seems to be test_fetch_trunk1 but it passes fine when run on it's own [19:06] New bug: #160335 in bzr-svn "--prefix could be determined from specified url" [Wishlist,Fix committed] https://launchpad.net/bugs/160335 [19:08] jelmer: It passes on its own but dies when you run it with the others [19:09] test_fetch_trunk1 [19:36] re [19:37] Ok, question ; Python2.5 sources have a "VS2005" build folder, if I use that to run python in debug mode, will it work with my extensions built on the 2003 compiler? [19:37] (probably not, eh?) [19:41] Not sure, sorry [20:09] Ah, I think I finally found the bug that was blocking 0.4.8 [20:19] awilkins: I don't think so, unless you manage to get them to link against the same C Runtime (which is damn hard to do) === juliank0 is now known as juliank [21:33] jelmer: ping [21:34] yacc: pong [21:34] Any progress? [21:34] Or a description of your clever idea? [21:35] I just pulled stable, and I'm getting still the assert exception. [21:37] jelmer: I'd be happy to help, but you claimed last night that you have a cool idea how to fix it in a backwards compatible way, ... [21:39] yacc: not really in a backwards compatible way but in a way that makes older clients not able to retrieve the revision but not corrupt them either [21:40] yacc: this problem only occurs for the single- branching scheme, which not a lot of people appear to be using [21:40] How can I switch the schema? [21:40] yacc: see "bzr help svn-branching-scheme" [21:41] So by switching the schema I could avoid this AssertionError? [21:41] yacc: the idea would be to start base64-ing the path in the single path branching scheme [21:41] and look at for both the base64-encoded name and the non-base64 encoded name to be able to deal with older revisions [21:41] yeah, assuming that one does not work through http. [21:42] I'd presume that one cannot get at the non-base64 property through http anyway ;( [21:42] yacc: yeah, that's correct [21:42] it seemed possible at some point to set / in properties over http but not possible to retrieve them later [21:42] but to help prioritize my work, switching the schema would make the assert go away? [21:44] Switching the scheme makes it impossible to push to your current branch in svn [21:44] jelmer: well, yeah, checking the "old" property name and converting it to the "new" property name would make sense to me. [21:44] Well, I have no current branch in svn ;) [21:44] yacc: in that case, using a different branching scheme should be fine [21:45] That's stuff that has started it's life in bzr, I just need to push it so the rest of the devels working with svn see it. [21:46] So what other branching schema can I switch to? [21:46] see "bzr help svn-branching-scheme" for details [21:51] Yeah, but I'm not completely grasping what options I do have. (I grasp the basic problem/idea, but I have no idea what over kind of schemes might make sense for me. [21:52] none/dir1/dir2/PackagePathWhereIPush [21:52] ? [21:53] yacc: not sure I understand what you mean [21:54] Well, I've got a path something like that: trunk/logs/LookeryBase <= LookeryBase does not exist yet. Nobody is using branches inside svn (that would not make much sense you know, branches and svn in one sentence evoke pain) [21:54] yacc: so, the branching scheme is basically list of branches inside the repository [21:56] No, actually, there are no branches, just trunk in the repository. [21:56] Now the bzr branch that I created locally, is "logically" part of the overall trunk of the svn repo. [21:56] yacc: In that case, just put "trunk" as single line in the branching scheme [21:57] thanks. [21:57] yacc: You can only push branches, you can't push into branches [21:57] Can I edit subversion.conf directly? [21:57] yeah, sure [21:57] What do you mean by " You can only push branches, you can't push into branches"? [21:58] I fear we have a term-overloading going on here between svn branches and bzr branches. [21:58] well, you can't push a bzr branch into /trunk/foo if you have /trunk as a branch [21:58] you can only push it into /trunk [22:00] Well, I want to push my local bzr branch that has not yet any representation in the svn world, to /trunk/logs/LookeryBase ? [22:00] why don't you push to /branches/whatever? [22:01] james_w: because my bzr is logically not a branch, just a new package inside the logical svn trunk. [22:01] My whole bzr branch are basically "files to add to the svn trunk, in some subdirectory". [22:01] yacc: in that case, /trnk/logs/LookeryBase is your branch in svn [22:03] Yeah, but where do I put that in subversion.conf? [22:03] Well, let me try it out. [22:04] * yacc was clever and created a complete throwaway https repo just for playing. [22:09] jelmer: http://rafb.net/p/ixuk7u60.html [22:12] Ok, setting the schema to None does not help either. === RAOF_ is now known as RAOF [22:28] jelmer: list-xxxx does not help either :( [22:38] re [22:43] yacc: please try again with new 0.4 [22:53] I just pulled from stable? Or do you mean something else? [22:54] jelmer: http://people.samba.org/bzr/jelmer/bzr-svn/stable/ [23:00] yacc: yeah, stable [23:00] stable is a symlink to 0.4 [23:00] I loosened the assertion a little bit [23:01] Should list-XXXX include paths like /test, /test/, test or test/? [23:02] Basically do I need slashes at the start/end? [23:08] jelmer: still the assert error, with no scheme selected in subversion.conf [23:08] :( [23:08] yacc: what version of the 0.4 branch are you using? [23:08] yacc: No scheme selected? [23:08] yacc: that probably means it's going to use the same scheme you were using earlier [23:08] there is no such thing as no scheme.. [23:13] jelmer: [23:13] Tree is up to date at revision 969. [23:13] no scheme: [23:13] [40f52546-0a3c-0410-aace-d8ec0cfe4f10] [23:13] locations = svn+https://andreas:qwertz@heaven.kostyrka.org/krit/repo [23:14] I just removed the repo completely from subversion.conf, and bzr-svn did not enter a scheme when it detected the repo. [23:14] yacc: It still uses a branching scheme though [23:15] yacc: try "bzr svn-branching-scheme " [23:18] andreas@andi-lap:~/lookery/lookery> bzr svn-branching-scheme svn+https://andreas:qwertz@heaven.kostyrka.org/krit/repo [23:18] andreas@andi-lap:~/lookery/lookery> [23:18] Funny thing, got lost in the paste. [23:18] the above outputs exactly two empty lines. [23:20] yacc: in that case it will probably refuse to push anywhere [23:21] jelmer: yeah, but what should I do? [23:23] yacc: You can change the branching scheme using the svn-branching-scheme subcommand [23:23] I've do I need to set the scheme myself? [23:23] To what? [23:24] trunk => would make only /krit/repo/ a branch that I can push to, which is wrong. [23:25] list-XXXX? I don't think it's meant this way, importing scheme.py and str(ListBranchingScheme(["path1", "path2"]))? [23:26] yacc: Use bzr svn-branching-scheme --set [23:27] What url should I provide? [23:27] http://host/repopath/pathinrepo? [23:27] no, just the repo url [23:28] in the editor that then opens you can list the paths in the repo bzr-svn should consider branches [23:28] Oh no! [23:28] Peng: ? [23:28] Python has an official mirror of some of their svn branches in bzr two days after I do it myself. [23:28] http://www.python.org/dev/bazaar [23:29] ooh, nice [23:30] jelmer: should I also list paths that I plan to use as a branch that do not exist yet? [23:31] yacc: yes [23:31] jelmer: ok, new try ;( [23:31] still the assert error. [23:31] yacc: what's the revno of stable you have? [23:31] Hmmm. [23:32] If those were done with bzr-svn, they have the same revids as my local conversion, right? [23:32] It updated to 970 now, before it was 969 [23:33] jelmer: still the same. [23:33] :( [23:33] Peng: Yep, should be [23:33] 7.861 adding branch dir 'testB' [23:33] 8.898 open dir 'lookery' [23:33] 8.898 open dir 'lookery/scripts' [23:33] 8.899 open file 'lookery/scripts/llfp.py' [23:33] 9.082 Traceback (most recent call last): [23:33] yacc: Please try with 971 [23:33] that should print the property name that failed [23:34] :) [23:34] jelmer: I'm using a fresh path on each test, ... [23:35] you forgot %s [23:35] Now I get a TypeError: [23:35] assert is_valid_property_name(prop), "Invalid property name" % prop [23:35] TypeError: not all arguments converted during string formatting [23:35] ah, crap [23:35] r972 :-) [23:37] AssertionError: Invalid property name 'bzr:revision-id:v3-single-test/lookery' [23:37] yacc: Looks like you're still using a branching scheme with a single branch, i.e. the bit that's failing [23:37] Which is funny, because lookery is not even there in the path I'm trying to push to, guess it's a branch nick or something. [23:37] yacc: please specify more than one path so it uses the list- one [23:37] I've specified 5 paths. [23:38] test9 .. testD [23:38] on seperate lines. [23:38] Yep, they do seem to have the same revids. Yay. [23:38] yacc: and you're pushing to one of those? [23:38] branching-scheme = list-QlpoOTFBWSZTWdCduU8AAAzNgAAQACA8AAIADAAgACEkA0IMmIyavGI5DQ0eLuSKcKEhoTtyng.. [23:38] yes. [23:38] I don't have to download the whole repo again then. [23:38] yacc: what url are you pushing to? [23:38] you're runinng something like "bzr push /test9" ? [23:39] I've put in testD and I'm pushing to: 'svn+https://andreas:qwertz@heaven.kostyrka.org/krit/repo/testD/' [23:39] svn-push [23:39] but yes. [23:39] leaving off the last slash does not help either. [23:39] right, that shouldn't matter [23:40] AssertionError: Invalid property name 'bzr:revision-id:v3-single-test/lookery' [23:40] running bzr svn-branching-scheme on the URL gives the test9-testD lines, and one empty line at the end. [23:42] jelmer: would the Apache log help? [23:42] yacc: no, that's not at all relevant [23:43] Well, bzr-svn did set branching-scheme-mandatory = True this time, ... [23:43] yacc: I wonder what is setting that property since it doesn't appear to be related to your branching scheme [23:43] It looks like the nick of my bzr branch? [23:43] How can I check that? [23:44] The branch is in a directory named lookery. [23:45] jelmer, let's see what properties get added. [23:45] yacc: it looks like it's thinking you're trying to push to test/lookery inside of the svn repository [23:46] http://rafb.net/p/l3S2si25.html [23:46] jelmer no such thing. [23:47] yacc: I mean, in svn [23:47] yacc: There doesn't happen to be a branch in svn with that name? [23:48] Yes there is. [23:48] But it's not a branch afaik. [23:49] andreas@andi-lap:~/lookery/lookery> svn ls https://heaven.kostyrka.org/krit/repo/test/lookery/ [23:49] svn: PROPFIND Anfrage fehlgeschlagen auf »/krit/repo/!svn/bc/9/test/lookery« [23:49] svn: PROPFIND von »/krit/repo/!svn/bc/9/test/lookery«: 207 Multi-Status (https://heaven.kostyrka.org) [23:49] Now isn't that peachy? [23:49] Guess a svnadmin create would be now a good idea? [23:49] yacc: right, that happens if a property is set once with a bad character in it [23:50] jelmer: yeah, but I'm not refering to /test/lookery at all. [23:50] I'm trying to push to /test? [23:50] Should I nuke the repo? [23:50] yacc: it may still remember you had a revision there [23:50] Who would remember that? [23:50] yacc: Yeah, I would recommend recreating it [23:50] bzr-svn? [23:50] yacc: ~/.bazaar/svn-cache/ [23:51] Well, I can try to nuke svn-cache first? [23:51] sure [23:52] svn must be really quite fast. svk has an internal hidden cache too. [23:53] It pushes, it seems ;) [23:53] revision 2/6 [23:53] 3/6 [23:53] 4/6 [23:53] Haha, bzr missing between two copies of Python's bzr branch took several minutes. [23:53] 5/6 [23:54] Cool it worked :) [23:54] Peng: yeah, I don't think it has been performance tuned yet [23:54] jelmer: btw, do I need to specify a password on the push URL, or does bzr-svn use the svn "password caching" mechanisms? [23:55] yacc: it uses the svn password caching [23:55] jelmer: Wait, when bzr-svn switches to Pyrex, what will the build dependencies be? [23:56] Peng: A C compiler and libsvn-dev [23:56] jelmer: what are you planning to use Pyrex (or probably Cython) for? [23:57] yacc: for bzr-svn own python bindings of subversion [23:57] yacc: rather than using python-subversion [23:57] jelmer: :) [23:58] jelmer: my experience suggests that you should probably prefer Cython over Pyrex, but beside that sounds like a plausible idea ;) [23:59] yacc: cython generates larger files, which is why I prefer pyrexc as long as I don't need any of the features pyrex lacks [23:59] so far it looks like both should work with the bzr-svn .pyx files though [23:59] jelmer: like a nice package support?