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