[00:14] nick125: there is an 'integrating with bzr' wiki page btw [00:15] nick125, http://bazaar-vcs.org/Integrating_with_Bazaar [00:15] * nick125 is reading [00:43] Does bazaar have some way to push via HTTP with something like a CGI script? [00:46] That's one of the main things that I liked about mercurial (one of the things I didn't like about mercurial was the random data corruption that would occur when you would use two different mercurial versions) [00:47] nick125: there is some support for smart behaviour over http, yes [00:47] i'm not sure how useful it is yet [00:48] nick125: bzr+http [00:49] *looks* [00:49] lifeless: Do you happen to have a link? [00:52] its in the docs [00:53] on an http url bzr 1.4 will autodetect bzr+http if its available [00:57] * nick125 looks at the big "THIS IS EXPERIMENTAL AND INSECURE" notice [00:57] hmm [00:57] That notice is gone in bzr.dev. [00:58] spiv: call ? [00:58] spiv: i hope that means its secure now :) [00:58] poolie is organising office stuff; I have offered to be the teddy bear de jour [00:59] lifeless: sure [00:59] What other ways exist to push with bzr without SSH? [00:59] bzr+http [00:59] ftp [01:00] wedbav [01:00] any vfs [01:01] ssh/sftp seem to be the most mature and simplest, tho [01:06] oh yeah, sftp too :P [01:06] but sftp kinda needs ssh :) [01:06] * nick125 is kind of leary about giving random people SSH access to his server [01:07] You can create sftp-only accounts [01:07] You set the shell to something special. sftp doesn't actually use a shell anyway, it's a different subsystem of ssh [01:08] LeoNerd: So I can set the shell to /bin/false (or something like that), and sftp would still work? [01:08] Um.. possibly. I don't know the details, I just know it's possible [01:09] nick125: I think that's roughly correct. OpenSSH's sftp subsystem in recent versions can even set up a chroot to restrict where they may navigate to [01:09] nick125: on my secured shells recently, I've been utilizing Apparmor profiles to provide restricted access. this can also be an acceptable option [01:09] nick125: you can even use a virtual SFTP server e.g. the conch one or I think paramiko has one too [01:10] hmmm [03:01] * nick125 sets up bazaar and paramiko [03:02] hello [03:02] welcome nick125 [03:02] hiya poolie [03:06] So, paramiko is a sftp server that doesn't require users to have shell access? [03:18] blah [03:19] I'm trying to figure out how to get a centralized repository that people will push and pull from...I don't think I want to do a shared repository, since I have a bunch of devs that want to work offline. [03:21] nick125: A shared repository is just a performance and storage enhancement, it doesn't affect your workflow. [03:21] Unless I'm misunderstanding the concept of shared repositories (it sounds to me that a shared repository keeps the history on the server) [03:21] nick125: shared repositories simply allow multiple branches to use a single shared history db [03:21] nick125: does not affect offline/branches/etc [03:22] Ahh. [03:22] The documentation makes it sound like that it stores the entire history on the server and only leaves a local copy. [03:23] which docs in particular ? [03:23] the centralized workflow one [03:23] I probably misread it. [03:23] (what you describe is what lightweight checkouts do) [03:23] an orthogonal feature [03:27] * nick125 hates having to come up with names for projects [03:40] New bug: #213172 in bzr ""bzr status" output problems" [Undecided,New] https://launchpad.net/bugs/213172 [04:16] New bug: #213182 in bzr "TestLockDir.test_35_wait_lock_changing is timing-dependent" [Undecided,New] https://launchpad.net/bugs/213182 [04:26] New bug: #213184 in bzr "'conflicting tags' could be more helpful" [Undecided,New] https://launchpad.net/bugs/213184 [04:26] New bug: #213185 in bzr "tag conflicts do not change exit code" [Undecided,New] https://launchpad.net/bugs/213185 [04:30] New bug: #213186 in bzr-gtk "gannotate broken with bzr.dev" [Undecided,New] https://launchpad.net/bugs/213186 === mwhudson_ is now known as mwhudson [04:33] * mwhudson wtfs [04:33] reality check please: [04:34] am i right that it's pretty strange that "cd a; bzr merge ../b" gives conflicts in different files to "cd b; bzr merge ../a" ? [04:35] (with --lca) [04:36] though the conflicts are different with merge3 too [04:37] (some of the conflicts look totally bogus too) [04:38] LCA has an edge case which it doesn't deal with, but I can't remember what it is... [04:46] mwhudson: unless there are working tree changes it does sound strange [04:46] i guess i'll just send abentley a mail, given that this is an issue with two launchpad branches [04:46] i don't think it's guaranteed that they're symmetrical [04:47] poolie: it should be; we walk back to a single lca [04:47] i guess i'll send the mail to the internal list then :) [04:48] Odd_Bloke: The edge case is that it fails to detect a conflict when one side deletes lines and the other side changes them to something else. [04:49] mwhudson: Please do. [04:50] hi, so like, i installed bzr and bzr-svn packages in ubuntu, but am having trouble branching an svn repo. the documentation is rather light in the bzr-svn wiki, any pointers? [04:50] I can tell you, it's been frustrating over the years to get reports of strange merge behavior with Launchpad branches, and not be able to do anything about it. [04:50] (there is some criss-cross merging around) [04:50] abentley: i'm sure [04:51] bitmonk: "bzr branch svn_url blah" - do you get an error? [04:51] bzr: ERROR: Not a branch: svn+https://svn.plone.org/svn/archetypes/Archetypes/trunk [04:51] same for https:// [04:51] hm [04:51] indeed.. i haven't had it working for a while, but got it working from source a couple times on my mac or something.. [04:51] i have had it working, so i have a rough memory of what works.. [04:52] abentley: just think, now you can dig all those reports up and analyse them :) [04:52] * mwhudson finds himself wondering if there is a way of restricting 'bzr viz' to revisions touching a particular file [04:52] lifeless: yay! [04:53] lifeless: Have you had seen bug 212908 ? [04:53] Launchpad bug 212908 in bzr "fetch all from a repo with identical contents fails with pack repos" [High,Triaged] https://launchpad.net/bugs/212908 [04:54] mwhudson: that would be lovely feature [04:54] mwhudson: I don't think it exists yet, sadly. === jamesh_ is now known as jamesh [04:55] Since VersionedFiles can provide a Graph, it shouldn't be hard now. [04:55] Because viz is now using Graphs. [04:57] abentley: are your two statements to me related? [04:58] lifeless: No. [04:58] abentley: I've seen that bug, I presume you had a plugin or something to trigger it? [04:58] bitmonk: does 'bzr plugins' show svn listed? [04:58] Reconfigure triggers it. [04:58] oh, ok. [04:58] At least in my new patch, it does. [04:59] But we have also occasionally seen reports of the same error in the wild. [04:59] I can guess at the cause; its really a LBYL avoidance optimisation [04:59] So this may be the cause of them. [04:59] oh, i think the different merge results with --merge3 were because of unknown files or something [04:59] bob2: yessir [04:59] abentley: rather than checking keys exist in packs, we copy them when we are asked too. By design multiple packs can have the same key. [05:00] This isn't a key-level problem-- it's a file-level problem. [05:00] bitmonk: hm, dunno then - try asking on the mailing list, I guess [05:00] It comes from trying to create a file in a pack that already has a file with the same name. [05:00] abentley: thats a key level problem [05:00] abentley: the name is the checksum of the .pack [05:00] bob2: will do, no hurry i s'pose [05:01] * mwhudson sends a mail [05:01] abentley: it means we've copied the exact same data in twice. [05:01] Are you saying the filename of a pack is its key? [05:01] (or got a md5 collision) [05:01] fortunately, it's not actually a real problem for me, the bogus seeming conflicts are trivial [05:02] No, I think you're forgetting that fetch with no argument ids doesn't copy contents, it copies files. [05:02] So if the source file has foo.pack, the target file has foo.pack, regardless of the keys inside it. [05:03] I mean source repo, target repo. [05:03] abentley: one sec, talking with poolie [05:04] So it's all about what the names of files in a repo are, not what their contents are. [05:05] (Now of course, we would *hope* that the repository is not corrupt, but that's not actually relevant...) [05:06] InterPackRepos.fetch does not copy files [05:06] when revision_id is None, it does self.source.all_revision_ids() [05:07] why are you saying we copy files ? [05:07] line 2726 of repository.py in bzr.dev [05:09] bitmonk: does http:// work? [05:10] good question, trying [05:12] I have line 2758 [05:13] ubotu: paste [05:13] pastebin is a service to post multiple-lined texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu-nl.org (make sure you give us the URL for your paste - see also the channel topic) [05:13] http://paste.ubuntu-nl.org/62385/ [05:14] lifeless: ^^ [05:14] abentley: that is consistent with my analysis [05:14] abentley: packers copy contents not files [05:15] abentley: when revision_id is None, revision_ids becomes the source's all_revision_ids() set [05:16] abentley: but like I said, we don't try to eliminate duplicate revisions because that is costly and unneeded. [05:16] My apologies if I misunderstood. [05:16] abentley: this is simply an expected md5 collision: we are copying the same content to a repository that has that content laid out the same way in a .pack. The right thing to do is to complete bug # [05:16] It looked as though it was copying the source's all_packs(), not their contents. [05:17] Bug # ? [05:18] There is no bug number. That's part of the bug :) [05:18] I can see the confusion :) [05:18] I'm looking it up [05:18] lp is slow [05:19] https://bugs.edge.launchpad.net/bzr/+bug/165293 [05:19] Launchpad bug 165293 in bzr "collisions through uploading same-named .pack files not handled correctly" [High,Confirmed] [05:20] fetch with no revision_id parameter should be extremely rare - limited to upgrade in fact [05:20] why does reconfigure use it ? [05:21] lifeless: It is deleting a repository. [05:21] So it fetches all the contents into a new repository. [05:22] right [05:22] as a backup ? [05:23] and is it doing it twice for some reason ? [05:23] (we can't filter on all_revision_ids() here, because if you need _all_ data you need signatures for absent revisions, inventories with no revisions etc.) [05:24] Because the new repository is going to be used for the branch from now on-- e.g. a heavyweight checkout being converted into a lightweight one, or a standalone tree being converted into a sharing tree. [05:25] so when you say new repository, do you mean 'existing other repository' ? [05:25] yes. [05:25] ok [05:26] So the test cases set up two repositories with identical content. [05:26] And then reconfigure itself does the fetch() [05:26] fixing the md5 collision handling to not error on collisions with identical content will fix this bug [05:26] but reconfigure in this case will be overly slow [05:26] If you fix it or in general? [05:27] the cause of the error is a situation we expect to encounter, but rarely [05:27] and is not an error when it happens, we just currently group it with actual errors. [05:27] however, copying a *lot* of data that we do have will be slow [05:28] pack repos allow keys to be duplicated in different .pack files because that allows better concurrency when two people write to a repository at the same time [05:32] testing a workaround for you [05:35] abentley: try this: http://paste.ubuntu-nl.org/62387/ [05:38] lifeless: that fixes my test case. [05:40] Reconfigure tests pass too, with my workaround removed. [05:45] abentley: cool [05:55] OperationalError: ('(OperationalError) database is locked', >) u'SELECT mergerequest.id AS mergerequest_id, mergerequest.date AS mergerequest_date, mergerequest.summary AS mergerequest_summary, mergerequest.branch_location AS mergerequest_branch_location, mergerequest.head_revision AS mergerequest_head_revision, mergerequest.text_type AS mergerequest_text_type, [05:55] *sorry* [05:55] I had no idea it was that long; I imagine IRC truncated it but still [05:56] /kick lifeless :) [05:57] spiv: whats up with http://bundlebuggy.aaronbentley.com/request/%3C20080228144229.GF3192@steerpike.home.puzzling.org%3E? [05:57] poolie: http://bundlebuggy.aaronbentley.com/request/%3C1207267732.5960.150.camel@lifeless-64%3E [06:07] bob2: still no love with http:// :/ [06:09] spiv: u have a review [06:09] lifeless: thanks [06:10] lifeless: so you just think s/list/tuple/ in that? [06:11] If that passes tests yes. [06:11] * spiv nods [06:11] you'll need to change the code obviously as you can't mutate the tuple once you make it [06:11] so list(thing) [06:11] ... [06:11] new = tuple(correct_options0 [06:12] spiv: calling it orig_options is confusing too; so perhaps options = list(self....) [06:12] Ok, makes sense. [06:12] * spiv finds out if tests pass [06:49] spiv it looks like you should merge http://bundlebuggy.aaronbentley.com/request/%3C20080228144229.GF3192@steerpike.home.puzzling.org%3E [06:50] poolie: yeah, it's on my radar. lifeless just pinged me about that earlier :) [09:26] hi fog [09:27] hi james === AfC is now known as AfC|makingDinner === `6og is now known as Kamping_Kaiser === doko__ is now known as doko === weigon_ is now known as weigon === AfC|makingDinner is now known as AfC [11:50] how do I unlock a branch? [11:50] "bzr break-lock" [11:51] it seams to be in the host [11:51] Unable to obtain lock lp--1228238676:///lock [11:51] held by luisbg@bazaar.launchpad.net on host vostok [process #25367] [11:51] :( [11:54] luisbg: hi [11:54] hey james_w [11:54] you want to run "bzr break-lock sftp://whatever" [11:54] ok [11:54] let me see [11:54] unfortunately with launchpad you may need to run this a few times. [11:56] a lot [11:56] still stuff locking it [11:57] done and pushed after like 10 runs [11:57] :) [11:57] thanks!! [11:57] no problem. === mrevell is now known as mrevell-lunch [12:18] what was the command providing --custom revision format? [12:18] the thingie that is recommended instead of $Expansion$ [13:06] how do i get a branch for some specific revision using bzrlib? [13:06] without making a checkout preferably [13:07] i want to pass the result as "other" to branch.missing_revisions [13:15] Hi, I've encountered a bug in bzr+svn that I think I can fix myself. Could anyone point me at any docs on bzr+svn hacking? [13:15] (i.e. which tree to work against, where/how to email a merge request/patch etc) [13:17] the bzr svn page on the wiki at least has some of that information [13:18] It links to three branches (trunk, 0.4 and 0.3), doesn't say which to use to hack on, shows how to run the unit tests, and where to raise bugs [13:22] emm, why is revision_tree method of a tree [13:22] "not implemented" but not marked as such in the docs [13:23] it always raises an error (at least that's what code says) [13:23] but has an elaborate docstring [13:23] that leads one to think that the method does somethingh [13:25] * ignas had this idea that using bzrlib would make listing of all the new changes since some revision easier than using bzr from the command line... === mrevell-lunch is now known as mrevell [13:30] ignas: there will be a subclass that implements th\at [13:30] ignas: although most classes don't tend to be constructed directly, you usually get them by calling methods on repository/branch/etc. [13:31] yeah, that's what i tried doing [13:32] tree.revision_tree("revision-I-want") [13:33] hello, i have a central repository (remote server), and i need to run a hook (shell script) on that server after each commit. how do i do this? [13:34] so - how do I list all the changes in a branch since some revision? [13:34] * ignas looked at show_log and it is a little bit complicated [13:34] ignas: bzr log -r.. [13:35] ignas: -v will show modified files as well [13:35] i need it not including the revno [13:35] which is why i tried using bzrlib to do that [13:35] ignas: maybe i haven't got what are you trying to do? [13:36] i need a list of all the changes since some tag (only new revisions) listed on a web page [13:36] at the moment i am using popen to run "bzr missing" [13:37] but that requires making a checkout from the tag [13:37] which makes the operation kind of slow [13:38] ignas: bzr log -r tag:.. [13:38] includes the revision that was tagged as well [13:40] ignas: hmm, no ideas for now [13:40] ignas: do you know how to set up a hook on a remote shared repo? [13:41] nope [13:41] why would i want to do that? [13:41] ignas: i need it :) [13:41] oh ;) [13:41] ignas: just asking === mw|out is now known as mw [14:00] is there an easy way to perform actions on bzr log messages using bzrlib? [14:01] i want all the log messages since some revision [14:01] in some data structure [14:01] and the only thing i could find that does something like that was show_log function, but it's way too complicated for what I want [14:01] and outputs stuff into stdout from what I can see, instead of giving me a list [14:02] ignas: I think revision objects have a .message attribute [14:03] ok, how do i get all the revision messages since some revision? [14:04] or does revision_history() return them ordered ? [14:04] ignas: yes, revision_history is ordered [14:06] and how do i get a revision object from a revision_id? [14:08] Is there a way to resume a bzr checkout operation that has died? [14:09] ignas: repo.get_revision [14:09] ignas: where 'repo' is a Repository, e.g. from Repository.open('path/to/repo'), or from branch.repository. === kiko is now known as kiko-afk [15:33] Anyone know how to resume a failed checkout operation? [15:36] pickscrape: "bzr pull" may be able to do it, I think it depends when it failed. [15:38] Bingo. :) I had to specify the URL of the svn repository again, but it appears to be working fine. [15:38] Thanks for that. [15:38] My bzr-svn fix appears to have worked too. Anyone know where I should email the bundle containing the fix to? [15:39] pickscrape: please send it to me (jelmer@samba.org) [15:39] Will do. [15:40] jelmer: should the patch be against 0.4 or trunk? [15:40] pickscrape: 0.4 please [15:40] pickscrape: just "bzr send" should Do The Right Thing[tm] if you have bzr >= 1.3 [15:41] I guessed right then :) [15:41] Just making sure my name etc is configured right for the commit. [15:41] where can I find example of how to change 1 file and commit it to a branch using bzrlib without having a checkout [15:42] if that's possible [15:42] oh and tagging, yes, tagging [15:43] I don't think you can do it without a checkout [15:43] at least not easily. [15:43] where can i read about the hard way? [15:43] I doubt you can I'm afraid [15:43] because i am already doing it with bzr co + shell script [15:44] I'd have no real idea how to do it, I'd just know that you probably have to write a CommitBuilder, or perhaps somesort of Tree. [15:44] i can see the CommitBuilder object [15:45] but where do i find the information on how to use it [15:45] I don't know I'm afraid. [15:45] all my attempts at googling for this stuff end up in unrelated mailing list posts or bug reports ... [15:46] ignas: It should be possible by obtaining a CommitBuilder from the branch you would like to commit to [15:46] ignas: and then calling the methods on the object that is returned to you [15:46] yeah, have that [15:46] the methods are not very obvious [15:46] i think "cb.new_inventory" is what i need [15:47] but i am not really sure [15:47] ignas: Basically the idea is you call record_entry_contents() for each entry in the inventory [15:47] ignas: (even the unchanged ones) [15:48] ignas: then, call modified_file_text() / modified_link() / modified_directory() for each entry that was modified [15:48] ignas: then commit(message) [15:49] modified_file_text is a method of what? [15:49] commitbuilder [15:49] hmm, can't see it === abadger1991 is now known as abadger1999 [15:50] python prompt is giving me attribute not found on it [15:50] ignas: Ah, looks like that's been removed [15:51] i see [15:52] is there some place i can read about it? or did no one ever tried doing that before? [15:52] how do you do such things in tests? or do you just modify the tree that you have checked out? [15:53] ignas: Please ignore me, it looks like modified_*() has been removed [15:53] ignas: Ah, you have to pass in a tree to record_entry that commitbuilder will get the text from [15:53] ignas: or something that has a get_file_text() method [15:54] ignas: lifeless and I wrote CommitBuilder a couple of years back, afaik there is no documentation (yet) [15:55] :D [15:55] not like you had time ;) [15:56] (-: === kiko-afk is now known as kiko [16:00] so i should get a basis_tree, use some bzr magic to modify versions.txt.in in there, iterate through it's inventory and pass all the entries to CommitBuilder.record_entry_contents, passing that new tree as the tree parameter? [16:01] ignas: yep [16:01] jelmer: Patch sent. [16:02] jelmer: thanks, i'll try ;) [16:06] pickscrape: Any chance you can also add an entry to NEWS and a test in tests/test_svk.py ? [16:07] Oh, sure. [16:07] Should I uncommit my change then, do the additional changes and then recommit? [16:08] pickscrape: no, you should be able to just commit on top of your current commit [16:08] OK. Figured you might prefer a 'cleaner' history, but I can do that. [16:09] Was the method used appropriate or are there cleaner ways of doing it? [16:10] pickscrape: I mainly care about the cleanless of the mainline history. No matter how many revisions you commit, there will only be one merge commit on mainline for your changes. [16:11] Ah, I get you. [16:11] pickscrape: In other words, "bzr log" will show one merge commit and your commits indented below that [16:12] pickscrape: The change itself looked fine === mrevell is now known as mrevell-afk === mrevell-afk is now known as mrevell [16:55] jelmer: I'm having trouble with the test. it's written, but when I try to run it I get "NameError: global name 'parse_svk_features' is not defined" [16:56] jelmer: Muppet alert (ignore me). [17:03] jelmer: i have managed to retrieve the content of the file, but how do I change it? [17:03] i have the branch, the tree, and the entry [17:04] or must I create a new entry instead? [17:10] ignas: When you call record_entry_contents set ie.revision to None [17:10] (see the docstring of record_entry_contents()) [17:15] hmm, still not sure about it, i mean - it seems that record_entry_contents takes the new content using tree.get_file(ie.file_id) [17:15] my question is - how do I put the new content into the tree [17:18] New bug: #213425 in bzr "push over sftp crashed" [Undecided,New] https://launchpad.net/bugs/213425 [17:19] jelmer: Further patch with NEWS entry and unit test added. [17:22] ignas: You have to override get_file() somehow [17:22] oh [17:24] The bug from that bug is running as root? :X [17:24] pickscrape: Thanks, merged :-) [17:26] Sweet. :) [17:33] jelmer: hmm if I try record_entry_contents on the entry i get a "file already under version control" error [17:33] because the file path is the same [17:33] and it tries to add the entry to the new_inventory [17:35] i kind of assumed that when you record the root entry all the sub entries get added recursivelly, but it seems that the assumption was wrong too === kiko is now known as kiko-fud [17:36] bzrlib/osutils.py is lazy-importing functions. Isn't that a no-no? [17:38] Peng: no, that's usually okay. [17:39] Functions are usually called, not used like variables. [17:40] The first time you call a lazily-loaded function, the real function is substituted. [17:40] If you happened to pass the function as an argument, that would be more of an issue. [17:43] Hey, if I've got a working tree with changes that aren't in the main branch, will bzr pull overwrite what I've got? [17:46] ignas: and you're adding it with the same file id? [17:46] no, i god an error about the id being in the inventory already [17:46] so i tried changing the id [17:54] lamalex: no, if there are any conflicts they will be reported [17:54] jelmer: I've got another bzr-svn traceback for you. :) http://paste.pocoo.org/show/38420/ [17:55] jelmer: Latest bzr-svn 0.4 and bzr.dev as of 5 minutes ago. [17:55] Peng: the 0.4 branch is b0rked at the moment [17:55] jelmer: "bzr svn-import http://svn.pyyaml.org/". Trying to branch an individual, err, branch also fails around the same place. [17:55] jelmer: Heh, ok. [17:55] jelmer: Was it borked on the 1st? [17:55] Peng: yep, has been broken for a couple of days [17:56] jelmer: Nice. Ok. [17:56] Peng: I added a warning message a couple of hours ok [17:56] s/ok/ago/ [17:56] The "experimental" warning? [17:56] yep [17:56] But that's always been there. :P [17:57] I occasionally add or remove it [17:57] So, should I downgrade? What to? [17:58] Peng: for stability, use a release [17:59] Bah, what's the fun of that. [17:59] Can I at least use the bzr branches of the releases? :) [18:00] bzr pull --overwrite tag:bzr-svn-0.4.9 :-) [18:02] s/tag/-rtag [18:03] s/pull --overwrite/revert/ [18:03] :) [18:03] Way boring though. [18:03] Hmmm. === kiko-fud is now known as kiko [18:06] Lightweight checkout++. === mrevell is now known as mrevell-dinner === hexmode` is now known as hexmode [18:30] Hello. Trying to push a branch to a ssh repository: `bzr push bzr+ssh://myuser@myserver:6114/path/to/repo` returns an error: bzr: ERROR: Generic bzr smart protocol error: bad protocol marker "error\x01Generic bzr smart protocol error: bad request u'bzr request 2'\n" [18:31] googling doesn't bring anything up [18:32] panosl: what's the version of bzr on the remote end? [18:33] Hi all, when I try 'bzr merge' in the relevant folder (to update from the main branch) I get an error which says: bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/%7Eubuntu-core-doc/ubuntu-doc/ubuntu-hardy/.bzr/repository/lock): Transport operation not possible: http does not support mkdir() [18:33] What does that mean? [18:33] 0.11 (ubuntu server), and my end is 1.2 (leopard) [18:34] ligemeget: you are using a checkout of a branch over http, which you are not allowed to write to. [18:34] panosl: This is the bug that's fixed by bzr 1.3.1 [18:34] ligemeget: do you know if you did a lightweight checkout? [18:34] james_w: Yes I did [18:35] to save time - I didn't need any history [18:35] jelmer: is it? I thought that was over http. [18:35] Only updating my end? [18:35] I can't update the server software [18:35] ligemeget: ok, you probably want the switch command [18:35] james_w: 'bzr switch'? [18:35] james_w: Oh, ok. I thought it was meant to fix errors like this as well [18:36] panosl: Looks like I'm wrong [18:36] ligemeget: bzr switch bzr+ssh://ligemeget@bazaar.launchpad.net/~ubuntu-core-doc/ubuntu-doc/ubuntu-hardy/ [18:36] (assuming your lp username matches your IRC nick) [18:36] jelmer: it looks like the remote end doesn't understand the request. [18:37] panosl: I think you need to upgrade the version on the remote end, I'm not positive though. [18:37]