[00:03] I have branched off some line of development with my own changes, now I'd like to get a complete, clean patch of my changes to the trunk revision. How to do that? [00:04] I tried with merge --preview, but it does not work, since I'm working treeless. And I don't really plean to do a merge anyway. [00:04] s/plean/plan/ [00:05] Leonidas: bzr send? [00:05] Furthermore, I'd like to merge in the latest trunk changes since branching, but they should not appear in my patch. [00:06] Leonidas: bzr send? [00:06] Peng: thanks. I'll see whether this is what I want. [00:06] Leonidas: there is also "bzr diff -r ancestor:URL" [00:07] Leonidas: 'bzr send' produces a bundle file, which by default includes a diff and the (base64-encoded) meta data. [00:09] poolie: did you ring? [00:10] Peng: bzr send sounds good, but I'd need to get the patch only, since it's only me who is using bzr. The other people have no use for bundles. [00:11] bzr send --output=- is nice, now compine it with no-bundle [00:13] huh? Am I missing something? bzr send --no-patch --output=- works [00:13] bzr send --no-bundle --output=- does not. [00:14] bzr send --output=- does work and produces both patch & bundle. [00:16] Leonidas: I'm guessing "bzr send --no-bundle" is failing due to a lack of a public location for your branch. [00:16] Leonidas: if you just want a diff, you're better off using "bzr diff" directly, as james_w suggested. [00:17] spiv: right, it fails because there is no public location. But I don't see why it does not work like bzr send just without the bundle. I could use sed, though ;) [00:18] Leonidas: bzr send tries fairly hard to make sure that all the history is available to the recipient, either in the included bundle, or in a publically accessible branch if there is no bundle. [00:18] ah, that explains a lot! [00:18] lifeless: no [00:19] i.e. bzr send is designed as a way to send merge directives for branches, not as a way to generate diffs. Generating diffs is what "bzr diff" is for :) [00:19] spiv: ok, bzr diff -r ancestor:... works properly. Fine. [00:20] Thanks, also to james_w [00:20] I wonder what happens if I merge trunk :) [00:24] ok, works. Fine [00:37] lifeless: I'm planning to tweak stacked branches today [00:37] 1. move branch-location into branch.conf [00:37] 2. rename shallow options and messages to stacked [00:37] 3. ???? [00:37] lifeless: is that ok? [00:51] igc, is the name really just branch-location? it needs a less ambiguous name... [00:53] poolie: no. I was being lazy because I knew that lifeless knew what I meant [00:53] ok :) [01:12] jelmer: around? [01:13] abentley, hi [01:13] igc: 4. profit ? ;-) [01:13] jelmer: Can I ask some questions about samba? [01:13] abentley: sure [01:15] jelmer: How stable is bzr-svn's 0.4 branch at the moment? [01:15] Peng: stable [01:15] jelmer: So it's okay to use instead of 0.4.10? [01:15] jelmer: The main question is, is Samba suitable for sharing to linux clients? I.e. can it preserve users, modes, etc? [01:15] Peng, at the moment, yes [01:16] I've only used it when the primary clients were win32. [01:16] jelmer: Are you planning to break it before the next release? :P [01:16] abentley: Yes, when you're using a recent version of Samba and CIFS VFS (mount -t cifs rather than mount -t smbfs) [01:16] Peng: no plans :-) but not guarantees either.. [01:17] jelmer: cool, thanks. [01:17] abentley: It's more POSIX compliant than NFS3 and even more compliant than NFS4 in a lot of cases [01:17] Maybe I'll keep using 0.4.10 as long as it works with bzr.dev. If it still does. [01:18] jelmer: great. [01:19] Yeah, it does. [01:20] Peng: 0.4.10 is broken with bzr.dev (push for example) [01:21] Oh. [01:21] Broken as in traceback or corruption? [01:25] traceback [01:25] corruption never happens because of mismatching versions === mw is now known as mw|out [01:58] poolie: found the plugin ? :P [01:59] abentley: is branch.conf meant to be human edited or bzr edited? [02:00] lifeless: Yes. [02:00] hmm [02:00] Same as bazaar.conf. [02:01] what settings from it are copied on clone/sprout? [02:02] I can't think of any values that are copied. [02:02] ok === kiko is now known as kiko-zzz [02:02] igc: go ahead [02:03] lifeless: It contains values like parent location, push location, bind location. [02:03] lifeless: thanks [02:04] lifeless: summary email on its way now too fwiw [02:09] igc: thanks [02:10] poolie: call? [02:21] beuno: are you still up? [02:22] hi everyone. I just wanted to know. Is olive-gtk currently the best available option for a gui interface to bzr? Or are there any better options? (I would prefer gtk over qt, but it' s entirely a matter of (visual) taste) [02:22] what I was looking for is some app that makes viewing change history easy (something like trac, but as a client app, instead of requiring a webserver) [02:25] mwhudson, yeap [02:25] beuno: cool [02:25] beuno: so my understanding, roughly speaking is that you have done four things to loggerhead recently: [02:25] 1) remove the use of deprecated methods [02:25] 2) switched to using zpts [02:26] 3) some ajax-y stuff for revision views [02:26] 4) use cleaner urls [02:26] beuno: would that be a fair summary? [02:28] mwhudson, generally, yes. Although 3) required generating a new controller from scratch for diff, and changing how the revision view is generated [02:28] ok [02:28] so what i would _like_ is to have one branch for each of these things :) [02:29] (they don't all have to be brances off trunk, i'd expect the branch for 3) to be a branch off that for 2), for example) [02:29] ah, good, was about to say that :) [02:29] and, well, 4) off 2) also, since it's mostly templating work [02:29] sure [02:30] ok, I can do that, now, where could I find a good VCS to help me with that... [02:30] heh heh [02:31] beuno: i'd like to review the branches for 1 and 2 today if i can [02:32] mwhudson, oh, sure. I'll get right on it. 1) would be with KID than? [02:32] *then [02:32] beuno: yeah, i think so, the changes are entirely independent of the templating stuff [02:32] and this branch is more urgent [02:33] yes, I see where you're going. I'll push em to LP and ping you [02:33] thanks a lot [02:34] you could even send merge requests to the bazaar list :) [02:35] sure, whatever is better. Will BB get confused if I send with [MERGE]? [02:37] yeah, i guess [loggerhead/MERGE] [02:41] hmm, is there anyway of running bzr viz in a repository? [02:41] (i.e. with multiple heads) [02:45] beuno: any idea how long this is going to take? i.e. a few minutes, an hour, tomorrow? [02:45] beuno: don't want to pressure, just want to know [02:45] mwhudson, I'll send 1) in a few minutes [02:46] cool [02:46] and 2) by the end of the day [02:46] as I see it, 3) and 4) stack up on top of 1) and 2) [02:48] You can run viz on multiple branches... [02:48] fullermd: you can? [02:49] beuno: isn't it rather late for you already? :) [02:49] beuno: but sounds good [02:49] * mwhudson heads out to buy some chocolate to fuel the review [02:49] mwhudson, I've seemed to moved to new zeland time zone these past weeks :) [02:49] beuno: heh [02:50] Yah, just hand it a couple on the command line. [02:50] (I haven't really used it, but I've done it) [02:51] fullermd: maybe my bzr-gtk is too old, it doesn't work for me [02:52] NEWS says it was on 0.94.0 [02:52] 0.93.0 [02:52] oh well [02:54] beuno: glad you like it [02:56] lifeless, I may even attempt to get it working within loggerhead, when I run into some free time [02:57] a pre-alpha version of it will be *way* better than what there is today :) [02:59] :P [02:59] surely not ? [03:00] mwhudson, we sould really disable full text indexing by default [03:01] it makes my core2duo 1.5gb of ram cry for a good hour on bzr.dev [03:01] holy crap [03:01] are you sure it only indexes the commit messages? [03:01] I promise :) [03:01] how the hell can you spend more than a few seconds indexing bzr.dev's commit messages. [03:02] I reckon you are missing a lock_read() or something similarly inane [03:02] I'd rather invest time in getting it to work with something new (bzr-search, for example) than fixing the horrid current sqlite thingie [03:03] k [03:03] (I'm sure the underpinnings are not that different though) [03:03] poolie: bzrlib.tests.test_lockdir.TestLockDir.test_35_wait_lock_changing is failing sporadically for me. I mention this because I thought it was fixed? [03:05] lifeless: i think i already explained that loggerhead's text indexer is worse than you can possibly imagine, didn't i? [03:05] i wasn't kidding [03:07] * igc lunch [03:07] mwhudson, patch for 1) sent off to the list [03:08] mwhudson: I thought my imagination had more power [03:09] mwhudson, I'm off for ~2 hours, and I'll be back to send 2) with 1) merged into it, and other tweaks it needs to work properly [03:10] beuno: ok, have fun [03:11] lifeless, http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk/annotate/launchpad%40pqm.canonical.com-20080418101647-2k1lv1l0edudd191?file_id=textindex.py-20061219035715-norgqx0pl0hxdax8-1 [03:11] for your amusement :) [03:15] mwhudson, oh, and I just remembered, not sure what that list is for, but I also tried genshi as a templating engine, which failed miserably :) [03:16] beuno: right, i'm not expecting to merge that one :) [03:16] jelmer: thanks [03:16] * beuno is off [03:18] beuno: bye [03:21] holy cow [03:21] thats scary shit [03:22] I mean, might want to tweak the term generator in bzr-search to combine robert's -> roberts rather than robert's -> robert, s [03:22] but thats stemming which I punted on [03:37] is there an IRC bot out there that'll watch bzr repos for changes? [03:39] I believe so [04:11] so bookmarks and lp: urls don't really get on [04:13] yay for stacking [04:29] lifeless: re that test - i have a patch that addresses it but there was some nontrivial review pushback, i need to revisit it [04:30] uh [04:30] i tried doing an incremental patch towards it, introducing a different error for "waiting for lock timed out" from "lock is not available at this instant" [04:30] which i think will make those tests clearer and not timing dependent [04:30] but the increment was not compelling by itself [04:44] poolie: k [05:18] back [05:18] mwhudson_, so, 2) then? [05:20] beuno: yes please :) [05:21] on it [05:35] hey guys [05:35] when someone deletes a directory in bazaar and the directory has pyc files, I get conflicst [05:35] yes [05:36] known issue, no good answer so far === lamont` is now known as lamont [05:40] lifeless: ok. cool. [05:42] (you need a way to separate 'my-bank-details.txt' which I ignored so it wouldn't be added from 'foo.pyc' wchich I ignored so it would not be added [05:43] need to somehow consider the former to be...precious ;) [06:00] or the latter to be junk [06:01] but this has complexity impact [06:12] mwhudson_, do you want the 2) patch relative to 1) or trunk? [06:12] relative to 1) please [06:13] beuno: i [06:13] coming up [06:13] 'm not going to be working for much longer today, btw [06:13] i'll look at it first thing tomorrow [06:13] oh, but it's only 3k lines... :p [06:14] :) === mwhudson_ is now known as mwhudson [06:14] i know, i'm lame [06:18] mwhudson, sent [06:19] I'll prepare the other 2 tomorrow [06:37] beuno, hi [06:37] hey there poolie [06:41] beuno: what a circus :-} [06:42] poolie, heh, the past weeks have been pretty active :) [07:02] abentley: lol, I have this image of bb running around going 'I'm freaking out mAAAAAAN' [07:03] hahha, I was just thinking that. With ian's patch in it's hand [07:03] lifeless: hehe [07:33] Hi. Anybody know what 'KnitCorrupt: Knit corrupt: incorrect number of lines 221 != 152 for version {svn-v3-single1-dHJ1bmsvbWFpbg..:6226825f-cf0a-0410-9073-f4040cba8958:trunk%2Fmain:116353}' means? [07:37] I'm off to bed. G'night everyone [07:40] night beuno [07:42] fdv: my first thought would be a symlink with newlines in it in the source svn repo [07:43] lifeless: ah [07:43] because I *think* bzr-svn generates its own knit hunks or something like that [07:43] that revision had broken symlinks, but I tried removing those nodes [07:43] jelmer: ^ any thoughts [07:44] what are knit hunks, really? [07:46] fdv: records containing the lines added in a revision, basically. [07:47] ok.. [07:47] Usually just the new lines, and a record of the lines removed. Sometimes a full copy of a file is stored rather than just a delta, depending on various conditions. [07:47] right [07:48] Basically, low-level guts :) [07:48] I removed all the nodes containing these symlink edits from the dump file and repopulated the repo [07:48] and then tried pulling it again [07:48] igc: Do you have a clear idea what you need to do to generate a mergeable directive? [07:49] fdv: did you clear the output repository? [07:49] fdv: or remove the corrupt revisions copied into it? [07:49] lifeless: absolutely :) [07:49] abentley: use bzr.dev as the submit_branch [07:49] lifeless: I couldn't remove the whole revisions [07:49] only the nodes affected [07:50] abentley: I don't get hope to get the right preview diff though ... [07:50] igc: And you can use -r to specify the cherrypick you want [07:50] so -rancestor:../foo.bar? [07:50] igc: bzr send -r thread:..-1 [07:50] igc: you should never need to touch -rancestor with send and a loom [07:50] lifeless: I've exported the loom [07:51] igc: oh, don't [07:51] igc: :) [07:51] igc: I send all my patches for loom-branches direct from the loom [07:51] lifeless: I didn't know better and smart people told me to :-) [07:51] AIUI export-loom exists solely for use with launchpads internal review system which is not loom aware [07:52] BB doesn't have the same flaws [07:52] lifeless: Not true, also for dealing with PQM [07:52] abentley: oh, I guess. I do all my merges via an integration branch, so it never occured to me [07:52] abentley: (bzr pull $source --overwrite && push --overwrite && pqm-submit -m '...') [07:54] igc: Anyhow, are you able to get a reasonable preview diff? [07:54] just trying now [07:57] abentley: in the case of StackableBranch, not by using -rancestor:../Development1 :-( [07:58] I guess the preview is the least important bit [07:58] but it annoys people reviewing in the mailer [07:58] igc: The preview reflects the merge you are requesting. [07:58] If it's wrong, your request is wrong. [07:59] abentley: the preview contains the right changes vs bzr.dev [07:59] but it's more than I wanted in the preview because it includes the changes from 'threads' below [07:59] igc: honestly, do the BB submissions direct from the loom [08:00] igc: with 'bzr send -r thread:..-1' from within each thread. [08:00] igc: it will JustWork [08:00] (I mean, this is the sort of scut work that loom is _meant_ to manage for you) [08:00] * abentley has send -r thread: aliased as tsend [08:01] lifeless: understood. Why the ..-1 ? [08:01] exactly [08:01] current tip [08:01] igc: a -r spec generally specifies the tip. [08:02] igc: you want from the thread below (thread:) to the last commit (-1). But giving send one revision says 'from bzr.dev to that revision) [08:02] So -r thread: specifies the tip to be the tip of the previous thread, which is wrong. [08:02] ok [08:02] You can probably specify "-r thread:.." but I haven't tried that. [08:03] I try sending from the loom now [08:05] Alternatively, you can specify the revision-ids from your previous submissions. i.e. "bzr send -r revid:ian.clatworthy@canonical.com-20080610013832-9dt6c5h67eckiezo..revid:ian.clatworthy@canonical.com-20080610045325-hi3yug3nasoe6e1h ../bzr.dev" [08:05] will loom become part of bzr? [08:05] gour: do you mean 'will it be part of the tarball' ? [08:06] gour: if so, probably, we plan to roll popular plugins into the release tarballs. [08:06] lifeless: yes. otoh, 'loom' is not listed at http://bazaar-vcs.org/BzrPlugins or i'm blind [08:08] lifeless: wrt. the knit error, could the revision be cached or already (half way) applied somehow, so that I don't get it from the new repo I set up, but still from the old one (which is broken)? [08:08] fdv: yes [08:08] ah [08:08] fdv: I would try importing to a fresh ('bzr init --rich-root-packs') tree [08:09] crap [08:09] that's three more days :p [08:09] well [08:09] but if that's what it takes.. :) [08:09] you have corrupt content in your target repo [08:09] removing knit references is not the simplest thing to explain [08:09] I can't roll it back somehow? [08:09] that's all right [08:09] if it's the only feasible solution, I'll start from scratch [08:10] we dont have an automated UI for removing single revisions at the moment [08:10] I think I have a corner case here :) [08:10] oh, there is need for it [08:10] it needs someone to write a ui for it using the low level primitives [08:11] I see [08:11] are there some docs anywhere? :) [08:11] if you have a pack repository, pydoc bzrlib.repofmt.pack_repo [08:12] (for a pack repo its basically 'copy everything to a new pack except hwat you want to remove, then discard the old packges') [08:12] igc: I'm off to bed. If in doubt, run a test against a local bzr.dev that doesn't use the same shared repo. [08:12] ok [08:12] for a knit repo its 'remove low level index entries' by doing the same on a per file-id basis [08:13] svn folks released svn-1.5rc10 :-/ good luck to those living with such software [08:13] lifeless: ok, I'll try to have a look. Don't have too high hopes, thouhg :) [08:14] ...requiring 10rcs [08:16] fdv: don't stress about it :P [08:16] no, but it'd be interesting to have a look === mneptok_ is now known as mneptok [08:28] beuno: test a little, code a little :) I don't think you need to duplicate tests for a --dry-run option. TDD helps in *reducing* code duplication after all. Some blackbox tests should be enough. [08:28] later all, dinner time [08:33] ok, I think I've stopped BB freaking out now. Let's hope so. [08:41] night all [08:41] night [08:44] cheerio igc === poolie changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org | please test 1.6beta2 | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/ [08:44] 1.6b2 is out [08:55] hello guys, does bzr can be integrated with trac? [09:01] guys is launchpad.net seems to be like trac? [09:08] toyto1: There's a bzr-trac thingy, but I don't think it's 100%. [09:08] toyto1: And yeah, Launchpad has some similarities to Trac. No wiki though. [09:10] seeing that trac-0.11 is still no out...hmm [09:11] night all [09:13] toyto1: have you seen http://www.redmine.org/ ? [09:13] Peng: ah i see:) [09:13] gour: what's that? let me check [09:14] Peng: I didn't find how-to their with bzr-trac for integrating :( [09:14] toyto1: it's what trac-2.0 will maybe become. it's RoR app, but still [09:16] gour: so you mean is that redmine is more advance than trac as of now? [09:16] toyto1: yep, more support for SCM, multi-project etc. however, we choose roundup (http://roundup.sourceforge.net/) - no need for wiki [09:22] gour: I see thanks for the info :) [09:22] ;) [09:32] help! [09:32] bzr: ERROR: Revision {foo@bar-20080606164431-373v96de5ba508yi} not present in "revisions.kndx". [09:32] ... at a bzr branch ... [09:37] mtaylor: https://bugs.edge.launchpad.net/bzr/+bug/232270 [09:37] Launchpad bug 232270 in bzr "Cannot checkout -- KnitCorrupt: attempt to add line-delta in non-delta knit" [Undecided,New] [09:37] james_w: ah [09:37] are you using a smart protocol for whatever operation you are doing? [09:38] for that one. [09:38] it's possible someone used sftp or something though [09:38] james_w: it is all bzr+ssh:// [09:39] james_w: I have a 2nd tree that is a bit more up-to-date that has that rev-id and I can pull nicely into that tree [09:40] only if I use a tree that is "before" that rev-id the branch/pull/log/... all fail [09:40] if you use sftp:// it should work. [09:41] james_w: it does [09:41] and interestingly a $ bzr log --show-ids sftp:// shows me the {foo@bar-20080606164431-373v96de5ba508yi} [09:41] hang on, are you two working together on this? [09:41] james_w: yep :) [09:42] ah :-) [09:42] ok, it's some problem with the smart server, I've updated the bug report about it, you can subscribe if you wish to follow the progress. [09:43] a full traceback of the error would be very useful, you can find one in your ~/.bzr.log. [09:43] you can edit out the details, but the traceback would be really helpful. [09:43] so, there still isn't a pack-based format that you can upgrade to from dirstate-with-subtrees ? [09:44] you should be able to upgrade to --rich-root-pack if you don't actually have any subtrees I believe. [09:45] james_w: http://pastie.org/212084 [09:45] james_w: we don't _think_ we are using any (at least, we aren't on purpose) [09:45] this is the one for bzr log failing [09:46] james_w: but upgrade --rich-root-pack still b0rks [09:46] weigon_: thanks. That's a different error from the "bzr branch" error, could you possibly provide that one as well, it would be great to have as much information as possible. [09:47] sure [09:47] mtaylor: is it an error about this problematic revision, or something unrelated? [09:47] james_w: something unrelated - I was trying upgrading to packs to see if that would help ... but now I'm just fixed on the fact that I _can't) [09:48] heh :-) [09:48] sounds like it would be worth a separate error report then. [09:49] yay! two bugs in one swipe! [09:49] james_w: http://pastie.org/212087 [09:50] thanks team. [09:50] I'll put those in the bug report if you don't mind, as we don't have good info there yet [09:52] shall I add it so you have a reference for more info ? [09:53] I think there may be enough there to know what is going on. I'm no expert in this area though. [09:53] k [09:53] there's also a public branch there that is reported to exhibit the problem, so it can always be reproduced by the developer. [09:53] thanks for your help. [09:54] the sftp:// idea is good enough for now [09:54] thanks [09:57] james_w: the story goes on with $ bzr merge ... let me paste it [09:59] james_w: http://pastie.org/212089 [10:01] ok, do you understand what the error message is saying? [10:11] james_w: it tries to find the common ancestor where the two trees are related and can't find it [10:12] yup, are these two trees supposed to be related? [10:12] this is the same tree that has the other problems :) [10:12] they are related just a few revs before the unknown rev-id [10:13] I assume that this is just a side-effect, as bzr thinks it can't find one of the rev-ids along the way and jumps out [10:22] gour: The SVN team have always been cautious about version numbers ; I remember how long it took them to get to 1.0 === mwhudson__ is now known as mwhudson [11:13] Hi, I'm getting extensive merge conflicts when merging two trees(383 conflicts). It feels like it select's a very old base. The manual hints about specifying a specific base to use. But I can't figure out how to do that. Any ideas? [11:16] Have tried to remerge with "bzr remerge --weave " and that will bring the number of conflicts down, but at the same time some changes will be lost and it's not possible to use "bzr extmerge" after that since ther is no .BASE, .OTHER and .THIS anymore. === cprov is now known as cprov-lunch [11:56] blaudden: try --lca instead of --weave maybe [11:56] blaudden: I'm not sure what you mean by "some changes will be lost" [11:57] spiv: yes, I tried --lca also [11:59] spiv: When running the binary it wil crash and I find one place where the merge has removed two lines instead of conflict them. That makes me a little scared and I start to think about other places being merged that way but that doesn't cause an immediate crash. [12:03] when i use bzr with http+ftp, does that create special traffic or abuse the sever?^^ [12:08] blaudden: that's always a risk with an automatic merge tool [12:09] spiv: :) [12:09] blaudden: just because one branch adds a line here and another removes a line there, in non-overlapping parts of the code, doesn't mean there isn't a semantic conflict. [12:10] blaudden: a trivial example is a branch that adds an extra parameter to a function, and updates all the callsites to pass the new parameter. If you have a branch that adds another call to that function, then merge the first branch in, you probably won't get an automatic conflict. [12:10] blaudden: but the code won't work [12:11] blaudden: so you ought to run the test suite and/or review the diff and/or do some other QA to check that the result is sane. [12:12] spiv: yes, that example seems resonable [12:12] fredreichbier: Do you mean ftp or http, or some ungodly hybrid of the two? ;P [12:12] fredreichbier: not sure what you mean by "special" traffic. It is just regular ftp/http, it doesn't do anything crazy. [12:13] You can abuse the server with regular traffic if you have enough of it, though ;) [12:13] fredreichbier: http mostly uses Range requests, which can confuse Squid. It also might make quite a lot of requests in a short amount of time, especially with a knit repo. [12:14] spiv: In this example it's someone who changed part of the line, and in addition the order of that line and the line above has changed place in one of the branches. [12:14] Peng: spiv: i mean http-pulling and ftp-pushing. thanks your your answer ;) [12:15] fredreichbier: You should use bzr+ssh or at least sftp. ftp sucks. It's not encrypted. [12:15] Peng: i need access to the server to use bzr+ssh, and i don't have ,) [12:15] blaudden: please feel free to file a bug with that example if you think bzr ought to do better there, btw. [12:15] fredreichbier: What do you mean? [12:16] blaudden: our merges are generally very good, but there's always room for improvment [12:16] spiv: ok, I'll see if I can make something reproducible... [12:17] Peng: i thought i have to set up a bzr server (`bzr serve`?) on my server to use bzr+ssh, don't i? [12:17] fredreichbier: you just need bzr installed on the remote side [12:17] fredreichbier: For bzr+ssh, you need to have ssh access (duh), with bzr installed and in the PATH. [12:18] fredreichbier: bzr+ssh simply sshes in and runs "bzr serve --inet --directory=/". [12:18] fredreichbier: (Err, the process doesn't stay around like a normal "bzr serve". --inet causes it to close when you're done.) [12:19] Peng: (it also passes --allow-writes) [12:19] spiv: Oh, right. [12:20] thanks Peng ;) I have a shared hoster without ssh access, that's the problem. [12:20]