| 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:07 |
|---|---|---|
| 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:11 |
| 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:15 |
| nekohayo | hmm, any reason why bzr-gtk in ubuntu hardy only seems to provide olive, no nautilus integration? | 00:16 |
| 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:27 |
| 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:28 |
| 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:29 |
| abentley | I would expect it even works with more permissive SVN repos. | 00:30 |
| yacc | abentley: well, I'll be checking that now, gonna switch back first to bzr 1.3/bzr-svn stable for the experimenting. | 00:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:40 |
| 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:41 |
| yacc | Ahhhh, how do I make bzr not check SSL certificates? | 00:42 |
| 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:43 |
| 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:44 |
| james_w | ah, that should be avoided. | 00:45 |
| yacc | Ok, it fails with my private https host too :( | 00:46 |
| james_w | thekorn: thanks, fixed. | 00:47 |
| yacc | james_w: what's the prefix for svn over ssh? | 00:48 |
| thekorn | james_w, thanks, but same in "Getting a Revision object from a revision id" | 00:49 |
| james_w | yacc: svn+ssh:// I think | 00:50 |
| 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:51 |
| abentley | yacc: so you've actually got a solution, then? | 00:52 |
| yacc | No. | 00:52 |
| 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:53 |
| 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:54 |
| abentley | Seems quite strange. Maybe the security settings are different on ssh? | 00:55 |
| 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. | 00:58 |
| jelmer | abentley: pong | 01:04 |
| jelmer | yacc: hi | 01:04 |
| 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:05 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| asabil | yacc: on windows ? | 01:12 |
| 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:13 |
| 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:14 |
| jelmer | yeah, but I just added some extra output for it | 01:15 |
| yacc | Ok, pulling the stuff. | 01:15 |
| 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:16 |
| asabil | oh oki | 01:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:26 |
| 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:27 |
| jelmer | hmm, actually | 01:30 |
| jelmer | this should be fixable without any changes | 01:30 |
| yacc | How so? | 01:30 |
| yacc | entity encoding in the XML? *wonder* | 01:31 |
| * yacc burns to test it out, I have four branches to deliver today ;) | 01:31 | |
| yacc | jelmer? | 01:36 |
| yacc | Just curious what's your solution idea is. | 01:37 |
| jelmer | yacc: trying to debug this, give me a few minutes | 01:41 |
| yacc | no problem :) | 01:42 |
| yacc | Anyway I can help? | 01:42 |
| asabil | jelmer: is there any bzr-svn to be used with 1.2 ? | 01:45 |
| jelmer | yacc: not really atm | 01:59 |
| jelmer | asabil: 0.4.7 | 01:59 |
| asabil | 0.4.8 you mean ? | 01:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:04 |
| 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:07 |
| jelmer | yacc: yeah, I use it for that | 02:12 |
| yacc | jelmer :) | 02:13 |
| yacc | jelmer: just wondering, on what time zone are you? | 02:17 |
| jelmer | yacc: CET | 02:41 |
| jelmer | I'll look into this further tomorrow | 03:11 |
| === 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 | ||
| rindolf | Hi all. | 09:53 |
| rindolf | I'm trying to do bzr export planet http://www.gnome.org/~jdub/bzr/planet/2.0/ | 09:53 |
| 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. | 09:54 |
| 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? | 10:47 |
| nubbun | which only has patches approved by the PQM: bzr.dev or lp:bzr? | 11:09 |
| === kiko-afk is now known as kiko | ||
| 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:40 |
| i386 | huh? | 11:41 |
| i386 | I dont know | 11:41 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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. | 11:55 |
| awilkins | jelmer: Which version of pyrex are you using? | 12:04 |
| awilkins | Hmph, obviously not 0.9.3, 0.9.6 works much better | 12:08 |
| 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:10 |
| 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:21 |
| 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:22 |
| Lo-lan-do | Hi all | 12:34 |
| Lo-lan-do | I'm stuck with bzr 1.1~rc1-1... | 12:35 |
| ubotu | New bug: #204607 in bzr "crash in 'bzr pull' when the network connection breaks" [Undecided,New] https://launchpad.net/bugs/204607 | 12:36 |
| Lo-lan-do | (Due to more recent versions being incompatible with bzr-svn) | 12:38 |
| dato | Lo-lan-do: guess who you have to prod :-P | 12:39 |
| Lo-lan-do | I know, but I figure he's tired of being prodded. | 12:41 |
| === doko_ is now known as doko | ||
| * yacc wonders if jelmer is a nightowl. | 12:49 | |
| * grutte_pier has been wondering the same for some time | 12:50 | |
| clarby | hmm, I'm experiencing some trouble with push, is there any way to increase the level of verbosity? | 13:02 |
| luks | ~/.bzr.log might have more info | 13:03 |
| 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:14 |
| chadmiller | clarby: Those "-Dxxxx" parameters may be of use. | 13:24 |
| chadmiller | clarby: -Dlock -Devil -Dfetch | 13:29 |
| chadmiller | clarby: They're all listed in bzrlib/debug.py . | 13:29 |
| clarby | Ah, great | 13:30 |
| clarby | Thank you chad | 13:30 |
| === kiko is now known as kiko-afk | ||
| === bigdo1 is now known as bigdog | ||
| james_w | (and bzr help global-options) | 14:13 |
| jelmer | abentley: ping | 14:44 |
| mib_v2v62hnc | Unable to load plugin 'multiparent' from 'bzrlib/plugins' | 14:58 |
| === mib_v2v62hnc is now known as ashyg | ||
| ashyg | anyone ever see that? the bytecode file is in there | 14:58 |
| dato | ashyg: the multiparent plugin was dropped a while ago | 14:59 |
| ashyg | then why is it trying to load it/why did it pull it when i rsynces | 15:00 |
| ashyg | rsynced | 15:00 |
| ashyg | rsync -av --delete bazaar-vcs.org::bazaar-ng/bzr/bzr.dev bzr.dev | 15:01 |
| ashyg | ls bzr.dev/bzrlib/plugins shows__init__.py __init__.pyc launchpad multiparent.pyc | 15:02 |
| ashyg | running bzr whoami "myname <my@email.com>" results in multiparent error | 15:03 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| nubbun | perhaps someone ( ashyg ) should file a bug? | 15:11 |
| 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:12 |
| ashyg | ah. yes there are rsync instructions on the install wiki page | 15:13 |
| 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:14 |
| nubbun | fullermd: pull not faster, but checkout --lightweight faster, right? | 15:15 |
| nubbun | pull would get history info. | 15:15 |
| 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:16 |
| fullermd | Urf. Those rsync instructions SHOULD be dumped. The WT there is really, really, really old. | 15:17 |
| nubbun | fullermd: do you know the answer to my question about pulling for a checkout? | 15:18 |
| 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:19 |
| 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:20 |
| luks | are you running bzr.dev? | 15:21 |
| nubbun | yes. | 15:21 |
| luks | hm, then yes | 15:21 |
| luks | weird | 15:21 |
| luks | I though the directory service stuff was added specifically to fix this | 15:22 |
| luks | thought | 15:22 |
| 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:24 |
| 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:25 |
| nubbun | Why should one not do a checkout from a readonly transport? | 15:26 |
| 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:27 |
| 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:28 | |
| fullermd | That's like saying "We need pickles so that you don't die when falling out of an airplane" | 15:29 |
| 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:31 |
| nubbun | yes. That's what I said. | 15:32 |
| fullermd | 'update' != 'pull' | 15:32 |
| nubbun | pull affects versioning info & working tree, update only working tree, right? | 15:33 |
| fullermd | Roughly, yah. | 15:33 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| abentley | nubbun: The smart server is part of bzr and can be run in read-only mode | 15:52 |
| nubbun | abentley: will updating a lightweight checkout via smart server reduce data transfer compared to downloading the next tar.gz? | 15:53 |
| 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:54 |
| abentley | jelmer: I don't know. | 15:56 |
| abentley | It get_revision_graph doesn't seem to be used in very many places. | 15:57 |
| 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? | 15:58 |
| fullermd | nubbun: Rebasing has nothing to do with checkouts or working trees. You want more like 'switch'. | 16:00 |
| nubbun | fullermd: thank you. | 16:00 |
| 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:04 |
| yacc | jelmer: :) | 16:13 |
| yacc | jelmer: any hints how you plan to solve the / property problem? | 16:14 |
| yacc | Ah, something got commited to bzr-svn :) | 16:17 |
| yacc | The suspense is unbearable, ... | 16:17 |
| yacc | :( still an assert error :( | 16:18 |
| ubotu | New bug: #183824 in bzr-svn "Use only one connection simultaneously to a Subversion repository" [Wishlist,Triaged] https://launchpad.net/bugs/183824 | 16:26 |
| 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:27 |
| thekorn | what's the reason behind this locks? | 16:28 |
| 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:36 |
| 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:52 |
| thekorn | james_w, whenever I do 'tree.get_file_text()' without the lock I get an Exception, so i added it there, | 16:57 |
| 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:58 |
| 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 --? | 16:59 |
| 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:00 |
| Qhestion | anyway, now it makes sense | 17:01 |
| Qhestion | bazaars source code is better than any book :) | 17:01 |
| Qhestion | oh and why does it else:break? shouldnt that be else:continue? | 17:02 |
| 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:03 |
| Qhestion | yeah, i had the weird idea of just trying another editor in that case. not a good idea... | 17:04 |
| james_w | nope | 17:05 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| dato | s/as/a/ | 17:13 |
| james_w | ah, thanks. | 17:13 |
| walters | hm, how do i get the revision number from a Revision object? | 17:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| james_w | which will return the first one to you quicker. | 17:27 |
| 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:28 |
| 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:29 |
| luks | but yeah, the patch looks much better than mine version | 17:30 |
| james_w | cool, at least we get a good improvement in the end, so it's not all bad. | 17:31 |
| awilkins | jelmer: I got those pyrex bindings to build | 17:51 |
| awilkins | Now to test the buggers..... | 17:52 |
| james_w | awilkins: nice work. | 17:53 |
| 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:58 |
| james_w | 403 Forbidden - Reading tree failed | 17:59 |
| james_w | there's still a pristine-tar branch there though, is that just old? | 18:00 |
| james_w | oops, sorry, wrong channel. | 18:00 |
| walters | james_w, luks: thanks for the help, got my script working | 18:01 |
| james_w | walters: great. | 18:02 |
| 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:06 |
| jelmer | awilkins: ah, cool | 18:14 |
| james_w | jelmer: hi. Would you be happy for the latest bzr-svn in Debian to go in to Hardy? | 18:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| jelmer | james_w: yeah, I noticed. thanks for taking care of that | 18:23 |
| 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:26 |
| jdong | dato / james_w: thanks for the update. Let me know how the plugins go :) | 18:29 |
| jdong | I know bzrtools is ready | 18:29 |
| 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:31 |
| jdong | that sounds like a plan. | 18:32 |
| 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:39 |
| awilkins | Aha, yes | 18:40 |
| awilkins | Is that why the suite locks solid? | 18:40 |
| * awilkins starts suite again | 18:41 | |
| ubotu | New bug: #204759 in bzr-svn "AssertionError when committing" [Undecided,New] https://launchpad.net/bugs/204759 | 18:47 |
| awilkins | jelmer: Are tests run sequentially from the source? | 18:52 |
| jelmer | awilkins: yes | 18:54 |
| awilkins | Just hit a segfault (or whatever causes a process to die) | 18:55 |
| 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:56 |
| 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:57 |
| jelmer | it may not have printed all test names yet though | 18:58 |
| jelmer | are you running with -v ? | 18:58 |
| awilkins | no | 18:59 |
| awilkins | I'm just running the whole of TestFetchWorks now | 19:00 |
| awilkins | Ok, it seems to be test_fetch_trunk1 but it passes fine when run on it's own | 19:04 |
| ubotu | New bug: #160335 in bzr-svn "--prefix could be determined from specified url" [Wishlist,Fix committed] https://launchpad.net/bugs/160335 | 19:06 |
| awilkins | jelmer: It passes on its own but dies when you run it with the others | 19:08 |
| awilkins | test_fetch_trunk1 | 19:09 |
| jelmer | re | 19:36 |
| 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:37 |
| jelmer | Not sure, sorry | 19:41 |
| jelmer | Ah, I think I finally found the bug that was blocking 0.4.8 | 20:09 |
| 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) | 20:19 |
| === juliank0 is now known as juliank | ||
| yacc | jelmer: ping | 21:33 |
| jelmer | yacc: pong | 21:34 |
| yacc | Any progress? | 21:34 |
| yacc | Or a description of your clever idea? | 21:34 |
| yacc | I just pulled stable, and I'm getting still the assert exception. | 21:35 |
| 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:37 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:44 |
| 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:45 |
| yacc | So what other branching schema can I switch to? | 21:46 |
| jelmer | see "bzr help svn-branching-scheme" for details | 21:46 |
| 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:51 |
| yacc | none/dir1/dir2/PackagePathWhereIPush | 21:52 |
| yacc | ? | 21:52 |
| jelmer | yacc: not sure I understand what you mean | 21:53 |
| 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:54 |
| 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:56 |
| 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:57 |
| 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 | 21:58 |
| 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:00 |
| 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:01 |
| yacc | Yeah, but where do I put that in subversion.conf? | 22:03 |
| yacc | Well, let me try it out. | 22:03 |
| * yacc was clever and created a complete throwaway https repo just for playing. | 22:04 | |
| yacc | jelmer: http://rafb.net/p/ixuk7u60.html | 22:09 |
| yacc | Ok, setting the schema to None does not help either. | 22:12 |
| === RAOF_ is now known as RAOF | ||
| yacc | jelmer: list-xxxx does not help either :( | 22:28 |
| jelmer | re | 22:38 |
| jelmer | yacc: please try again with new 0.4 | 22:43 |
| yacc | I just pulled from stable? Or do you mean something else? | 22:53 |
| yacc | jelmer: http://people.samba.org/bzr/jelmer/bzr-svn/stable/ | 22:54 |
| 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:00 |
| yacc | Should list-XXXX include paths like /test, /test/, test or test/? | 23:01 |
| yacc | Basically do I need slashes at the start/end? | 23:02 |
| 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:08 |
| 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:13 |
| 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:14 |
| jelmer | yacc: try "bzr svn-branching-scheme <repo-url>" | 23:15 |
| 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:18 |
| jelmer | yacc: in that case it will probably refuse to push anywhere | 23:20 |
| yacc | jelmer: yeah, but what should I do? | 23:21 |
| 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:23 |
| yacc | trunk => would make only /krit/repo/ a branch that I can push to, which is wrong. | 23:24 |
| yacc | list-XXXX? I don't think it's meant this way, importing scheme.py and str(ListBranchingScheme(["path1", "path2"]))? | 23:25 |
| jelmer | yacc: Use bzr svn-branching-scheme --set <url> | 23:26 |
| yacc | What url should I provide? | 23:27 |
| yacc | http://host/repopath/pathinrepo? | 23:27 |
| jelmer | no, just the repo url | 23:27 |
| 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:28 |
| jelmer | ooh, nice | 23:29 |
| yacc | jelmer: should I also list paths that I plan to use as a branch that do not exist yet? | 23:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| yacc | :) | 23:34 |
| yacc | jelmer: I'm using a fresh path on each test, ... | 23:34 |
| 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:35 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| yacc | jelmer: would the Apache log help? | 23:42 |
| jelmer | yacc: no, that's not at all relevant | 23:42 |
| 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:43 |
| yacc | The branch is in a directory named lookery. | 23:44 |
| 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:45 |
| yacc | http://rafb.net/p/l3S2si25.html | 23:46 |
| yacc | jelmer no such thing. | 23:46 |
| jelmer | yacc: I mean, in svn | 23:47 |
| jelmer | yacc: There doesn't happen to be a branch in svn with that name? | 23:47 |
| yacc | Yes there is. | 23:48 |
| yacc | But it's not a branch afaik. | 23:48 |
| 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:49 |
| 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:50 |
| yacc | Well, I can try to nuke svn-cache first? | 23:51 |
| jelmer | sure | 23:51 |
| yacc | <philosophical-rant>svn must be really quite fast. svk has an internal hidden cache too.</rant> | 23:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| jelmer | Peng: A C compiler and libsvn-dev | 23:56 |
| yacc | jelmer: what are you planning to use Pyrex (or probably Cython) for? | 23:56 |
| jelmer | yacc: for bzr-svn own python bindings of subversion | 23:57 |
| jelmer | yacc: rather than using python-subversion | 23:57 |
| yacc | jelmer: :) | 23:57 |
| yacc | jelmer: my experience suggests that you should probably prefer Cython over Pyrex, but beside that sounds like a plausible idea ;) | 23:58 |
| 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? | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!