=== tommieb is now known as t0mm13b [00:38] spiv: I cheated, I submitted each one as being proposed to the previous one, rather than bzr.dev [00:46] jam, good point about testing the readdir change [00:46] i had not yet done it [01:49] poolie, jam: http://bazaar-vcs.org/Benchmarks [01:49] lifeless, spiv, vila: ^^^ [01:52] igc: the numbers for samba are pretty weird! [01:53] spiv: very. fastimport does an implicit pack at the end so maybe there's an obscure bug in that [01:54] spiv: or maybe samba's trunk is very dull vs other branches? [01:54] Also that the fully packed size is an order of magnitude smaller that git, unlike in the other tests. [01:56] igc, i saw that earlier [01:56] maybe before your changes [01:56] poolie: yep, new figures [01:56] http://bazaarvcs.wordpress.com/2009/10/08/bzr-size-benchmarks/ [01:56] are they pretty figures ? [01:58] poolie: the early hg figures were 'du -sb' instead of 'du -sh' - we're even more impressive now! [02:03] ? [02:03] oh, ignoring gas at the end of the files [02:03] yeah, real vs apparent size [02:04] actual size taken on disk is more meaningful IMO [02:04] yes [02:04] not just your opinion! [02:05] in actual practice, too! [02:13] wow yeah, those samba numbers are cracful === abentley1 is now known as abentley [02:57] poolie: hai [02:59] igc: interesting [02:59] hi lifeless [02:59] igc: its not clear to me what the 'bzr branch' column means [02:59] lifeless: see 'how we tested' [03:00] I have [03:00] lifeless: maybe it needs a different column heading? [03:00] so it's what a user gets when they grab just the trunk [03:00] step four in the process looks like one command [03:01] 'bzr trunk only' [03:01] or something, would be clearer [03:01] ok [03:01] it would be good to have a comparison figure for that too with hg/git [03:01] I realise that that is trickier to accomplish in git/hg [03:02] so I wouldn't suggestspending mondo time on it [03:02] ayhow, those numbers are very encouraging; the samba project figure is a bit disappointing [03:02] I presume that fast-import is cleaning obslete now? [03:02] lifeless: I'm wondering if it's a bug in fast-import? or pack? [03:03] yep [03:03] lifeless: it does a pack at the end and then deletes the obsolete packs [03:03] igc: repository-details may help diagnose [03:33] lifeless: figure out that group-pack problem re large binary files ? [03:33] / else. or should i file a bug. [03:37] Is losing secondary comments the only disadvantage of bzr revert --forget-merges when merging branches? [03:42] Is there a magic way to use meld when going through a conflicting file? [03:43] I realize that `bzr diff --using meld` does just that, but in the case of a conflict I'm trying to figure out if there's a better way to use it than manually doing [03:43] $ meld src/bindings/org/gnome/gtk/LinkButton.java.THIS src/bindings/org/gnome/gtk/LinkButton.java.OTHER [03:43] as I just did [03:51] d1b: the one where I explained bzr is operating as designed ? [03:51] d1b: you can file a wishlist bug on that if you like [03:56] lifeless: what is that, no deltas between pack files? [03:56] hey igc, the numbers look interesting. very good except for samba looking a bit crazy [03:57] jam: yeah. I was hoping you'd get curious and tell me why :-) [03:57] igc: I'd need the source data [03:58] I thought there was something about samba copying a bunch of v3 or v4 stuff into another tree [03:58] it may be that we end up tracking those separately [03:58] and not getting the right cross-file compression [03:59] igc: is the data accessible somewhere? [03:59] jam: no, N identical parallel files [03:59] jelmer: ^^ can you comment about the shape of the samba tree? [03:59] jam: I'll push the imported repo somewhere and email you the location [04:00] RenatoSilva: out of interest, why? [04:00] jam: also http://bazaar-vcs.org/BzrPopularity is interesting [04:02] bob2: because I want to use it :) [04:02] lifeless: you're talking about d1b's issue, right? (or samba?) [04:03] bob2: but I wonder if I'm doing WOP [04:03] jam: both possibly [04:03] jam: but intending to speak on dib's [04:04] RenatoSilva: don't know what that means [04:04] lifeless: so the idea is that multiple identical files aren't getting fully de-duped? [04:04] igc: i agree. Interesting that we are above hg, and the 39k there is close to the 36.7k that downloaded bzr-setup 1.13 [04:05] bob2: http://uncyclopedia.wikia.com/wiki/Workaround_Oriented_Programming [04:05] RenatoSilva: what are you working around? [04:05] ja 80MB images/movies [04:06] jam: 80MB movie files; separate file ids [04:06] bob2: I don't know, that's why I wonder :) [04:06] jam: right: the 39k is the combination of the different Windows installers [04:06] roughly [04:06] RenatoSilva: why are you reverting the merge metadata to begin with? [04:06] lifeless: yeah, and we explicitly cap a group based on file-id [04:06] bob2: the Portuguese version is so much better description :) http://desciclo.pedia.ws/wiki/Programa%C3%A7%C3%A3o_Orientada_a_Gambiarras [04:07] igc: I mean that popcon says 39k for installs, and we have ~39k downloads [04:07] jam: we did use too much memory though [04:07] lifeless: how much? [04:07] I would expect at least 160MB [04:07] since they aren't likely to zlib well [04:07] Note that popcon isn't reliable at all. [04:08] wgrant: as in a margin of error of 100%, or 20% [04:08] jam: Potentially thousands of percent. [04:08] I have no idea why you are counting downloads. I mean, other distros? People who don't have popcon installed? [04:08] I was mostly commenting about how close the numbers were [04:09] jam: It's optional, and well hidden in the installer. [04:09] AfC: number of downloads of the windows installer is probably pretty accurate, since there is one "canonical" source [04:09] jam: So not only will most people not have it turned on, those that do will be a very skewed sample. [04:09] bob2: I'm not reverting, but since I knew about --forget-merges, I thought it was nice when the merge commit can summarize all the work done during the secondary branch [04:10] RenatoSilva: that's what happens when you don't --forget-merges [04:10] jam: intwo swap n a 2400MB vm or something like that [04:10] lifeless: would it be a repack? [04:10] jam: no, single commit [04:11] hmm... something funny then [04:11] sorry, that was a 400MB vm I meant to type, damn hotel latency [04:11] I did quite a bit of testing w/ a 120MB text file [04:11] though that zlib'd very well [04:11] jam: well, I can tell you that one of the biggest reasons that Sun screwed up Java was that they restricted mirroring *specifically* so that they could count downloads. That alone probably cost them the existence of .Net. [04:11] jam: But in Open Source we don't count users because we *cannot*. ~10 distros with significant user bases, all of which have broad mirror networks. Corporate installations with no outside connectivity. [04:11] you know all that of course [04:12] which is why I was *flabbergasted* to see Emma mention that was on your website. [04:12] AfC: we phone home :) [04:12] wait... no we don't [04:13] Hi, new bzr user here (Windows) [04:13] A quick question about .bzrignore, if I may. [04:14] shoot [04:14] aglauser: sure [04:14] I can't seem to work out the syntax for ignoring an entire subdirectory, with out ignoring other directories with the same name [04:14] aglauser: ./path/to/subdir [04:14] needs a '/' [04:14] you can use './foo' to get one at the top level [04:15] bob2: as I said, I'm not reverting. But it seems to me that the only diff is that I lose the secondary revision info. That is, it's just like the diffs introduced by the merge were made directly in trunk [04:15] Does the /**/ glob still work, or was that only older versions? I'm at 2.x [04:15] RenatoSilva: No, you ARE reverting. You're just not reverting the _files_. All you're doing is building up hurt against future merges. [04:15] RenatoSilva: it is unclear to me why you're doing this, but ok [04:15] aglauser: ** should work [04:15] I mean, if you don't want to track merges, you can just use CVS :p [04:16] RenatoSilva: new versions of bzr already hide the merged revisions in log output, if that is your concern [04:16] bob2: and that seems nice to me when e.g. your secondary branch has only one commit or all the changes can be summarized on a single commit comment [04:16] fullermd: huh??? [04:16] RenatoSilva: which is what bzr does already [04:16] RenatoSilva: 'bzr log' on 1.18+ iirc [04:16] fullermd: I'm NOT reverting. I'm writing on IRC. I'm talking about an idea. I'm not even running bzr. So huh? [04:17] Well, I'm not putting 2 level teaspoons of arsenic in my coffee either, but I wouldn't expect people on IRC to tell me it's a good idea if I suggested it :p [04:17] ... well, OK, maybe they would... [04:18] fullermd: tell me who so I can avoid them! [04:18] Thanks, it seems I've got the right pattern now. I think the ./ was the key [04:19] bob2: ok, but I want to know of any other problems IF I use --forget-merges [04:19] RenatoSilva: you lose all the merge metadata [04:19] RenatoSilva: I don't understand why you would do it at all [04:20] RenatoSilva: you lose bzr's record that those revisions are already merged. So it's no better than applying a diff with patch. bzr uses the revision history to calculate merges, so if you forget that data then bzr can't calculate merges as usefully... which means you will get unnecessary conflicts. [04:21] Because the next time you merge that branch, or another branch that does incorporate those revisions, bzr will think it needs to reapply those changes, because it has no record of them being merged. [04:22] bob2: bob2: my main, current reason is that I have branches with a single commmit. When I merge them I think the merge look in qlog is useless. It's a single commit and would be cleaner to have it only in the trunk line, just like I never had used another branch, but committed directly into trunk. The secondary branch was just a sandbox. [04:23] RenatoSilva: You could use "pull" instead of "merge", I suppose. [04:23] So use pull, or even "bzr merge --pull". [04:23] or fix qlog to work like log [04:24] bob2: that would hardly be a fix! [04:24] Actually, qlog already IS collapsed by default... [04:24] Right, there's no reason why qlog couldn't have a heuristic to hide single-revision branches from the mainline by default (I'm surprised it doesn't already). [04:25] spiv: it defaults to hiding everything until you click the twisty [04:25] But if the concern is literally "I want the new revision to be directly on the end of the existing history", then that's what pull is for, so I'd say use that. [04:25] spiv: those conficts only if I try to merge the updated secondary branch again, right? But in my case I'd delete the branch right after merging. But ok, it's the same as diff + patch, which seems easier btw :) [04:25] I happen to disagree with RenatoSilva's analysis that it is "worthless" [04:25] but perhaps.. [04:25] Peng_: I use pull when I can, but sometimes I need merge [04:26] RenatoSilva: I think you should do this if it makes you happy. [04:26] RenatoSilva: understand that *if* you have other people building on the source branch, you will be creating future conflicts when you do this. [04:26] bob2: and the branches with a single commit, well when I change them I tend to uncommit and commit again... [04:26] bob2: Peng_: fullermd: spiv: This is a great example of one of the use cases in my history-edting manfesto [04:27] lifeless: *nod* [04:27] jam: what's worthless? [04:31] lifeless: I'm curious if you saw http://jam-bazaar.blogspot.com/2009/10/refactoring-work-for-review-and-keep.html from today [04:31] its what I did to get the static-tuple stuff up for review [04:31] breaks the changes into diffs post-facto, *and* preserves annotations [04:31] * RenatoSilva gave up of using rebase, ihrc the timeline becomes unordered (the rebased revision is greater in number, but older in date o.O ) [04:32] * RenatoSilva suffers the uncommit syndrome [04:32] * RenatoSilva starts to realize that he just can't fight against the merge fact [04:32] jam: and interestingly they still appear on https://code.edge.launchpad.net/bzr/+activereviews [04:33] spiv: they are on the bzr project, and I requested bzr-core review them [04:33] jam: although it's a shame that the ordering isn't dead-obvious, but it's not hard to discover. [04:33] spiv: yeah, I submitted them "in order" [04:33] so if you go by the "22 hours ago" vs "10 hours ago" you can use that as a guide :) [04:34] also it is sorted correctly in my view, but I see them in the "I am waiting on" section. [04:35] jam: I hadn't no [04:35] not much time to read during sprints [04:35] jam: you also get forward and back links, of a sort, on the individual branch pages. [04:35] spiv: ah sure, because I requested to merge it into the other branch [04:36] it is unfortunate I'll probably have to do the "merged" manually [04:36] jam: "proposal or merging into X", and "N branches proposed for merging into this one" [04:36] but that is worth having small diffs for review [04:36] jam: thats what I want loom to manage [04:37] lifeless: the main thing is doing it at the *end* after I've done all the work in a dogpile [04:37] jam: yes [04:37] especially when exploring, it is hard to figure out what your separations are going to be (at least for me) [04:37] also, it allows avoiding the "spurious merges" between the loom threads [04:38] jam: I'm saying loom should support post hoc separation [04:38] lifeless: sure [04:39] I think the main difference is that loom would probably want to start from the 'upstream' thread, and I was more branching from downstream [04:39] I think 'up' does basically what I was doing with my merges [04:39] jam: I don't see why it would :) [04:40] are plugins written to 1.x fully compatible with bzr 2.0? [04:40] RenatoSilva: depends [04:41] RenatoSilva: many, but I wouldn't say all [04:41] but mostly they can be easily made to work [04:41] if they worked for a recent 1.x [04:43] 1.18 vs 2.0 is "as big" of a difference as 1.17 vs 1.18 [04:43] interestingly enough 2.0 vs 2.1 will be a bigger difference [04:43] but we are changing numbering systems [04:43] jam: iirc I use xmloutput and bzr-email only [04:43] so it is actually 2.0.0 vs 2.1.0 [04:43] jam: will wait a bit more then :) [04:43] RenatoSilva: bzr-email works fine [04:44] xmloutput... I know we bundle it with the windows installer [04:44] so there should be *a* version that just works [04:44] RenatoSilva: move to 2.0.0 as soon as you can ;) [04:44] * igc lunch [04:46] jam: with the windows installer? not in 1.x right? Can't remember of it being listed there [04:47] jam: I submitted some fixes to xmloutput that were merged but not release,d it is still in 0.8.3. So either you have a modified version in 2.0 or the 0.8.3 or trunk has no need to change in 0.8.3 right [04:47] RenatoSilva: I think we started with 2.0 [04:47] RenatoSilva: we packaged "bzr-xmloutput-release = 0.8.5" [04:47] not sure what makes you say it is still at 0.8.3, but there is a tag in the branch @ 0.8.5 [04:48] jam: you're from canonical right? it would be nice if you release your private, improved version of bzr-email. The one currently there is a bit simple [04:48] RenatoSilva: I don't know of a "private, improved version" [04:48] I use the stock version from "bzr branch lp:bzr-email" [04:48] jam: release 0.8.5???? let me check that, I thought I was subscribed to the branch.... [04:48] but yes, I' min canonical [04:49] jam: e.g. public bzr-email does not have html, and does not allow customization of body/subject, and does not work for me without a patch [04:50] RenatoSilva: I thought I saw something about html being mentioned on the mailing list, but I've never used it or seen it [04:50] RenatoSilva: "doesn't work for you" ? [04:50] have you proposed the patch? [04:50] jam: the emails sent by LP when you change branches are done by something similar to bzr-email, but not released to the public [04:51] RenatoSilva: LP's code is public [04:51] RenatoSilva: its not a bzr plugin though [04:51] jam: something about TLS [04:51] RenatoSilva: grab the latest from the bzr-email branch [04:51] I'm pretty sure that is fixed [04:51] may not be in a tarball, etc [04:51] though it is packaged for Karmic ( I checked with james_w just a couple weeks ago) [04:52] jam: this is the patch to make it work: https://code.launchpad.net/~renatosilva/bzr-email/ignore-tls [04:53] jam: I don't know if you mean what's done here [04:54] http://bazaar.launchpad.net/~renatosilva/bzr-email/ignore-tls/revision/40 [04:54] though you build on top of that, so obviously something is different in your situation [04:59] jam: see bug https://bugs.launchpad.net/bzr-email/+bug/388723 [04:59] Launchpad bug 388723 in bzr-email "SSL error on starttls()" [Undecided,New] [05:01] jam: it's a hand shake error, maybe and likely server problem, but I thought it would be nice to allow users not being affected by such broken servers [05:01] jam: so I created the disabling option, it's working fine with me now. [05:13] latest version of bzr-xmloutput is 0.8.4, from where did you get 0.8.5 to pack together with 2.0? [05:13] https://launchpad.net/bzr-xmloutput [05:19] poolie: gnight; we can try to hook up sunday avo or something [05:19] poolie: or perhaps my morning (7hr from now) [05:28] lifeless: you're not in AUS/NZ? [05:42] ok [05:42] thanks all [05:43] wow nice work igc [05:43] you should send that to the bazaar list too [05:53] poolie: which bit? [05:53] the benchmarks and the mail about them [05:54] ok [05:54] if you want to [05:54] hi spiv [05:55] poolie: good afternoon [05:55] how's stuff? what are you up to? [05:56] I'm reading through jam's patch flood. [05:56] I'm greatly looking forward to cutting our memory consumption! [05:57] spiv: me too! I was hoping you'd choose to review those patches (with your Python internals knowledge) [05:58] Also used -Drelock to squash a simple (and probably not very wasteful in practice) relock in cmd_missing, mainly to see what it feels like. I'm going to leave -Drelock on in my bazaar.conf for a while and see if that encourages me to squash some easy bugs. [05:58] It's a bit depressing that almost every command trips it, though. [05:59] I'm particularly wondering about extending the -Drelock thing to allow writing test assertions about it. [06:00] I don't know that we really want to explicitly add "assertNoRelockingHappened" or whatever to lots of individual tests, but it would be nice to find and easy-yet-firm way to drive it towards zero instances. [06:01] But maybe blackbox tests could test for that by default, and then individual tests or test cases could opt out? [06:03] Oh, and I spent some time (re)reading the summary of the London meeting. [06:21] lifeless: no. [06:22] the one where it took 11 minutes to commit the large files into the bzr repo. [06:22] also most 4 times longer than the time to copy the files. [06:23] however, i am tempted to go and have a look at the code, and submit a patch for where a file is sufficiently large to store and make comparisons against a sha1 or similar hash of the file. [06:23] spiv, could you review jam's cix patch, if you didn't alread? [06:24] that obviously will require other changes to ensure that the binary files are kept avilable for the various locations in the repository (if one changes the others shouldn't etc.). [06:24] d1b, you're committing a rename of a large file? [06:24] poolie: it was a worst case senario i ran bzr 2 against, 5 167mb video files. [06:25] the files were identical [06:25] under different names? [06:25] poolie: yes. [06:25] k [06:26] probably best to start by profiling it and looking at the developer docs on profiling [06:26] poolie: lifeless already has a kcachegrind / valgrind dump thingy. [06:27] poolie: a workaround would be to not try to group-compress large binary files. [06:36] poolie: ok [06:38] cool [06:51] spiv: what's .bzr/upload for? any ideas? why would there be a xxxxxx.reconcile file in there? [06:52] poolie: ^^^ [06:58] igc: do you mean .bzr/repository/upload ? [06:59] igc: it's where pack files are created initially. Once all the content has been added and the pack file finished, then they are moved from upload/ to packs/ and then added to pack-names. [07:00] igc: similarly indices. [07:00] spiv: thanks [07:00] igc: the name they are given in upload/ has a suffix that varies depending on which code path created it. *.reconcile is made by the ReconcilePacker (or the GC variant, etc) [07:01] spiv: right. so a crash of reconcile leaves a xxx.reconcile file there. It makes sense now [07:01] igc: which is a long-winded way of saying "you probably hit ^C or similar during a 'bzr reconcile' at some time :)" [07:01] spiv: nah, reconcile is falling over for keybuk [07:01] Ah, right. [07:02] Yes, that'd do it. [07:02] i can reproduce it [07:03] lifeless: i am going to kick you later for being too smart a nerd. [07:05] lifeless: ok so skipping the nistallation bit... how do I actually use the bzr-hg tool. commands, syntax on bzr branch, whatever?? [07:21] hi all [07:44] bbiab [08:00] nice post there [08:00] arjenAU: basically you can just urls to hg repositories [08:00] there are no new commands [08:14] poolie: ok so back one step. how do I install the sucker [08:14] poolie: all these plugins are lacking in docs. I'm not a python person [08:14] are you on ubuntu? [08:14] i think it's in the ppa? [08:15] hmm didn't show up in synaptic. I am on the PPA [08:15] no, it's not [08:15] I grabbed the tarball and did python thingie build and then install. no worky [08:15] hello all [08:15] igc: what is scary numbers for Samba import? [08:16] bialix, this one i think: https://launchpadlibrarian.net/21176883/gwibber.64x64.png [08:16] blah [08:16] http://bazaar-vcs.org/Benchmarks [08:16] yes, benchmarks [08:16] and why Firefox trunk bigger than import? [08:16] questions, questions... [08:16] different packing maybe? [08:17] or trunk is branch + tree? [08:17] and import is treeless? [08:17] somebody should explain [08:18] really guys [08:18] well, reply to ian and ask [08:19] if it's even for me wtf -- then you can expect many gibes from outside [08:19] there is a page of details but it doesn't say what trunk only is [08:19] * poolie burned out [08:19] good night [08:19] night [08:27] Why does the bzr home page now say "rockin'" and give a nonsensical user count? [08:29] where? [08:30] Near the bottom, just above the anonymous logos. [08:30] ah see [08:30] I recognise them, but I imagine most will not... [08:31] * bialix don't know what is purple cog icon means [08:31] * bialix as well as globe [08:32] I dunno, emmajane and igc constantly improving this page [08:32] there is branch with page source [08:35] The purple thing is GNOME Do, the globe is Gwibber. [08:35] clearly Gnome/Ubuntu centric point of view [08:36] * bialix goes away for my work on windows xp [08:36] :-P [08:38] bialix: do you know of any Windows software projects using bzr? if so, suggest they be added. [08:43] hi bialix [08:44] bialix: I just run the commands. Exactly what pack does under the covers is outside my depth of knowledge [08:45] bialix: but fast-import imports a whole repository while 'branch' just grabs the revisions referenced by trunk [08:45] mneptok: it should be a BIG project right? no I don't know [08:46] bialix: not necessarily. but something at least noteworthy. [08:46] igc: I suppose Bazaar Import size is the size of treeless shared repo? and trunk is the sizer branch with tree? [08:46] mneptok: oh, I know many. QBzr per example. It will count? [08:47] PhotoBatch, Leo editor [08:47] there is page with links to these projects [08:47] bialix: ask emmajane or igc :) [08:47] bialix: import size is just repo size - see "how we measured" link [08:48] du -sh? [08:48] bialix: branch size is still just the .bzr size - there's no point comparing the working tree as it's the same across each tool [08:48] that's nice that I know what du is [08:48] but this is not windows utility [08:49] h=human readable [08:49] s=summary (don't show each subdirectory) [08:49] will be much simpler if you just wrote in plain english [08:50] the plain english bit is the directories being compared :-) [08:50] mneptok: http://bazaar-vcs.org/WhoUsesBzr [08:51] igc: then I'm bad in english today. Sorry and nm [08:55] bzr qlog is amazing, but its revision sorting algorithm is a bit suboptimal. It seems to optimize keeping the trunk revisions consecutively displayed, at the cost of vastly increasing the horizontal space used for the graph [08:56] maxb: this is because in bzr mainline is special [08:57] igc: also I think 36K windows downloads is extreme. [08:57] igc: for most releases this number is order of magnitude smaller [08:57] I dunno why 1.13.1 so big, but it seems pretty wrong for me [08:57] Attempting to put correct numbers there is an exercise in foolishness. [08:58] I agree [08:58] I dunno why there is need numbers [08:58] foolishness is good word [08:58] * wgrant should probably check the list for similar complaints. [08:59] recent thread is 42,000 too much [09:02] Hello [09:02] I've a big problem [09:02] I cannot create repository on my http server anymore [09:02] I receive : [09:02] bzr: ERROR: Server sent an unexpected error: ('error', "An attempt to access a url outside the server jail was made: 'chroot-3102421996:///'.") [09:07] bialix: would your company be interested in putting your logo on our home page? [09:11] ploum: there's a bug about that, with a workaround: [09:11] ploum: https://bugs.edge.launchpad.net/bzr/+bug/348308 and the workaround is in comment #8 [09:11] Launchpad bug 348308 in bzr "Smart server jail breaks bzr+http with shared repos" [High,Triaged] [09:12] funny, I was already subscribed to this bug but it was so old [09:12] thanks for the info [09:15] igc: unlikely :-) [09:15] we are very small company working in narrow niche [09:16] bialix: we're happy to promote companies and projects using Bazaar there [09:16] bialix: but QBzr is probably too close to Bazaar itself sorry [09:17] bialix: i.e. users won't see it as a separate project to Bazaar [09:17] bialix: by user, I mean typical home page visitor [09:21] igc> bialix: but QBzr is probably too close to Bazaar itself sorry -- I know, it was joke [09:21] igc: for my company the problem is we made embedded systems not software per se [09:21] so we have hardware which you can take in hands [09:22] software is just companion [09:22] bialix: ah - ok [09:24] night all - have a good weekend [09:24] bye [09:26] igc: g'night [09:27] night spiv === JaredWigmore is now known as JaredW [10:34] can anybody help me understand the difference between bzr checkout svn+ssh://foo.com/foo vs bzr svn-import svn+ssh:///foo.com/foo? [10:35] the main reason for my question is that I've tried the former approach twice on a history-rich svn repo and I've gotten failures both times, so I'm considering trying the other approach. [10:36] but I don't understand the example at on using svn-import [10:42] hi all [10:42] hi [10:42] faldridge: can you tried to simply `bzr branch svn+ssh://foo.com/foo`? [10:43] faldridge: the main author of bzr-svn is jelmer [10:43] faldridge: always when I need a copy of svn repo of upstream I'm just running bzr branch [10:44] bialix: I have not tried that; it wasn't listed on the bzr-svn plugin doc. What does that do differently than bzr checkout? [10:44] bzr branch will create bzr mirror of svn repo [10:44] I think it's similar to svn-import [10:45] what is the product of bzr checkout I really don;t know [10:45] can you show me the output of bzr info -v in the your checkout? [10:45]