[00:04] jfroy|work: theres an option to log, I think [00:04] Or API to get to it. I'm basically trying to write a plug-in that adds a --fixes scheme for my company's bug tracker and also a post-commit hook that will add a message to the bug if the commit includes the --fixes metadata. [00:04] adding the --fixes scheme was trivial [00:04] (just another UniqueIntegerBugTracker) [00:05] the revision.properties [00:05] well --long doesn't do it [00:06] in your post commit hook [00:06] nice [00:06] I'm trying right now just to check if the metadata was recorded [00:06] print branch.repository.get_revision(revision_id).properties [00:06] There has to be a command to inspect a revision, even a debug command of some kind [00:07] time to break out a python shell huh [00:07] fair enough :) [00:07] cat-revision [00:07] ha, like the name :) [00:13] huh, log doesn't print the revision ID [00:13] --show-ids, nvm [00:16] And right now, it seems the property value will be hardcoded to "$BUG_URL fixed" [00:17] And stored with the key 'bugs' [00:18] Which seems to be a magic constant in the builtin commit command, which has me worried one day someone will change that and the plug-in will break [00:18] Dumb question: currently when I want to add files to bzr, I basically run bzr st -S . | grep "^?" | awk '{print $2}' | xargs bzr add. Is there a better way of doing this, besides maybe aliasing said command? [00:25] jfroy|work: its not part of commit; its part of the bug module [00:25] pydoc bzrlib.bugtracker [00:26] KhaZ: 'bzr add' [00:26] ... D'oh. It is quite possible I'm that much of an idiot. [00:27] lifeless: the 'fixed' part yes [00:27] but not the property name [00:28] the property name won't change [00:28] or if it did the query api in bugtracker would be adjusted to support reading from both [00:29] I'm saying, its no more or less at risk of changing than any metadata [00:30] I don't see any code in the bugtracker module that ever reads a revision property [00:30] there's stuff in qbzr [00:30] it will probably mgirate to the core at some point [00:31] I see [00:31] lifeless: 'kk (+trunk to 2.0 and 2.0.0) [00:31] spm: 2.0 to 2.0, and 2.0.0 to 2.0.0 :) [00:31] spm: pushing trunk to 2.0 would be bad ;P [00:32] So it should be relatively safe for the hook to look for the 'bug' property (as a constant key value, not as a constant imported from bzrlib) [00:32] heh. that's not what I meant :-) [00:32] jfroy|work: yes [00:32] jfroy|work: 'bugs' [00:32] * 'bugs' [00:32] damn, beat me to it :p [00:39] lifeless: so. 2.0: 4665 pushed, vs 4664; 2.0.0: 4667 vs 4665. no changes needed to locations. [00:39] spm: thanks [00:39] jam: ^ [01:03] Good morning. [01:17] hi all [01:17] hi spiv, lifeless [01:18] maybe i should change the 'compiled extensions' warning to say "if you're running from a bzr source directory, run 'make'" [01:24] poolie: good morning. Thanks for starting the review of the hpss homedirs patch. I forgot to mention that part of the diff (mainly pathfilter.py) is in a separate review (which has been approved now). [01:24] np, i saw robert's verbal approval [01:24] of that [01:24] if you want me to read it too i can [01:25] I wouldn't bother if I were you :) [01:45] Okay, assuming that I don't go to the 2a format right now, what's the best format for a repository that I will have to maintain well into the future, right now? [01:45] And that random people, including our users, might be checking out from. [01:46] (Which is why I don't want to go 2a right now--I need relatively good backwards-compatibility so that users can get at the repo.) [01:46] I'm asking because Bugzilla picked bzr over Hg, BTW. [01:52] hi mkanat [01:53] that's great news btw [01:53] mkanat: i'd probably go for 1.9 [01:53] it's faster and smaller than earlier formats [01:53] and it'll be supported by bzr releases going back, of course, to 1.9 [01:54] poolie: That sounds pretty good. And that will be upgradable to 2a in the future? [01:54] which is nearly a year ago now [01:54] yes [01:54] * mkanat nods. [01:54] Okay, cool. [01:54] and 2.0 will support it [01:54] so in your case i'd probably be suggesting people install 2.0.0 (or 2.0.x later) [01:54] which will be a bugfix-only series [01:55] but use 1.9, for interoperation with older releases [01:55] Okay. [01:55] Some people won't be able to install 2.0 very easily. [01:55] But everybody should be able to get 1.9. [01:55] At least. :-) [01:55] (For example, Bugzilla still works on RHEL4, but that only has python 2.3.) [01:56] mkanat: why would 2.0 be hard to install? [01:56] mkanat: 1.9-rich-root [01:56] mkanat: if you don't go 2a [01:56] mkanat: the rich root will make moving to 2a easier [01:56] poolie: Is there any way yet of reconciling two separate cvs imports and saying "these are actually the same, and these commits match to these commits and these files match to these files"? [01:56] mkanat: no [01:57] mkanat: bzr has only ever supported python 2.4 and up, FWIW [01:57] lifeless: Hmm, ever? Okay. :-) [01:57] mkanat: CVS -> bzr is non-deterministic [01:58] davidstrauss: Yes, but it would be nice if I could re-do my import, because some of it's messed up. [01:59] Due to the fact that we started it with an older bzr and an older cvsps_import. [01:59] mkanat: There's also no way in bzr for a single file to have multiple UUID ancestors [01:59] davidstrauss: But without breaking people who have already checked out from the existing bzr import (which is a lot of people including all my client work). [01:59] mkanat: so merging two branches with the same files and different bzr ancestry is a non-starter [02:00] mkanat: you could "merge" into the repo and resolve all conflicts in favor of the incoming files [02:00] mkanat: then you'd pick up the file UUIDs from the branch being merged in [02:00] davidstrauss: That would break merging back into the older checkouts, though, right? [02:00] I mean, I don't see any advantage. [02:00] mkanat: correct. you can't maintain ancestry in both directions [02:00] Ah well. [02:00] mkanat: it's an architectural limitation i've discussed with aaron bentley [02:01] mkanat: if you can get all your users to help switch, it may be feasible [02:01] you'd need to tell them to just cherrypick across from their existing branches into new ones based on the new import [02:02] poolie: The actual user base is fairly small, so it might be possible. [02:02] poolie: That is, my *main* concern is all the work I have in client branches. [02:02] poolie: re the extensions nag [02:02] And the work I did with NASA. [02:02] per-client forks [02:03] poolie: Yeah. [02:03] poolie: I suggest: make bzr --version show the full list of missing extensions, and have the nag be a one-liner: 'One or more C extensions could not be loaded. See bzr help C-extensions' [02:04] poolie: So we'd do the import by basically just applying each patch of each revision individually, and copying the log message? [02:05] lifeless: i agree about the nag [02:05] mkanat: you *might* be able to use rebase for some of it ? [02:05] mkanat: right, and bzr-rebase may be able to help [02:05] or, you can just fold them all up into one commit, depending how much resolution you want to keep [02:05] rebase still follows fileids [02:05] poolie: Okay. In that case, next question--is there a better existing CVS importer that can do branches and branch relations than cvsps_import now? [02:05] lifeless: oh, right, dang [02:05] lifeless: the hard part is making --version show them: --version won't normally know all of the extensions we might want toload [02:06] poolie: I heard something about cscvs from kiko once. [02:06] i know of the tool [02:06] mkanat: cvsps-import or cvs2bzr [02:07] mkanat: cscvs is not for conversions, its for ongoing mapping, and only really does trunk [02:07] lifeless: Ah, okay. [02:07] My problem with cvsps_import right now is that it wasn't correctly handling utf-8 in CVS log messages, and it wasn't deleting files under certain circumstances, it seemed. [02:07] mkanat: it can do other branches, with fiddling, but unless you plan to stay on cvs, go for cvsps-import or cvs2bzr (which is fastimport based) [02:08] poolie: so, seems to me that we don't really know that full list ever; so the current warning is also able to be incomplete. [02:08] poolie: I don't think it would be overly ugly to have a module scoped list of expected extensions, and plugins could add to that list if they have extensions too. [02:08] right [02:08] or otherwise [02:08] just give the nag warning [02:08] put the missing list into the log file [02:09] it's probably actually rare that a non-developer will see just some things fail to load [02:09] I desire --version to show the list because its a very easy thing to ask a Windows or new user to look at. [02:09] or see something that's not fixed by either running make, turning off the warning, or filing a bug [02:10] i don't object to it, i just think it's a different (filed) bug [02:10] poolie: kk [02:10] good idea on the message though [02:12] lifeless: Any particular preference between cvs2bzr and cvsps_import? [02:13] mkanat: I suspect they will have different bugs ;) [02:13] lifeless: Hahaha, okay. :-) [02:13] Maybe I'll just stick with cvsps, then. [02:18] So, if I want to make sure that people don't accidentally check in as somebody else, is the best way to require signatures? [02:18] Well, actually, I'm not even sure that would work. [02:45] is someone here using bzr on sourceforge? do they support more than one branch per project? [02:56] jam: I'm running into a problem with cvsps 2.2, importing Bugzilla into bzr: https://bugs.launchpad.net/bzr-cvsps-import/+bug/431127 [02:56] Launchpad bug 431127 in bzr-cvsps-import "cvsps_import fails with cvsps 2.2" [Undecided,New] [03:04] Hi, I use bzr in my personal branch in launchpad. I save my different projects under different folders, my friends found it hard to pull all the folder to pull one of them. Is there any way to split the folders under different branches without losing the history of the commits ? [03:08] aboSamoor1: last time i asked about that i was not given a direct solution. but the hint that you could use fast-import/export and filter. so it should be possible with 2 or 3 steps [03:10] zsquareplusc: well, it is not only performance issue. I don't want to announce all my work once I send someone the address of branch. [03:11] zsquareplusc: also I don't want make global commits history. so it will more clear to me the history of the commits of each project alone [03:17] aboSamoor1: "bzr help fast-import-filter" should give some insight [03:18] aboSamoor1: just make separate branches now; e.g. [03:19] if you have in your current branch /proj1 /proj2 /proj3 [03:19] then bzr push ../new-proj2-branch [03:19] cd ../new-proj2-branch [03:19] bzr rm --remove proj1 proj3 [03:19] bzr mv proj2/* . [03:19] bzr rm proj2 [03:19] bzr commit -m "Make this branch be for proj2 only." [03:20] and push that to launchpad under an appropriate project [03:21] lifeless: how will the history of the new branch look like ? I mean if the initial branch has commit till 100 and proj2 was last updated with commit 90 what will be situation ? [03:21] lifeless: --remove is not documented in my bzr's help rm, is that brand new? [03:28] zsquareplusc: actualy its old I think :) [03:28] aboSamoor1: try it and see ;) [03:28] aboSamoor1: as it in a separate branch it won't impact your existing work :) [03:28] lifeless: good point [03:28] :) [03:29] in short, it will have everything up to the point you do the rearrangement [03:29] which is what 'preserve history' means, generally ;) [03:29] bzr push ../new-proj2-branch ----this must be ---> bzr branch ? [03:30] aboSamoor1: that makes a new branch at the path ../new-proj2-branch [03:30] lifeless: hm, if its old, it's undocumented. i can't find a word about in in "help rm" or "man bzr" [03:30] zsquareplusc: as in removed [03:31] zsquareplusc: ignore it ;) [03:31] aboSamoor1: its correct with push. you are in the directory of the current branch and push a copy to a fresh directory [03:35] hm.. with bzr 1.17: bzr rm --remove CVSROOT ... bzr: ERROR: no such option: --remove [03:35] zsquareplusc: don't use the option is what I mean [03:36] ah, but with just rm you still have the history [03:36] zsquareplusc: Of course, the question was how to keep the history, wasn't it?... [03:37] In order to control commit access to a bzr repository, do I have to control the unix permissions of the repository .bzr directory, or just the unix permissions of the branch .bzr directory? [03:37] lifeless: what i understood was, how to make 3 separate branches from 3 folders in one, each with only the history of the respective folder [03:38] zsquareplusc: to do that you need to break the history, rewrite it into a smaller form, which is what you'd use fast-export and fast-export-filter for [03:41] lifeless: I did that for the first project it increased the commit number by one, now how can I view the history of the new branch without using launchpad ? [03:42] aboSamoor1: bzr log or bzr qlog or bzr vis, depending on which plugins you have installed [03:42] aboSamoor1: bzr log [03:57] lifeless: I am satisfied with the solution proposed, thanks very much :) [03:58] Hey hey. Anybody got some feedback on my permissions question, above? [03:58] aboSamoor1: cool [03:59] mkanat: both [03:59] lifeless: Okay. [03:59] lifeless: That's what I thought; it's what I've been doing. [03:59] lifeless: So basically if we have separate committer groups, we need separate repos? [03:59] yes [04:00] lifeless: Okay, that's what I thought. [04:00] there are ways to avoid that; theres some stuff in contrib I believe [04:00] but the most secure simple and robust way is one-capability per-repository [04:02] lifeless: the only drawback of the solution, that if you split the old branch to 5 new branches you have 5 duplicate histories. 5*100 MB :( [04:02] aboSamoor1: they won't grow at the same rate though [04:02] aboSamoor1: and if you have a shared repository the deep history will be shared so you want have 500MB used on disk. [04:03] lifeless: I will try bzr split later [04:03] lifeless: I see [04:06] Is there a config for setting up "bzr serve" as a init.d daemon that logs to syslog? [04:07] what is the bzr equivalent of git reset --hard origin/master ? [04:08] mkanat: no, unfortunately. [04:08] Okay. [04:08] mkanat: it would be good to improve our logging to make that possible. [04:08] Drakeson: what does that do? [04:08] Yeah--I imagine running a constant "bzr serve" is faster than serving through inet. [04:10] git-reset resets current head to the speficied state (origin/master here). --hard matches both the working tree and the index to the state one asked for. [04:11] mkanat: yeah, most likely; it commonly takes a couple of hundred milliseconds to start a bzr serve process, assuming a warm system. A cold system and some plugins can make that much worse. [04:11] * mkanat nods. [04:12] Drakeson: "bzr uncommit -r something && bzr revert", perhaps? [04:12] Or maybe just "bzr pull --overwrite -r something", I guess. [04:13] spiv: how about an overheating system ? [04:13] leave that aside for moment. assume I do rm -Rf * in a working directory (that leaves .bzr intact). How can I get get back all the files? [04:13] I'm not sure exactly what the git jargon means. [04:13] SamB_XP: I don't overclock, so I couldn't say ;) [04:13] Drakeson: bzr revert [04:13] spiv: oh, mine does that without being overclocked [04:14] spiv: thanks [04:14] I had to clock it down to get it to stop rebooting -- probably there is some kind of problem with the cooling ... === AfC1 is now known as AfC [04:37] Does anyone know the timelines for 2.0? I see the release candidate has been pulled from the main page of bazaar-vcs.org. [04:38] rc1 was pulled, rc2 is out and fine [04:38] 2.0.0 is being assembled at the moment, no further changes [04:40] thanks lifeless [04:42] Jemsquash: just merging the animated .gif of poolie waving frantically that auto-displays during branch routines. stand by. [04:43] lifeless: was the decision final on this one for weave merges? - http://birdhouse.org/~mnep/avatars/scream.gif [04:44] heh [05:01] is anyone going to fix the hardlinking issue with WorkingTree6? [05:14] thumper: eventually I guess? its fallout from content filtering, and theres a bunch of work needed in that area [05:15] ok [06:02] hey spiv, i may (if we're lucky) review your patch this afternoon [06:03] i was wondering what you thought too about the idea of the client inhibiting itself from sending requests to servers when the implementation is known to be broken [06:03] i think i asked before but didn't see (or remember :) your reply [06:08] spiv: the 'extra' in smart tcp server for testing is flummoxing me [06:08] spiv: got a minute for a chat [06:16] spiv: for example: [06:16] (Pdb) bzrlib.bzrdir.BzrDir.open(self.get_url() + '../') [06:16] *** UnknownErrorFromSmartServer: Server sent an unexpected error: ('error', "Invalid URL join request: Cannot go above root: '/' + ('../',)") [06:16] bzrlib.bzrdir.BzrDir.open( "bzr://127.0.0.1:46829/") [06:16] *** BzrError: Attempt to escape test isolation: 'bzr [06:16] ... [06:17] self.get_transport(self.get_url()) [06:17] [06:17] lifeless: could you look at bug 430738 some time? [06:17] Launchpad bug 430738 in bzr "Upgrade fails with NoSuchId in _iter_file_id_parents in add_inventory_by_delta" [Undecided,New] https://launchpad.net/bugs/430738 [06:17] self.get_transport(self.get_url()).list_dir('.') [06:17] poolie: does 'check' pass on that repository? [06:18] he doesn't say [06:18] he says reconcile passed [06:26] * thumper is helping some windows bound people with bzr [06:26] lifeless: the last thing I would say is that if isinstance the for_testing server that you shouldn't hardcode /extra/; you can (and probably should) use server_obj.client_path_extra [06:27] what is the absolute easiest way to install bzr on windows that allows bzr+ssh usage? [06:27] thumper: windows on client, or server (or both)? [06:27] how much hoop jumping needs to be done for people without ssh keys? [06:27] spiv: windows client for sure [06:28] spiv: I was going to set up my desktop as the main code host [06:28] spiv: it is for a polytech project [06:28] 3 people collaborating [06:28] It should mostly just work, I think, now that we default to using paramiko on Windows. (IIRC) [06:28] spiv: as you may expect, my desktop is linux [06:29] spiv: the bazaar wiki page for windows installing isn't very helpful [06:29] thumper: we know you still use an Amiga. [06:29] it says "download these 8 things..." [06:29] There's no requirement to have SSH keys, but they can help avoid the need to retype your password a lot :) [06:29] thumper: Huh, I thought it was just a case of "download and run the .exe installer" [06:29] spiv: I don't allow ssh with a password to my server :) [06:29] thumper: but I could easily be wrong. [06:30] which one? [06:30] I tried the py 2.6 one as I thought that ment "uses python 2.6" [06:30] but no [06:30] the standalone installers say 2.2 and 2.3, and I'm not sure if they are meaning python or what [06:30] Gosh, I'm out of date. I thought there was just one! [06:30] I'll ask again later tonight [06:30] thumper: IIRC, PuTTY allows creation and use of ssh keys. [06:30] perhaps I'll get some windwos users [06:31] thumper: http://bazaar-vcs.org/Download has, next to "Windows installer", a link called "default 1.18.1 installer". [06:31] when is the 2.0 one going to be there? [06:31] thumper: I guess you're looking at the Launchpad page of download files? [06:31] yeah [06:31] When it's released, I assume ;) [06:31] :) [06:31] * thumper goes to make dinner [06:32] thumper: I'm pretty sure you almost always want to be using the "Standalone" installers on Windows. [06:34] poolie: I'm ok with the idea of not sending requests we know the server will get wrong... the question is how can (and should) we determine the "known to be broken" fact? [06:35] poolie: You're thinking of looking at version string in the response headers, I guess? [06:36] poolie: the way we've dealt with this (or something similar, at least?) before is to create a new verb. [06:41] uhm [06:41] lp handles ~ fine [06:41] so I beg the question, how would one tell? [06:41] hi all [06:41] how's 2.0 moving? [06:49] spiv: [06:49] I don't know about you, but I'm pretty good at ignoring yet another email, [06:49] particularly email that comes from a cron job ;) [06:49] bah [06:49] copy paste fail [06:49] I don't know about you, but I'm pretty good at ignoring yet another email, [06:49] particularly email that comes from a cron job ;) [06:49] and gain. [06:49] * lifeless stares at vim [06:50] elif isinstance(transport_server, server.SmartTCPServer_for_testing): [06:50] # The smart server adds a path similar to work, which is traversed [06:50] # up from by the client. But the server is chrooted - the actual [06:50] # backing transport is not escaped from, and VFS requests to the [06:50] # root will error (because they try to escape the chroot). [06:52] lifeless: sounds good [06:53] lifeless: what are you referring to with "lp handles ~ fine"? [06:53] this should make you laugh: [06:53] Attempt to escape test isolation: 'bzr://example.com/quack/' ['/tmp/testbzr-HhM4se.tmp/', 'file:///tmp/testbzr-HhM4se.tmp/', '/tmp/testbzr-HhM4se.tmp/', 'file:///tmp/testbzr-HhM4se.tmp/'] [06:53] :) [06:53] bzr+ssh://bazaar.launchpad.net/~lifeless/... [06:54] I'm missing something. [06:54] What was that comment in reply to? [06:54] 15:33 < spiv> poolie: I'm ok with the idea of not sending requests we know the server will get wrong... the question is how can (and should) we determine the "known to be broken" fact? [06:54] Oh, that was unrelated to ~ in URLs. [06:54] ah ok [07:01] it was unrelated [07:01] it was about 1.17 sticking xml into chk streams [07:01] purportedly chk streams [07:02] spiv: we know now that 1.17 was broken [07:27] poolie: it was unrelated [07:27] poolie: it was about 1.17 sticking xml into chk streams [07:27] poolie: purportedly chk streams [07:27] poolie: spiv: we know now that 1.17 was broken [07:28] poolie: right [07:28] hi all [07:28] poolie: you're speaking to yourself ? .... Often ?.... :P [07:30] :) i think i fell off irc [07:30] i wasn't sure if it got through [07:40] what's the cleanest way to test things sent to trace.warning? [07:41] poolie: nearly done with bug #430749, I still have one failure [07:41] Launchpad bug 430749 in bzr ""Failed to load compiled extensions" warning breaks the test suite" [High,Confirmed] https://launchpad.net/bugs/430749 [07:41] ok [07:41] poolie: just in case you're on it [07:41] i'm nearly done with giving a nicer message and am just trying to work out how to test it [07:42] i'm also going out in about 40 mins [07:42] oh btw, i forgot to say yesterday [07:42] ok, I think there is another for that [07:42] i appreciated all your bug tidying [07:42] ok, I think there is another bug for that [07:42] there is [07:42] bug 430529 [07:42] Launchpad bug 430529 in bzr "missing extensions warning is unclear" [High,In progress] https://launchpad.net/bugs/430529 [07:42] ok, so no problem, we'll review each other :) [07:43] the way I address mine doesn't depend on the message only on the config variable [07:44] this is kind of annoying [07:44] and last one fixed, running a full test suite to check [07:44] it's a stupid thing to get stuck on [07:44] the testing i mean [07:44] pfewwww [07:45] don't feel stupid, IME writing the first test of a new kind is always hard, far far harder than the code [07:45] the thing is it's not the first [07:45] it's just that trace really needs some cleaning up [07:45] at least now we can do it with less fear of compatibility [07:45] breakage [07:46] worth spendng some time on it isn't it ? :D [07:54] poolie: so what is it you're wanting to test exactly ? The text itself ? (Coincidentally I have test_config.py under my eyes, there is an assertWarning(warning) there [07:54] vila, the text, and it's no longer a python warning [07:54] https://code.edge.launchpad.net/~mbp/bzr/430529-extension-warnings/+merge/11950 [07:54] i might pull at the cruft in a separate branch [07:57] ooh, it was a *python* warning, sorry I missed that [07:59] i'll pull out some uncontroversial stuff from trace.py and send mail about the rest [07:59] in short it's a question of whether we should still be using python logging [07:59] it's a bit conflicted with our ui factory stuff [07:59] it takes a little while to load [07:59] and it makes things a bit more complex to test [08:26] bonjour vila, good evening poolie [08:27] hello bialix [08:27] poolie: my vote is to unify under the ui banner [08:27] poolie: but I still have to read your mail :) [08:32] commiting to stacked branch with bzr-2.0rc2 is OK on Ubuntu but failed on WinXP [08:33] naoki: that sounds bad, please file a bug. [08:37] https://bugs.launchpad.net/bzr/+bug/431223 [08:37] Launchpad bug 431223 in bzr "bzr2.0rc2 fails commiting to stacked branch on WinXP" [Undecided,New] [08:39] naoki: Hmm. Sounds like bug 375013, but I don't know why you'd get different behaviour on Ubuntu vs. WinXP for that. [08:39] Launchpad bug 375013 in bzr "lightweight checkout commit to a stacked branch does not work" [High,Triaged] https://launchpad.net/bugs/375013 [08:40] naoki: perhaps on Ubuntu you aren't using a lightweight checkout of the branch? [08:41] naoki: also, what version of bzr are you using on Ubuntu? [09:18] I am trying to connect to a server through proxy on Windows; I have set http_proxy=http://my.proxy.server.com [09:19] even tried to configure authentication.conf to no avail, any ideas? [09:19] rojanu: try adding '-Dhttp' and look at your '.bzr.log' for clues [09:21] vila: where do I find the log? [09:22] 'bzr version' will tell you [09:25] Ok. log has some traceback info and msg printed to stdout "bzr: ERROR: Connection error: failed to connect to bzr.bugzilla.org:4155: Operation timed out" [09:26] Did you specify '-Dhttp' in your command ? [09:26] Err, wait, you're connecting with a bzr+http:// url ? [09:28] here is my command "bzr -Dhttp co bzr://bzr.bugzilla.org/selenium/3.4" [09:29] rojanu: http is not involved here [09:33] spiv: I used bzr-2.0rc2 on Jaunty x86 [09:33] spiv: And I didn't use lightweight checkout on both. [09:34] I did use only stacked branch that stacked on standalone branch. [09:35] rojanu: I meant, I don't know what proxy you're using but I'm not sure it will know how to transparently proxy the bzr protocol... [09:37] vila: I don't know what proxy it is apart from the server address. In browsers, we have pac files specified!!! [09:38] rojanu: browsers speak http, bzr can speak http too with http servers, here you're trying to speak to a bzr server in the bzr protocol [09:38] rojanu: does bugzilla offers http access for that branch ? At a different address ? [09:39] rojanu: you may want to contact *them* to know that [09:39] s/know/answer/ [09:41] vila: I will contact bugzilla to get a http address, Thanks [09:42] rojanu: the alternative is to contact your admins to allow direct connection to bzr.bugzilla.org:4155 [10:00] naoki_: thanks! I'm still mystified, but I've updated the bug. [10:01] grr [10:01] "bzr: ERROR: Attempt to escape test isolation: 'file:///home/robertc/source/baz/pending/working/bzrlib/version.pyc/' ['/tmp/testbzr-laC87z.tmp/ [10:02] lifeless: why grrr? Aren't you happy to catch one more ? :D [10:02] vila: this is 'bzr version looks for a bzr source tree' [10:03]