[12:02] abentley: IIRC it was pournelle and ??? in 'The mote in gods eye' [12:02] lapthrick: AddHandler None .knit .kndx [12:02] the gripping hand was the big overdeveloped arm, not the fine-tuned hand [12:02] oh yes, they did a book called that too [12:02] Lo-lan-do: .htaccess by default is valid for all subdirs unless overrided, right? [12:03] Yeah, Pournelle/Niven, but I think the "on one hand, on the other hand, on the gripping hand" phrase came from the sequel, "The Gripping Hand" [12:03] Right [12:03] Anyhow, I'll look the patch over now. [12:04] abentley: could be, I don't think I've read the sequel === lifeless notes to do so [12:09] jelmer: I pushed my gateway branch to http://alioth.debian.org/~lolando/bzr/gforge/upstram-svn/trunk -- it contains the stuff that I'm trying to push to SVN [12:11] I'm off to bed for now, but I'll be available in the next few days to provide info if needed. [12:12] Thanks already for the time you spend on my bugs :-) === Lo-lan-do [n=roland@mirexpress.internal.placard.fr.eu.org] has left #bzr ["Leaving"] [12:14] abentley: Do you mean Haruki, Ryu, or Takashi? :) [12:14] Heh, Haruki. [12:14] (the first three Murakamis that have written books that I can think of) [12:15] ok yeah, figured ;-) [12:15] funnily enough, they're all flaming postmodernists [12:15] I also read this blog about SCO by Jones. [12:19] that's probably not postmodern :) === corporate_cookie [n=richie@seraphim.asbury.edu] has joined #bzr [12:22] radix: No, but SCO is a significant author of speculative fiction. [12:22] haha === Demitar [n=demitar@c-212-031-182-147.cust.broadway.se] has joined #bzr === jml [n=jml@ppp121-44-213-76.lns1.hba1.internode.on.net] has joined #bzr === fog [n=fog@debian/developer/fog] has left #bzr [] [01:03] is there some more documentation on bugs metadata in bzr? [01:03] help bugs isn't very verbose [01:07] there is a document in the docs [01:07] doc.bazaar-vcs.org/bzr.dev/en/ [01:08] thanks [01:10] is the immutability inherent in the design, or just something to be implemented? [01:10] what do you mean [01:11] lifeless: http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/bug_trackers.html , section Limitations [01:11] is that limitation supposed to be removed? [01:12] not in the short term [01:12] the reason its immutable is that its part of the commit [01:12] so changing it would involve changing the commit, which is part of history [01:13] one can imagine a more complicated system where later commits can 'revert' things, but that hasn't been really designed or discussed at this point [01:14] lifeless: I see, I was reading http://bazaar-vcs.org/Specs/RevisionBugMetadata [01:14] which indeed does discuss that :) [01:14] well [01:15] in terms of concrete goals [01:15] there are no patchs, nor folk hacking on, the more complicated sorts of things [01:15] so far no one has needed them [01:17] aha === igc [n=igc@ppp59-167-96-213.lns3.bne1.internode.on.net] has joined #bzr [01:41] igc: call ? [01:41] yep - 10 mins === jimrth1 [n=jimrthy@ppp-70-128-113-172.dsl.tulsok.swbell.net] has joined #bzr [01:57] lifeless: you at home? === corporate_cookie [n=richie@CPE-76-177-101-92.natcky.res.rr.com] has joined #bzr === thumper [n=tim@canonical/launchpad/thumper] has joined #bzr [02:30] lifeless: I don't think _apply_delta is unused. I think the reason nothing else needed to be changed is that static methods can be invoked on instances as well as on classes. [02:33] abentley: true enough, still leaves it as a no-op change though [02:33] robertc@lifeless-64:~/source/baz/test-repos/mozilla$ time ~/source/baz/repository/bzr commit -m 'commit' --unchanged -q [02:33] [02:33] real 0m58.889s [02:33] user 0m50.591s [02:33] sys 0m3.640s [02:33] robertc@lifeless-64:~/source/baz/test-repos/mozilla$ time ~/source/baz/repository/bzr commit -m 'commit' --unchanged -q a [02:34] [02:34] real 0m27.626s [02:34] user 0m25.538s [02:34] sys 0m1.504s [02:34] 25 seconds to *just* do the overhead of a commit for a single file. [02:34] I'm going to target this for a bit [02:34] It does remove the artificial requirement for a knit instance. [02:34] lifeless: adding staticmethod is a good change iff semantically it has nothing to do with the current object [02:35] that's certainly the case in terms of the implementation fwiw [02:35] abentley: this is true, but it also makes it unvariable when you have a knit. I think moving it closer to the users would make sense. [02:35] rather than just bit-twiddling [02:36] I mean, applying a delta would seem to be be related to the delta representation [02:36] and/or the content representation [02:37] How do you mean unvariable? [02:37] well object methods are mainly to allow code to vary based on the content of the object [02:38] if this method has no dependencies *in principle* on the content of the object, then its probably on the wrong object [02:38] I'm with you there. [02:39] so the params are lines and delta ... [02:39] it operates on lines and returns lines [02:39] igc: if delta is returned by another method on the VersionedFile, then delta is linked to the VersionedFile [02:39] igc: so its not clear from this level of discussion that there is no connection [02:40] anyhow, I've said my bit [02:41] lifeless: But it's trivial to imagine an implementation of iter_file_versions directly on top of packs, using knit deltas. And that would clearly have no need for a versionedfile of any kind. [02:41] abentley: I agree. However it could sensibly use a KnitData instance [02:42] there is delta assembly too [02:42] so being able to use a single KnitSomeThing instance to manage that implementation would be good [02:42] something that takes (fileid, revisionid) keys and uses the index directly without the mapping thunk layer [02:43] Yep, we're agreed there. [02:44] lifeless: know where poolie is? [02:44] thumper: yes [02:44] I think the reason we don't have something like that already is that knit deltas are not objects. === kgoetz [n=kgoetz@gnewsense/friend/kgoetz] has joined #bzr [02:44] abentley: well there is KnitData/KnitContent. [02:45] abentley: I'm not sure that individual delta objects are the problem [02:45] its more that the delta application stuff was conflated with storage. [02:45] KnitData vs KnitAccess has fixed that [02:45] lifeless: sometimes you remind me of a friend in the UK (never answered the implied question) [02:46] thumper: I'm proud to remind you of a friend :) [02:46] thumper: oh, and merf says hello [02:46] merf who? [02:46] michael murphy [02:46] from uni [02:47] KnitData looks more akin to ContainerReader. KnitContent looks plausible. [02:47] lifeless: ah, where is he now? [02:47] Sydney [02:47] doing? [02:47] we had Jason's bucks night last weekend [02:47] cool [02:48] it go well? [02:48] oh, hes running something in the money market space for commbank [02:48] yah [02:48] abentley: so is moving _apply_delta into knit.py (and out of versionedfile.py) agreed as an improvement? [02:48] lifeless: I think that qeebo revision of yours is definitely strange. [02:48] don't have a sound-bite label for it unfortunately, but he's happy and it sounds fun and interesting [02:48] lifeless: In that the second parent does seem to be in the ancestry of the first parent. [02:49] spiv: yah. Want to be a cherrypick merge will do that [02:49] igc: If we are talking about the optimal place, that looks like it. I'm also happy with a staticmethod, or the status quo. [02:49] *bet* [02:50] spiv: try this on for size: [02:51] bzr branch -r 2634 bzr.dev foo; bzr merge -r 2591..2592 ; bzr st === NamNguyen [n=namnt@203.162.163.50] has joined #bzr [02:52] spiv: its merging in a revision that was already merged previously, but had had its text discarded [02:53] spiv: but even so, the heads() calculation for me gives the right single parent case [02:53] lifeless: right, but we don't record cherrypicks yet? [02:53] its not a cherrypick :) [02:53] because the base revision is in the ancesty [02:53] Sounds more like a cherryununpick. === poolie [n=mbp@86.228.233.220.exetel.com.au] has joined #bzr [02:54] good morning [02:54] hi [02:55] lifeless: ah, that does indeed create it. Weird. [02:55] morning poolie [02:55] spiv: normal IMO [02:55] spiv: its unusual but still a valid DAG [02:55] (incidentally bzr viz just ignores the second parent for the purposes of drawing lines) [02:55] spiv: yes, I wrote that code :) [02:56] its the same logic as bzr log uses for indenting [02:56] lifeless: well, "weird" in the sense that I had thought that "bzr merge -r X..Y" wouldn't record a pending merge, but it turns out the world is more complicated. === corporate_cookie [n=richie@CPE-76-177-101-92.natcky.res.rr.com] has joined #bzr [02:56] lifeless: thanks for satisfying my curiosity about that. [02:56] :) [02:56] np [02:57] Could this be related to igc's restoration of my patch that jam reverted? [02:57] yes [02:57] jams patch apparently reverted many things [02:57] mine was restored months ago [02:58] but I don't think igc could have caused the parent confusion [02:58] revno 2614 was the merge [02:58] fwiw, I used patch -p0 to apply abentley's changes to bzr.dev [02:58] lifeless: so, what information in the corrupt bzr.dev repo can be used to deduce that file revision has the wrong parents? [02:59] spiv: left_parent = r.get_inventory(p1)[fileid] .revision [02:59] lifeless: did you say InventoryEntry.find_previous_heads figures it out? [02:59] spiv: My reconcile algorithm ought to determine the correct parents already. [02:59] right_parent = r.get_inventory(p2)[fileid] .revision [03:00] abentley: *nod*. I want to figure out why it isn't. [03:00] correct_parents = r.get_graph().heads([left_parent, right_parent] ) [03:00] spiv: the algorithm is applied only when there are unreferenced parents. [03:00] for me, that returns just one [03:00] This parent is clearly referenced. [03:00] abentley: ah, I see. [03:01] so disabling the condition to only check when its not referenced should be enough [03:01] d === mw [n=mw@189.146.19.173] has joined #bzr [03:06] hmm [03:06] perhaps we should catch UnicodeDecodeErrors and log them, then show a nice user error IFF their locale is C [03:06] otherwise raise them as normal [03:06] (in run_bzr_) [03:09] spiv: I have paged the algorithm back into memory. Ping me if you want a description, but I gather you've already been looking at that code. [03:09] abentley: thanks, I think I'll be ok, but I'll let you know. [03:25] lifeless: that patch submitted to pqm now === RichardL_ [n=Skippy@78.32.35.169] has joined #bzr [03:35] Ok, I have a version of Aaron's reconcile that does correct that problem. === orospakr [n=orospakr@bas11-ottawa23-1088839886.dsl.bell.ca] has joined #bzr [03:36] Now to polish it and test it properly... [03:36] lifeless, abentley: it's safe to say I understand this stuff much better than I did a week ago... [03:36] cool [03:40] igc: thanks [03:40] spiv: cool [03:42] Boy I wish reconcile gave some progress indication. [03:43] Maybe it figures it would just be too depressing. [03:43] fullermd: I want to know how depressed to be! :) [03:44] It's the depression with no visible end that gets me down... ;) [04:01] Good grief reconcile is slow though. [04:01] I guess NEWS has a particularly large history, but even so... === jdong [n=root@ubuntu/member/jdong] has joined #bzr === AfC [i=andrew@office.syd.operationaldynamics.com] has joined #bzr === igc [n=igc@ppp121-45-207-115.lns1.bne1.internode.on.net] has joined #bzr [04:07] it spins [04:08] just give it some progress figures === corporate_cookie [n=richie@CPE-76-177-101-92.natcky.res.rr.com] has joined #bzr [04:13] 20 minutes just to check the NEWS knit. === poolie_ [n=mbp@86.228.233.220.exetel.com.au] has joined #bzr === jdong [n=root@ubuntu/member/jdong] has joined #bzr === pete__c [n=pete@032-463-246.area7.spcsdns.net] has joined #bzr === siretart [i=siretart@ubuntu/member/siretart] has joined #bzr === jrydberg_ [n=johan@213.115.45.46] has joined #bzr === spiv [n=andrew@canonical/launchpad/spiv] has joined #bzr === sii [n=sii@tranquillity.sii.se] has joined #bzr === dato [n=adeodato@debian/developer/adeodato] has joined #bzr === Radtoo [n=mschmid@84-75-167-50.dclient.hispeed.ch] has joined #bzr === AndyP [n=andyp@ubuntu/member/welshbyte] has joined #bzr === SteveA [n=steve@canonical/launchpad/SteveA] has joined #bzr === dholm [i=dholm@gentoo/developer/dholm] has joined #bzr === [PUPPETS] Gonzo [i=gonzo@80.69.47.16] has joined #bzr === metze [n=metze@ip-217-172-181-76.mx-netz.de] has joined #bzr === taaz [n=dlehn@66.37.66.32] has joined #bzr [04:43] lifeless: FWIW, the reconcile branch http://people.ubuntu.com/~andrew/bzr/reconcile-check-heads [04:44] its cooked ? [04:44] lifeless: it just has the manually tested fix, it's not fully cooked at all. [04:44] k [04:44] lifeless: how urgent is it for you that I cook it now? [04:44] if you don't, I'll have to [04:44] I can't work with bzr.dev till we apply it there, and uncooked code == buggy === spiv nods [04:45] Ok, I'll keep at it. [04:45] New bug: #130574 in bzr "Interrupting bzr log causes "bzr crashed with IOError in ()"" [Low,Confirmed] https://launchpad.net/bugs/130574 [04:52] So, what's the upshot of all of this fribbery with that ancestry lately? [04:52] Should I be avoiding updating my bzr.dev, or switching back to the release for my daily work? Or is it ignorable for us non-devs? [04:53] ignore it [04:53] we'll fix it and issue a bzr that will correct it all [04:53] Sweet. My favorite problems are those I can ignore :) === igc food [04:59] poolie_: my fix to not propogate changes has hit bzr.dev. [04:59] poolie_: I propose to move pqm to that version asap [05:00] not propogate randomish index changes I mean === orospakr_ [n=orospakr@bas11-ottawa23-1128668897.dsl.bell.ca] has joined #bzr === spiv -> food [05:19] OMG [05:19] regular bzr is /so slow/ now :( [05:21] are you teasing us? :) === thumper [n=tim@125-236-193-95.adsl.xtra.co.nz] has joined #bzr [05:22] not at all [05:22] I'm testing a specific optimisation for bzr.dev [05:22] and its making me cry [05:25] ah, I see [05:25] I read it as "haha, look at me with my faster bzr!" :D [05:25] initial commit of a moz tree with my hacked up bzr that I'm peeling off patches is 1m32 [05:27] with bzr.dev and the patch I'm currently testing it is ... 8m [05:28] wow, that's a substantial difference [05:29] yes [05:29] We've been working on performance [05:30] glad to hear [05:34] Is 0.91 due this week, or is it blocked on resolving that ancestry burp? === _thumper_ [n=tim@125-236-193-95.adsl.xtra.co.nz] has joined #bzr [05:35] its due === _thumper_ is now known as thumper [05:36] Cool. [05:55] anyhow, thats a clean 4% in that patch [05:56] igc: ^ [05:59] cool [06:05] add_inventory is 20% [06:05] update_builder is 37% === orospakr__ [n=orospakr@bas11-ottawa23-1088839879.dsl.bell.ca] has joined #bzr [06:11] fullermd: i'll probably do 0.91 when i get home [06:11] just spending some quality time w spiv now [06:14] Oh, I was just making sure I was up-to-date with plans. Not trying to rush you. === orospakr [n=orospakr@bas11-ottawa23-1177563682.dsl.bell.ca] has joined #bzr === orospakr_ [n=orospakr@bas11-ottawa23-1088840187.dsl.bell.ca] has joined #bzr === Vantage13 [n=Vantage@www.toddcharron.com] has joined #bzr === BasicOSX [n=BasicOSX@216.243.156.81.real-time.com] has joined #bzr [06:32] ok, of that 25 seconds, I've just nuked 7 [06:33] neat [06:33] it won't apply to non-selected-file commits unfortunately, but it will make it easier to see hot spots in the code that does apply [06:34] care to review that other patch ? [06:34] sure === BasicMac [n=BasicOSX@warden.real-time.com] has joined #bzr [06:47] garh benching on bzr.dev is breaking my balls [06:47] ..so.. ..slow.. [06:47] while this runs I'm going for a wlak to think === BasicMac is now known as BasicOSX === g0ph3r [n=g0ph3r@p57A0A9EC.dip0.t-ipconnect.de] has joined #bzr [07:11] woot [07:11] 50% saving [07:12] real 0m29.516s [07:12] user 0m27.594s [07:12] sys 0m1.236s [07:12] to [07:12] real 0m19.251s [07:12] user 0m17.897s [07:12] sys 0m0.768s [07:12] in bzr.dev [07:12] You're a rock star [07:12] well, not *quite* 50% [07:12] now to see if it passes tests, and if so send it in [07:13] AfC: I know :) [07:13] AfC: I have initial commit with packs faster than hg, on my laptop [07:14] darn this fails tests, I'll have to tweak it for corner cases. [07:14] lifeless: Initial commit... I know that's what you've been working on; that's for importing projects into Bazaar, right? [ie, unrelated to initial checkout?] [07:15] AfC: yes, the first experience for folk considering migrating an existing project to bzr [07:15] Sure [07:15] AfC: much of initial commit is present in incremental commit too [07:15] so wins there show up in incremental [07:15] Understood [07:21] bbiab [07:47] lifeless: you _really_ need to take half an afternoon and put something a bit more flattering up as a home page. [07:47] Eh, people have been telling me that for years. [07:47] lifeless: right now it doesn't even _mention_ Bazaar [07:48] fullermd: yeah, but if I link to Rob in a blog post, it's like embarrassing for him. [07:48] They usually phrase it as "Aiee, my eyes are bleeding!", but it means about the same thing... [08:02] What's lifeless's homepage. [08:02] ? [08:02] to say its bare bones would be to talk it up [08:02] AfC: I loath web design; someone who's eyes bleed enough will eventually offer me a new site [08:02] Mine is completely empty. [08:02] I just realized what I need to do: 1997! [08:03] But with valid HTML and CSS. [08:03] So it's ironic? [08:06] Anyone got a freely-licensed animated GIF of the U.S. flag? [08:07] lifeless: review sent to the list now [08:07] igc: + or - ? [08:08] few changes would be good I think [08:10] ok, I'll llook tomorrow [08:10] for now I want to get this 40% win polished === nocturn [n=nocturn@ubuntu/member/nocturn] has joined #bzr [08:16] Hi all [08:16] I'm relatively new to Bazaar and I think I made a mistake [08:16] I wanted to branch an existing project to which I only had a source tarball [08:17] So I unpacked it in project.vanilla and made that a Bazaar repo [08:17] I then created project.mybranch and imported the tarball again [08:17] I made my changes on mybranch. Now I would like to use diff and later merge as the vanilla version gets updates [08:17] but mybranch and vanilla have no common ancestor.... [08:18] Is there any way to fix this? [08:18] nocturn: if you've just done the one change, it may be easiest to do diff -r 1 on mybranch, then apply that through patch to a branch coming from the real import [08:19] uh [08:19] actually, why not just throw away project.vanilla, and replace it with === marianom [n=marianom@ubuntu/member/marianom] has left #bzr [] [08:19] bzr branch -r 1 mybranch vanilla [08:19] ? [08:19] I did multiple changes (3 actual releases of my branch) [08:19] poolie_: What would that do exactly? === pmezard [n=pmezard@nor75-4-81-56-59-92.fbx.proxad.net] has joined #bzr [08:20] that would give you a new 'vanilla' branch, containing the import you committed as the first on mybranch [08:20] but it would be known to have history in common [08:20] OK, and would that still be OK when I use diff and merge since Vanilla is actually the real mainline [08:20] right [08:20] Ok, trying... [08:21] have you done anything else with your original vanilla branch? [08:22] no, I didn't touch it. It belongs to someone else (I'm branching their projec) [08:22] then the best thing to do is to use the branch command :) [08:23] lifeless: Yeah :-) [08:23] Ok, did the branch === hdima [n=hdima@idealer.cust.smartspb.net] has joined #bzr [08:24] lifeless: hi, just reading this 4% branch [08:24] trying to understand [08:24] # If length == 1, then we only have the root entry. Which means [08:24] # that there is no real difference (only the root could be different) [08:24] - if (len(self.builder.new_inventory) != 1 and self._any_real_changes()): [08:24] + if len(self.builder.new_inventory) != 1 and (self.entries_changed or [08:24] + self.entries_deleted): [08:25] poolie_: Do I need to do anything special to remove the branch again? [08:25] nocturn: you can just either delete it, or i usually prefer to move it into a directory called 'Abandoned' [08:25] just in case i want it back [08:25] like a trash can [08:26] Is it wise to follow something like trunk,tags,branches in bzr too [08:26] no, better to just have the trunk and branches in one directory [08:26] as separate branches obviously [08:27] lifeless: the len(...inv) tests in there look a bit strange strange [08:27] poolie_: silly question, but how to I do that 'have the trunk and branches in one directory'? [08:27] the usual setup is [08:28] bzr init-repo myproject [08:28] bzr init myproject/trunk [08:28] lifeless: don't need anything fancy. Just a one paragraph bio, some bullet points about what you're _currently_ working on, and a photo. Don't need any of the rest of the bling. [08:28] (do stuff) [08:28] bzr branch myproject/trunk myproject/somefeature [08:28] lifeless: bring a photo jpg along this weekend and we'll hack someething up quickly. [08:28] AfC: photo. Eek. [08:28] lifeless: hackergotch at least :) [08:28] quick, look for a cookie monster jpg [08:28] i have some good photos of lifeless [08:28] i think [08:29] he can be the judge [08:29] poolie_: did I hear you say Bazaar 0.91 would be "today"? [08:29] poolie_: I think you're probably better placed to asses [08:29] AfC: yes i expect so [08:29] poolie_: they are strange but correct; its an artifact of 'the null tree has no root' [08:30] which I don't like but is entrenched now [08:34] bleh test output ordering failures. [08:35] ok fixed version I think, real 0m18.834s [08:35] user 0m17.645s [08:35] sys 0m0.580s [08:35] New bug: #141157 in launchpad-bazaar "Locks acquired via the smart protocol have poor lock info." [Undecided,New] https://launchpad.net/bugs/141157 === n2diy [n=darryl@wlk-barre-208-103-148-20.dynamic-dialup.coretel.net] has joined #bzr [08:40] ok, all commit tests pass, next round [08:42] looking good [08:42] 2K ok so far === AfC updates the time in the blog post he's writing [08:45] time? [08:46] It was 19.2 seconds. You just said 18.8 [08:46] (or was that for something else?) [08:46] down from 29.5s [08:48] oh right [08:48] so if you want the test scenario [08:48] this is a mozilla tree [08:48] doing 'bzr commit -m message FILENAME' [08:48] I'm aiming for that to be about 2seconds eventually, or less [08:48] long way to go to get there [08:49] this is just the low hanging fruity biscuits [08:49] lifeless: forgive me for being stupid, but isn't that incremental commit, not initial commit? [08:49] I'm talking about incremental today [08:49] *initial commit* figures: [08:49] bzr.dev [08:50] real 6m21.980s [08:50] user 3m16.668s [08:50] sys 0m18.469s [08:50] my experimental pack work, not all of which is stable enough to publish in any form (but I can supply patches for the *really* brave) [08:50] real 1m34.322s [08:50] user 1m20.829s [08:50] sys 0m4.668s [08:50] (Your comment was just the seed for me writing a blog post, but it's part of my contribution to the ongoing war in GNOME land about DVCS) [08:51] Ok, I'm reading TrackingUpstream here: [08:51] http://dev.marva.antwerpencentraal.be/ [08:51] Sorry, wrong url [08:52] http://bazaar-vcs.org/TrackingUpstream [08:52] How can I use SVN from upstream instead of CVS === abentley [n=abentley@bas8-toronto63-1088754407.dsl.bell.ca] has joined #bzr [08:53] bzr-svn [09:02] nocturn: bzr-svn is wicked cool [09:04] at this point, calling status, then a selected commit with the ids from status is still faster, have to hammer some more. [09:05] OK, thanks lifeless [09:09] igc: review requested [09:10] lifeless: sure [09:16] it should be obvious which one :) [09:17] lifeless: yes, and you're right re the nested tree stuff I think [09:23] Ok, got the structure set up [09:23] I created a repo with bzr init-repo project [09:23] and upstream and mybranch in that [09:24] Now, how can I check out the repo? [09:25] bzr checkout project/mybranch [09:25] or have I misunderstood what you mean? [09:26] lifeless: That checks out only my branch, can I checkout the entire repo? [09:27] Like an SVN checkout without specifying trunk [09:27] no [09:27] in bzr branches are *semantic*, they define structure [09:28] in svn there are no branches, which is a huge problem for programmatic use of svn [09:29] Ok, when I try to get the upstream branch, it says: bzr: ERROR: Not a branch === BjornT [n=bjorn@canonical/launchpad/BjornT] has joined #bzr [09:30] For mybranch too. [09:30] how did you make the branches ? [09:30] I created myproject with repo-init [09:30] then upstream with bzr init [09:31] then mybranch with branch upstream mybranch [09:31] I'm now trying a checkout over sftp [09:31] As I usually do [09:31] what sftp url are you using ? [09:32] sftp://hostname:/path-to-repo/upstream [09:32] (don't paste a password or anything, but the rest would be useful. feel free to mangle hostnames etc, but keep the path basically intact if possible) [09:32] ^ [09:32] erm [09:32] ^ [09:32] thats better [09:32] bzr co sftp:/bzrhost.domain:/home/bzr/marva/upstream [09:32] the second : is incorrect in SFTP urls, you would need a port number there [09:32] and you are missing a / [09:33] bzr co sftp://bzrhost.domain/home/bzr/marva/upstream [09:33] that will work better === pmezard [n=pmezard@dhcp26-226.enst.fr] has joined #bzr [09:33] Sorry, I need more coffee ;-) [09:34]