=== sdboyer is now known as crapstain === crapstain is now known as sdboyer [01:17] hey guys.. i tried to branch off a repo on one of my web servers, bzr+ssh it got to 124MB, still says 1171KB/s but it's stuck, for about the last 15 minutes. [01:18] there's only 10 MB left in the repo i believe [01:18] is there anything i can do to cancel and recover the branch operation? [01:24] NET||abuse: unfortunately bzr can't yet resume interrupted fetches [01:25] NET||abuse: strange that it got stuck, though [01:25] yeh, been waiting a while. [01:25] still stuck :( [01:25] crap.. it's a big fetch, 135 MB [01:26] I don't suppose there's any errors in ~/.bzr.log on the server? [01:26] right, i could look. [01:27] yep, error [01:27] If you do need to restart, perhaps try "bzr branch -r 500 ...", then "bzr pull -r 1000", "bzr pull -r 1500", etc to do it in stages. [01:27] Could you pastebin it? [01:27] File "/usr/lib/python2.4/site-packages/bzrlib/osutils.py", line 1810, in until_no_eintr return f(*a, **kw) IOError: [Errno 32] Broken pipe [01:29] How strange. Could you paste the full traceback in http://pastebin.com/ ? [01:29] But that snippet implies that the connection was lost, at least as far as the server is concerned. [01:41] jelmer: ping [01:52] arrg. [01:52] timeout? [01:53] NET||abuse: yes, you dropped of IRC due to a timeout [01:53] NET||abuse: which I suppose is consistent with the bzr stream failing due to a network drop out... [01:53] oh well.. [01:53] :) maybe my net connection is dorky [01:53] NET||abuse: so I'd grab the branch in smaller chunks [01:53] jfroy|work, hi [01:53] * spiv -> lunch [01:53] well, any ideas from my pastbin. [01:54] smaller chunks? how do i do that? [01:54] jelmer: I have a rather serious problem [01:54] NET||abuse: didn't get your pastebin URL [01:54] ahhhh [01:54] < spiv> If you do need to restart, perhaps try "bzr branch -r 500 ...", then "bzr pull -r 1000", "bzr pull -r 1500", etc to do it in stages. [01:54] http://pastebin.com/m64de9e31 [01:54] jelmer: there was some... evil messing around with our subversion repository [01:54] i posted when seemingly my irc had dropped, there was no indication for a while. [01:54] NET||abuse: also, if your branch isn't in 2a format yet, consider upgrading, it'll be smaller. [01:55] jml: now would be good, if you've lunched [01:55] I described what was done in https://bugs.launchpad.net/subvertpy/+bug/497280 [01:55] Ubuntu bug 497280 in subvertpy "Assertion hit when pushing merge commit to remote svn repository in parse_mergeinfo_property" [Undecided,New] [01:55] it is 2a already [01:55] NET||abuse: ok [01:55] now, beyond that kink, which I worked around, I thought everything was fine. [01:55] NET||abuse: hmm, that doesn't look like the whole traceback, just 3 frames, but I think given that you're having network issues it's safe to assume it's not bzr's fault. [01:55] But, a co-worker just committed a revision to our trunk (nested inside our project directory in our new repository) [01:56] and bzr won't pull the changes introduced by that revision [01:56] NET||abuse: thanks for pasting that though [01:56] * spiv -> really lunch this time [01:56] worse, it allowed me to push 2 new revisions after that revision without any complaint -- normally, it should have stopped, telling me the branches had diverged [01:57] if you have a bit of time, I'd like to try to figure out what the heck is going on [01:58] jfroy|work, did your two revisions merge any of his changes? [01:58] no [01:58] they were completely unrelated sets of changes [01:58] well, at least I didn't intentionally do a merge [01:59] can you check if those revisions have any other parents? [01:59] well, there's nothing i can do other than try fetch again. [01:59] you didn't push with --overwrite or anything like that? [01:59] but, if you read the bug I filed on subvertpy, it's possible bzr-svn is getting confused by merge properties or even bzr-svn properties that are completely bogus [01:59] nope, I did a commit from a bound branch [02:00] or, I should say, properties that have been made bogus [02:00] and OK, I do I check for parents? [02:02] jfroy|work, bzr log --show-ids should tell you [02:03] the subversion revision in question does not appear in the log [02:04] yep, it's as if it was being skipped entirely [02:04] the revision that should have the missing revision as its parent instead points to the one before [02:09] jfroy|work, that's correct, as that's the order in which you committed them locally [02:10] well yes, but there's a whole in there [02:10] so I wonder why it didn't complain about diverged branches - you're sure you didn't push with --overwrite? [02:10] pretty sure... [02:11] unless something can turn that option on... [02:11] it wasn't even a push, it was a commit in a bound branch [02:16] jfroy|work: might be a bug in the commit code in bzr-svn in that case, can you file a bug? [02:16] jfroy|work, I've responded to the other bug report in subvertpy, which is probably unrelated [02:16] sure, although I'm not sure I can provide much more information than I have. [02:16] Yes, it's probably unrelated [02:17] Also, is there a way I can fix the situation? [02:17] you can cherrypick the changes from the missing revision [02:17] Apply a diff manually between a svn checkout and a bzr checkout and push --overwrite, at least to pick up the missing changes> [02:17] commit those and then push them [02:17] *? [02:18] I need to get some sleep, let's move this discussion to the bug report [02:18] sorry [02:18] OK [02:18] no worries at all [02:18] I appreciate you taking some time at all. [03:57] * mwhudson randomly wonders how long away realistically being able to disable vfs operations on the smart server is [04:05] mwhudson: ages, probably, given that it doesn't seem particularly relevant to udd goals [04:06] spiv: yeah, fair enough [04:06] ronny: hi, I'm back [04:07] spiv: if it was a priority, do you have a sense how long it would take? [04:07] / how much work it would be? [04:07] mwhudson: I think you're asking the wrong question :) [04:08] lifeless: i find it hard to believe you know why i'm asking [04:08] mwhudson: I think the question you want to ask is 'how many operations do people do, that need the VFS today, which we would have to support to be willing to disable the VFS' [04:08] mwhudson: I've got no idea why you are asking [04:08] but we can disable the VFS today, just at high impact. [04:09] lifeless: yes, ok, that's a more answerable question [04:09] mwhudson: also you have a question in /msg [04:10] mwhudson: one implication of framing the question about VFS as I have, is that you can clearly see that lp might reach a different answer than (say) savannah [04:11] yeah [04:12] or, more importantly, than core. [04:12] One useful thing would be to get a % use of VFS today. [04:12] I suspect its 60-70% [04:12] (connections which invoke vfs at all), not % of operations on a connection. [04:30] yeah, i guess we could measure it [04:31] though it's probably not so interesting, i mean i would guess 90% of connections just do a fetch in one direction or the other [04:31] so if we want to push for vfs free lp [04:31] then we should measure it [04:31] if we basically do-not-care [04:32] then its all moot :P [04:32] i guess it's in the do-not-really-care bucket for now, as spiv says [04:33] mwhudson: if you do start to really care, I'm sure you'll let us know :) [04:35] :-) [04:47] Isn't there a bzr command that will show me pending merges? I'd like to confirm it before I commit and I'm having a temporary brain-freeze. [04:48] status? or am i missing the point? [04:49] 'arvo, btw. [04:49] Hey! [04:49] :) [04:49] st just shows me modified files. Perhaps because they were all conflicted. [04:49] Well, all bar one. [04:50] Then you have no pending merges. [04:50] Hello, what are valid bzr URLs (other than lp:// & bzr+ssh://) ? [04:50] Unless you've done "bzr alias st='status --no-pending'" ;) [04:51] AnAnt: bzr help urlspec [04:51] thanks [04:51] spiv: I ran bzr merge, resolved the bunch of conflicts, but I'd expect it to still say there is a pending merge [04:51] (which will include url schemes supported by plugins, if any) [04:52] StevenK: you probably did a cherrypick then [04:52] spiv: Yeah, it was only one revision [04:52] Right. [04:52] spiv: That isn't a real merge per-se? [04:52] Well, it's real, but bzr can't record it :) [04:52] bzr represents merges as extra parents for the revision. [04:54] So it has no way to record "X was merged but not X-1" [04:55] It's simply "X was merged [and so implicitly all of its ancestors too]", or nothing. [04:55] We'd like to support that better, but it hasn't quite made it to the top of our todo list. [04:58] poolie: I wonder if you could mail me your APN details from your magic [04:58] is there a way to check wether a bzr URL is valid or not ? [04:58] AnAnt: valid for what purpose? [04:59] lifeless: what is an apn? [05:00] spiv: ie. the URL is not wrong, for example, if I do bzr branch lp:foo/boo/zoo I would get this error: "bzr: ERROR: Invalid url supplied to transport: "lp:boo/foo/doo": No such project: boo" [05:00] I want to check if the URL is valid or not without actually doing a bzr branch [05:00] poolie: access point name [05:00] poolie: ~= to essid [05:01] I don't see a dry-run option for bzr branch [05:01] AnAnt: Well, if you want to check if there's a branch there without branching, you can do "bzr info URL" or even just "bzr revno", for example. [05:01] thanks [05:03] poolie: settings -> wireless -> mobile networks, there should be a list of apns there, I'd like the settings for the one that you're using, which will be what vodafone shipped [05:04] ok [05:04] on phone now [05:04] no rush [05:04] I'm trying to set up tethering to my phone [05:12] spiv: thanks again, that helped me to fix something in git-bzr [05:13] AnAnt: you're welcome === abentley1 is now known as abentley [07:05] hi all [07:37] oh right. [07:37] I'm still trying to land this branch. [07:50] hi vila [07:50] and good night [07:50] and send a pp report :) [07:50] :) [07:51] i booked trains btw, the details are on the wiki [07:51] it was quite cheap [07:51] have a good day and a good trip [07:51] poolie: thanks and thanks for updating the patch pilot page ! [08:10] vila, can you please help me land this patch? [08:11] I get the error: merge http://bazaar.launchpad.net/~jml/bzr/lp-login-oauth-2 http://bazaar-vcs.org/bzr/bzr.dev [08:11] Command failed! [08:11] All lines of log output:Sender not authorised to commit to branch http://bazaar-vcs.org/bzr/bzr.dev [08:11] jml: Try the new http://bazaar.lp URL. [08:12] jml: one sec, but I think trying Peng suggestion is worth it [08:12] Peng: which one is that? [08:12] http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev or lp:bzr :) [08:13] * jml tries lp:bzr first [08:16] vila, what do you have in your locations.conf? [08:16] * vila was well known for hanging pqm with lp urls :) [08:17] jml: I use branch.conf: http://paste.ubuntu.com/343725/ [08:18] relevant part: http://paste.ubuntu.com/343726/ [08:18] vila, that seems to be a bit better. [08:19] jml: the change dated back to the switch from bazaar-vcs.org to lp for hosting bzr.dev [08:19] s/for hosting/to host/ ? [08:19] the first one is correct. [08:20] vila, I see that HACKING.txt hasn't been updated then. [08:21] yes, lifeless mentioned it yesterday too, you may have missed that [08:23] ahh, I did miss that. [09:37] vila: I sent my contributor agreement through months ago. CCd poolie. Where is the best place to resend it? [09:38] johnf1: Just comment in the merge proposal, poolie will be the patch pilot next week so he will sort that out [09:39] johnf1: sorry about that :-/ [09:39] no problems [09:42] Good morning! [09:42] I've released trac-bzr 0.3.0 today. Due to lack of testing, I've got to consider it of beta quality, so I'll be happy for all of you who use Trac to give it as much testing as possible. [09:54] hey guys.. i want to inspect older revisoins of one particular file, how can i do this easily? [09:54] NET||abuse: bzr cat, I'd say [09:54] hmm, ok [09:58] NET||abuse: you might find the bzr-gtk or qbzr plugins handy, they give you commands like glog/qlog that let you explore history with a GUI. [09:59] not a bad idea i suppose. [10:00] any preference between qbzr or gtk? [10:02] NET||abuse: qbzr is probably a little more polished at this point [10:03] just tried to install... [10:03] no applications->programming item, no obvious terminal line command to run [10:22] NET||abuse: try bzr help plugins/qbzr [10:22] then you most probably try 'bzr qlog' or 'bzr qblame FILE' [10:23] that seems to do it. [10:23] err, qannotate (qblame is an alias so it doesn't appear in that help) [10:43] what does the qannotate doe exactly? [10:44] the qlog was great, i got to view the tree from the old revision... was able to open the file in question, i had a UTF-8/Latin10 character encoding problem. litereally the files own encoding type. [10:54] vila: What time zone are you in? [10:54] CET [10:54] i.e. I will go to lunch soon :) [10:55] Oh, fun. [10:57] Hehe, I'm in -0500; it's 05:57 here right now. If only I had a sleep schedule... [10:58] Peng: Really ? Where are you ? [10:59] that's just east coast US [11:00] Yep. [11:01] could have been canada or south america :) [11:02] I'm in Florida, to be a bit more specific. [11:03] * vila feeds the satellite Laser [11:04] I think my LP map location is set semi-accurately. [11:05] So as long as the laser can take out an area, say, 30 miles wide, I think it will work. [11:06] * vila tries [11:06] oops [11:06] Peng: your timezone says UTC though [11:07] vila: I like using UTC. [11:07] Peng: doesn't really help in that for visitors trying to reach you :-D [11:08] * vila add 'case' [11:08] vila: Well, my usual sleep schedule is more like Australia anyway. [11:09] good, use that :) [11:09] But I like UTC. No Daylight Saving Time. [11:10] Hmm, using an Australian time zone is a completely insane idea that sounds totally fun. [11:11] Peng: yes, that's fine, I'm talking about your lp page, where I don't think *you* care much about what is displayed there, but *others* may. But that's your page in the end :) [11:11] vila: Ah. Does that setting influence times displayed on LP, though? [11:12] You'll tell me :) [11:16] why does bzr have >700KB of data transferred to do a 2 line commit? :/ Could this be a continuation of the issues I was asking about earlier in the week? [11:17] i shoul work out who i was talking before *checks logs* === jelmer_ is now known as jelmer [11:18] ah, vila . [11:18] * vila search logs too [11:19] What is your remote server and what protocol do you use ? [11:19] i should probably grill the savannah admins before i ask here more, i know they have issues at their end. [11:20] Ha ! savannah, sftp [11:21] vila: I added a note to my LP page. :) [11:21] So you may be doing a repack which requires downloading/uploading more than strictly the 2 lines commit [11:22] from your reaction i take it sftp is not the fastest way to transfer data :) [11:22] i note my other checkout pulls over http and pushes on sftp - strange but true. [11:22] Kamping_Kaiser: .bzr.log should give hints [11:22] Kamping_Kaiser: well, the smart server is supposed to be really smarter than the dumb servers [11:22] Savannah runs such an old version of bzr that you're better off avoiding their smart server, if they have one. [11:23] In particular it knows how to repack locally (or remotely, well, locally from its pov) [11:23] Peng: I don't think so, I'm pretty sure they use a backported 2.0.3 [11:23] vila: Oh, they do now? Thank goodness. [11:23] But they don't have allow the use of it, Kamping_Kaiser ? Can you confirm that ? [11:23] vila: I had heard that they were going to stick with Debian Stable, which is 1.5 or something. [11:24] * Peng shrugs. [11:24] vila: can't confirm what savannah runs sorry. [11:24] Peng: backports [11:24] Peng: The change occurred recently (if it has), one or 2 weeks [11:24] Peng: see the long thread on same [11:24] I've successfully avoided becoming responsable for savannah in any form *g* [11:25] Yeah, I stopped paying attention to that thread. :P [11:25] That's great to hear, though. Go Savannah! : [11:25] :) [11:25] Kamping_Kaiser: I like the etymology of responsible: the one who can respond for :) [11:26] vila: hehe. the problem is, I tend to involve myself in projects deeper then i need ;) (I'm still a bzr _user_ thank goodness) [11:27] I think spiv and/or jam hacked a ping plugin that could help here but I don't remember the details... [11:27] bzr log tells me 21.366 fetch up to rev {karl@kgoetz.id.au-20091218111320-8qya0xqtb74qzrfn}, so i'll guess thats the problem on that data transfering [11:28] Kamping_Kaiser: context ? More than 1 commit ? [11:28] vila: i'll pastebin the log stanzas, just a tick [11:29] http://paste.debian.net/54352/ [11:29] vila: lp:bzr-ping, usage simply 'bzr ping URL', it will report the smart server version at that URL [11:30] (or at least which version of bzr the smart server claims to be) [11:30] spiv: \o/ [11:32] Kamping_Kaiser: that doesn't tell me if there was more than 1 rev to push :-/ [11:33] But that strongly remains me that we have a pending patch that give that kind of info for pull (at least the revno/revid *before* the pull), it would be nice to do the same for push [11:33] vila: afaik it was just one revision [11:34] * vila breathes again, subunit/testtools/bzr working happily together again to provide --parallel=fork [11:34] interesting... bzr.log confirms 2009-11-22 was the last submission CIA got from me. i should track that problem down [11:34] sorry. getting distracted by my new data source :p [11:34] Kamping_Kaiser: no simple explanation comes to mind then :-/ Do you observe that for every push ? [11:35] vila: the last half a dozen at least (they're the ones i remember). [11:36] vila: I suspect something in a newer version of bzr isn't playing happily with something in my install. cia disapeared enf of last month, and this slowlness issue, its definitely only been a month or so [11:37] what bzr version are you using ? [11:37] 2.0.2-1~bpo50+1 [11:39] where did you get that ? [11:40] http://www.backports.org (directly from them, or via roberts backports repo) === johnf1 is now known as johnf [11:41] ok, so that's an official 2.0.2 right ? [11:42] haaa bpo == backports ? [11:42] yup [11:42] k, excuse my English I'm French :) (And sorry for my president too :-/) [11:43] no worries. [11:43] i'll match and raise your president with my communications minister [11:45] Kamping_Kaiser: where are you from ? [11:46] vila: Australia. http://www.abc.net.au/news/stories/2009/12/15/2772467.htm [11:46] Kamping_Kaiser: bug #465517 may be a candidate, but I doubt it [11:46] Launchpad bug 465517 in bzr "'bzr push' copies the entire repository if there is a BzrDir but not a Branch" [High,In progress] https://launchpad.net/bugs/465517 [11:47] Kamping_Kaiser: Oh my, you too have internet censors for you own godd ^^ [11:47] not the same - whole repo isn't copied, but could be related (as is the way with software) [11:47] vila: I feel safer already ;O [11:48] Kamping_Kaiser: you repo is big ? [11:48] Kamping_Kaiser: your repo is big ? [11:48] Kamping_Kaiser: do you an url where I can branch from ? [11:49] vila: 88 mb. hang on for the uri [11:49] bzr branch http://bzr.savannah.nongnu.org/r/gnewsense/builder should do the job (I assume you don't have a savannah login :)) [11:50] Kamping_Kaiser: Oh I should have one.... but where :D [11:50] hehehe [11:51] https://savannah.nongnu.org/bzr/?group=gnewsense ftr, but i doubt you'll need it [11:55] Kamping_Kaiser: ok, so the repository is currrently quite fragmented 32 packs in http://bzr.savannah.gnu.org/r/gnewsense/.bzr/repository/packs/ so we may need to access the corresponding indices which in turn should not be quite good for you if you have high latency to savannah [11:56] what is your ping time there ? [11:56] vila: 324ms [11:56] again, the smart server can help a lot here since all the indices are local from its pov [11:58] so if you can afford to issue 'bzr pack :push' and try a new push after that you may get far better results [11:58] vila: will all checkouts be this fragmented, or just mine? [11:59] the fragmentation is natural but... geee, I wish I had an url for that explanation... [11:59] every 10 commits a bigger pack file is created, every 100 an even bigger with the 10 bigs, etc [12:00] http://bzr.savannah.gnu.org/r/gnewsense/.bzr/repository/packs/?C=S;O=A [12:00] hm, ok. so is this an 'email everyone suggesting they repack' moment, or a 'oh good, something new learned'? from what you say i assume only people with a reasonable number of commits will be affected to start with [12:01] I suspect the high latency is really the most proeminent problem here and only the smart server can address that [12:02] bzr pack *should not* be needed under normal circumstances, I'm asking here to see if it changes the behaviour you're seeing *right* now [12:02] If you look at the last url I pasted you can see that your last commit is really small, so bzr didn't upload a lot, I'm trying to roughly evaluate if the time can be due to a lot of downloads instead, hence the proposal [12:03] ok. its repacked, and pushing. :) [12:04] But that url is weird too because it seems to show a weird distribution of sizes... [12:04] Still the same, are you sure you packed the remote one and not the local one ? [12:05] incase its relevant, the original repo was svn, it got bzr-svned, then commited to, then upgraded to some format, then commited to, then upgraded again, and commited to again [12:05] vila: its still uploading. [12:05] [########/ ] 7920KB 1KB/s | repacking chk:chk node 9760/47924 [12:05] repacking, here we go [12:07] right, so that may explain the weird distribution, can you put dates on the events above that we can relate the pack dates ? [12:08] should be able to, it'll involve some logs diving though, so could take a min === mrevell is now known as mrevell-lunch [12:11] Kamping_Kaiser: looking at http://bzr.savannah.gnu.org/r/gnewsense/.bzr/repository/upload/ progress, I think I can leave you there and be back after lunch [12:11] hehe. most likely. i'm going nowhere. [12:12] Kamping_Kaiser: I'll be back in ~< 1h [12:12] enjoy lunch :) [12:12] no no, already 6.6M uploaded, don't stop it ! [12:12] 26000KB to upload 6.6mb. ah well. repacking ftw ;) [12:12] wow, huger spike suddenly 11M.... [12:13] no, your repo is far bugger than 6M ! [12:13] more like 65M roughly [12:13] s/bugger/bigger/ damn keyboard === vila is now known as vila-lunch [12:14] nm. i'll dig those logs, see you later. [12:18] MvG: ping [12:18] bialix: pong [12:18] congrat on new trac-bzr release [12:18] have a question [12:19] does trunk supposed to be used only with trac 0.11? or? [12:19] MvG: ^ [12:20] bialix: No, so far trunk and trac-0.10 are equal. [12:20] oh, that's great [12:20] I just want to give devs the option to track trac-0.10 and be ensured that their setups won't break. [12:20] And I had supposed I'd break compatibility before releasing 0.3.0, but it turns out there was no pressing need to yet. [12:21] * MvG is AFK for a minute. [12:21] thanks for the info [12:22] MvG: did you send announcement to bazaar-announce or main bzr ML? [12:23] when you'll have a chance, please do :-) [12:26] Oh, thanks for the reminder, will try to do so if I find the time... [12:27] bialix: btw: caching scheduled as main goal for 0.4: https://blueprints.launchpad.net/trac-bzr/+spec/caching [12:27] \o/ [12:27] * MvG is AFK for a while longer now. [12:31] vila-lunch: this should give you some idea. http://paste.debian.net/54356/ not brilliantly accurate, hope its enough (all times GMT+9.5 or +10.5) === mrevell-lunch is now known as mrevell [13:09] Hello! I'm using sftp to upload changes to my main repos, it says I'm uploading using 1KB/s. At the same time, I can upload files using sftp at several MB/s. Why is Bazaar so slow? [13:10] Right now bazaar is about 100-200 times slower than svn [13:10] (for checking in and updating) [13:11] Coke: hm... hang around. i have the same slow sftp upload issue. === vila-lunch is now known as vila [13:11] someone was helping me. perhaps he'll come back from .... [13:11] lunch ;O [13:11] Kamping_Kaiser: wow, the restaurant was crowded... [13:11] but still < 1h :-D [13:11] Kamping_Kaiser: I've had this problem forever [13:11] ;D [13:12] Coke: i haven't had it that long - its only existed in my lifetime for example :D [13:12] Coke: What `bzr version`, what repository format `bzr info` ? [13:12] 2.0.1 [13:12] pack-0.92 [13:12] Kamping_Kaiser: looks like your repo is packed now [13:13] Coke: upgrading to 2a should make a significant difference, using a smart server (bzr+ssh: instead of sftp:) even more [13:13] vila: yes, it is. i pasted you a pastebin link giving some rough info you asked about [13:13] vila: I'm not interrested in changing the setup [13:13] If anything I'll just revert to svn [13:13] or upgrade bzr [13:14] Why is it so slow? [13:15] socket.write(data, 1024); sleep(1000) ??? [13:15] Coke: Good catch, patches welcome ! [13:15] vila: I'm not really sure how you can get down to 1KB/s without doing above code [13:16] Coke: If you don't want to use the smart server you can still upgrade your repository to the 2a format [13:16] sftp is pretty smart [13:18] Kamping_Kaiser: did you solve it by upgrading? [13:19] Kamping_Kaiser: Nothing suspicious in your log, bzr upgrade --2a should end with an automatic repack so the distribution I oberved before has no good explanation. Is that repository shared with other branches or projects where some commits may have resulted in pack files in the 10MB range ? [13:19] Kamping_Kaiser: more importantly what happens *now* if you push ? [13:20] vila: shared at the server end? I think so. (I didn't set it up). I doubt theres been any 10mb commits to it, but I can't say i've kept very close tabs on it. [13:21] Coke: sftp is not "smart" enough because it just provides us with a remote file system, when bzr wants to merge several pack files into a bigger one, it sill has to download the pack files and then upload the resulting one [13:22] vila: ok, I'll be honest, I dont understand how the protocol works [13:22] vila: but here's what I do know; only bazaar manage to turn my 24MB line into a 9k modem speed [13:22] Coke: The "smart" server can do that locally and don't have to use any bandwith for that [13:22] vila: sftp in itself does not [13:22] vila: but I have 24MB! [13:22] I shouldn't have to worry about bandwidth [13:22] Coke: what is your latency ? [13:23] around 30ms [13:23] Are your repositories/branches used shared with others ? [13:23] no [13:23] and it doesnt matter [13:24] 1KB/s is just not acceptable after the introduction of 56k modems [13:24] vila: its still "fetching revisions: inserting stream". is this a function of sftp? :/ [13:24] vila: it seems to be faster though, for the small commit i made to test [13:24] Kamping_Kaiser: the message is expected [13:24] I get that too [13:25] Coke: expected too [13:25] is regular ssh+bzr faster? === bialix_ is now known as bialix [13:26] vila: ok. so it has to download anyhow, i assume its related to what you just told Coke about the sftp issue :) [13:26] Coke: bzr+ssh is almost always faster than sftp these days (at worst it should be as fast (or slow :)) [13:26] Kamping_Kaiser: Well, bzr has to check what history is available remotely to know what should be uploaded, so certainly the smart server is far better for that [13:27] nod. [13:27] vila: all revision systems do that [13:27] But the progress bar indicators are not the best tool to diagnose what is dowloaded/uploaded and whn [13:27] when i do pushes i'll keep my eye on it and see if it seems to work consistantly better or not. [13:28] Coke: We can discuss for hours why the old formats are bad, but I find it a bit less interesting than knowing if the new format and/or the smart server suitsyour needs or not [13:28]