| lifeless | moin | 00:02 |
|---|---|---|
| lifeless | thumper: fixed in trunk I think | 00:02 |
| jelmer | 'morning lifeless | 00:02 |
| jml | hello everybody | 00:04 |
| poolie | hello all | 00:04 |
| mwhudson | lifeless: that means, if thumper uses bzr.dev he'll be able to upgrade? | 00:05 |
| garyvdm | HI | 00:05 |
| mwhudson | hi jelmer, thanks for the cscvs comments | 00:05 |
| jml | should that fix go into 1.16final? | 00:05 |
| garyvdm | Is there a mirror of bzr.dev in a bzr 1.3 compatible format? | 00:05 |
| garyvdm | For Richard Wilbur (see mailing list) | 00:06 |
| lifeless | jml: np | 00:06 |
| lifeless | jml: no | 00:06 |
| lifeless | jml: dev7->2a should be exceedingly rare | 00:07 |
| lifeless | jml: and multiple fixes are needed | 00:08 |
| lifeless | thumper: init a 2a tree somewhere else | 00:08 |
| jml | lifeless: cool. | 00:08 |
| lifeless | thumper: copy the repo/format file across; dev7 and 2a are identical | 00:08 |
| RenatoSilva | is lp: bzr+ssh? | 00:12 |
| RenatoSilva | is bzr+ssh on port 22? | 00:12 |
| jelmer | mwhudson: you're welcome | 00:13 |
| lifeless | RenatoSilva: lp: is an XMLRPC query, done on port 80, and then bzr+ssh on port 22 *or* http on 80 | 00:14 |
| jelmer | does bzr do any sort of normalization on symlink paths? | 00:15 |
| thumper | lifeless: ok, I'll try that | 00:16 |
| thumper | lifeless: bzr trunk still fails the upgrade | 00:16 |
| RenatoSilva | lifeless: so lp: is 80 then bzr+ssh, which is 22 or 80 (in this case httpS don't?) | 00:16 |
| wgrant | jml: Is there a 6 year delay for bzr 1.16, or did you mess up the date? | 00:17 |
| lifeless | RenatoSilva: no, 80 then either 22 or 80 | 00:17 |
| RenatoSilva | lifeless: that's what I said don't? | 00:18 |
| RenatoSilva | lifeless: but the latter 80 is over https right? | 00:19 |
| jml | wgrant, oops! | 00:19 |
| mwhudson | wgrant: he means wednesday in the us | 00:19 |
| RenatoSilva | How do I brz branch behind a proxy and with no access to external SSH? | 00:19 |
| * mwhudson hides | 00:20 | |
| RenatoSilva | I'm trying bzr branch lp:~renatosilva/+junk/moin.theme.solenoid | 00:20 |
| RenatoSilva | with HTTP_PROXY=http://aaaa | 00:20 |
| thumper | lifeless: is it branch format 6 or 7 that enables stacking? | 00:20 |
| RenatoSilva | and HTTP_PROXY_PORT=1234 | 00:20 |
| mwhudson | thumper: 7 | 00:20 |
| thumper | why then are new branches still being created with 6 FFS | 00:21 |
| mwhudson | thumper: all the new formats look like they should be branch7 | 00:22 |
| thumper | --development7 wasn't | 00:22 |
| thumper | or... | 00:23 |
| thumper | when I branched from another branch that was in format 6 it kept it | 00:23 |
| mwhudson | it is ow | 00:23 |
| mwhudson | *now | 00:23 |
| thumper | I've upgraded the branches now to 2a | 00:23 |
| thumper | I've not tried bzr 1.16, just bzr.dev | 00:23 |
| * thumper gets lp:bzr/1.16 | 00:23 | |
| lifeless | thumper: there is a bug open; in a shared repo 'bzr init' creates the default format not the repos matching format. | 00:25 |
| lifeless | thumper: secondly, branching existing projects preserves formats. | 00:25 |
| lifeless | thumper: if you aren't running 'bzr init' then you simply need to upgrade all your branches. | 00:25 |
| thumper | lifeless: do we have a nice command to upgrade all branches in a repo? | 00:25 |
| jelmer | lifeless: does bzr do any sort of normalization on symlink target paths? | 00:29 |
| RenatoSilva | Guys the port and host must be in one var, solved | 00:29 |
| RenatoSilva | bzr branch http://bazaar.launchpad.net/bzr-email/bzr-email --> bzr: ERROR: Not a branch: "http://bazaar.launchpad.net/bzr-email/bzr-email/". | 00:35 |
| RenatoSilva | but lp:bzr-email? | 00:35 |
| lifeless | http://bazaar.launchpad.net/bzr-email/bzr-email isn't a branch | 00:35 |
| RenatoSilva | Tried one bzr-email, trunk in the end (which is a series) | 00:36 |
| RenatoSilva | none worked | 00:36 |
| lifeless | http://bazaar.launchpad.net/~bzr/bzr-email/trunk is the branch | 00:36 |
| RenatoSilva | I wonder what lp:bzr-email does | 00:36 |
| lifeless | I don't know where you got http://bazaar.launchpad.net/bzr-email/bzr-email from. | 00:37 |
| RenatoSilva | sure it's the project, but how does it find the branch | 00:37 |
| wgrant | It asks the Launchpad XML-RPC RPC server for the real path. | 00:37 |
| lifeless | thumper: igc has been working on making upgrade more capable | 00:37 |
| wgrant | s/ RPC// | 00:37 |
| RenatoSilva | lifeless: from my mind hehe | 00:37 |
| RenatoSilva | wgrant: ah ok! | 00:37 |
| lifeless | RenatoSilva: lp:bzr-lp does an XMLRPC call, as I said when you asked about half an hour ago :) | 00:37 |
| RenatoSilva | lifeless: I'm missing the ~bzr | 00:38 |
| lifeless | jelmer: ECONTEXT. Inside inventories? | 00:38 |
| RenatoSilva | lifeless: sorry | 00:38 |
| lifeless | np | 00:41 |
| poolie | hi lifeless | 00:42 |
| poolie | hi spiv, if any | 00:42 |
| poolie | jesus, this progress bar thread... | 00:42 |
| mwhudson | poolie: :) | 00:45 |
| mwhudson | i think i'm on fullermd's side | 00:45 |
| poolie | me too, but that's a lot of heat | 00:45 |
| jelmer | lifeless: yeah | 00:50 |
| jelmer | lifeless: If I add a random byte string as symlink_target, will bzr modify it in any way? | 00:51 |
| lifeless | jelmer: depending on layer; it must be either unicode or utf8 | 00:53 |
| RenatoSilva | lifeless: I sucessfully installed it here | 00:54 |
| RenatoSilva | thanks | 00:54 |
| RenatoSilva | however I get this error: bzr: ERROR: socket.sslerror: (1, 'error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure') | 00:55 |
| lifeless | jelmer: but we won't randomly change it | 00:55 |
| RenatoSilva | is bzr-email trying to use ssh with smtp by default? | 00:55 |
| RenatoSilva | our internal server doesn't require auth to send mails | 00:55 |
| lifeless | email servers can request TLS | 00:56 |
| lifeless | which is like SSL | 00:56 |
| RenatoSilva | sure the server doesn't request any kind of auth | 00:59 |
| RenatoSilva | File "C:/Arquivos de Programas/Bazaar/plugins\email\smtp_connection.py", line 84, in _create_connection | 00:59 |
| RenatoSilva | it is try: self._connection.starttls() | 00:59 |
| RenatoSilva | http://www.mibbit.com/pb/qpen81 | 01:00 |
| lifeless | RenatoSilva: it looks like your server is offering TLS but doing it badly | 01:06 |
| lifeless | you could comment out that line if you like | 01:06 |
| RenatoSilva | lifeless: humm | 01:08 |
| RenatoSilva | lifeless: ha, that's what I did, I commented the try block | 01:09 |
| RenatoSilva | lifeless: I would expect it to raise an exception to be catched tough | 01:09 |
| RenatoSilva | lifeless: it seems that another kind of error happens | 01:09 |
| RenatoSilva | is post_commit_url a bzr option or bzr-email option? | 01:11 |
| lifeless | its for bzr-email, but only needed if your public url is set incorrectly | 01:13 |
| RenatoSilva | I don't have one | 01:15 |
| RenatoSilva | Actually I hacked the option to put a friendly title for the email | 01:15 |
| RenatoSilva | post_commit_url = My Project Name | 01:15 |
| garyvdm | RenatoSilva: btw - launchpad sends email when you push to a branch on launchpad. | 01:17 |
| RenatoSilva | hum maybe I could just branch bzr-email to do my customizations :) | 01:18 |
| jelmer | lifeless: not even removing double backslashes and that sort of thing? | 01:18 |
| garyvdm | RenatoSilva: People who want email should click on the "subscribe to this branch" button on the branch page. | 01:18 |
| RenatoSilva | garyvdm: I can't push to launchpad at work: ssh blocked and lp does not support http push | 01:19 |
| garyvdm | OK | 01:19 |
| jelmer | lifeless: kirkland seems to've hit a problem importing from git that suggests it does, but it'll probably be a bzr-git bug | 01:19 |
| lifeless | jelmer: I'm pretty sure we don't normpath or anything | 01:23 |
| RenatoSilva | garyvdm: does lp uses bzr-email | 01:35 |
| === jfroy is now known as jfroy|reborn | ||
| RenatoSilva | is tehre any work on pretty html emails? | 01:35 |
| garyvdm | RenatoSilva: I don't know. You could ask at #launchpad, or may be someone here will know | 01:36 |
| jml | it doesn't. | 01:36 |
| jelmer | lifeless: ok, I'll keep looking in bzr-git then. Thanks | 01:38 |
| RenatoSilva | jml: do you know what they use? | 01:41 |
| jml | RenatoSilva, some custom stuff that integrates with the Launchpad web application. | 01:43 |
| RenatoSilva | jml: maybe bzr-email wouldn't exist if they released such component | 01:44 |
| jml | RenatoSilva, I think it would. | 01:45 |
| fullermd | mwhudson, poolie: A lot of heat over wildly unimportant details is my specialty ;p | 01:52 |
| RenatoSilva | jml: why | 02:00 |
| RenatoSilva | wold that be easy if I had a rev_id and a branch object, to get the committer? | 02:01 |
| RenatoSilva | Inside a bzr plugin | 02:01 |
| lifeless | RenatoSilva: branch.repository.get_revision(rev_id).committer | 02:01 |
| spiv | lifeless: beat me to it :) | 02:02 |
| lifeless | RenatoSilva: there is another email sender for bzr branches, I don't remember the name offhand. Anyhow, it has a template system available. | 02:02 |
| lifeless | spiv: ;) | 02:02 |
| garyvdm | Is it possible to get a inventory from a WorkingTree that includes unknown items? | 02:02 |
| RenatoSilva | lifeless: oh, thank you so much! | 02:03 |
| RenatoSilva | lifeless: another better mail plugin? | 02:03 |
| jml | lifeless, I'll be a bit later than 1ish to yours if that's ok | 02:03 |
| jml | If I don't clean the dishes soon they will stage a bloody revolution. | 02:04 |
| lifeless | RenatoSilva: a different one | 02:07 |
| lifeless | jml: Sure. | 02:07 |
| * thumper doesn't like projects with broken trunks | 02:24 | |
| thumper | not bzr | 02:24 |
| thumper | Please note that code you get from this repository is not intended for productive use (unless it's tagged as a released version, of course, in which case the usual alpha/beta disclaimers apply ;-)). We like to break our codebase, config files, database schemas and all kinds of stuff. We sometimes commit non-compiling revisions to facilitate collaborative development. Running such an unstable version might trash your settings, your backlog and ma | 02:24 |
| thumper | your computer. You have been warned! | 02:24 |
| thumper | I like bzr's concept of a good trunk | 02:24 |
| thumper | why do people do this to themselves? | 02:25 |
| RenatoSilva | is branch.conf fetched when I copy a branch? | 02:26 |
| RenatoSilva | I want to use bzr-email at work, bring branch home, stop using bzr-email, work, commit, and push | 02:26 |
| lifeless | RenatoSilva: branch.conf isn't copied around | 02:33 |
| RenatoSilva | oh nice, then I can use bzr-email at work only | 02:33 |
| lifeless | RenatoSilva: you can configure bzr-email in locations.conf, then the config would be specific to that machine | 02:33 |
| lifeless | (as another option) | 02:34 |
| RenatoSilva | you mean in my app data? | 02:34 |
| RenatoSilva | in my ~ | 02:35 |
| lifeless | whereever your bazaar.conf is you can also have locations.conf | 02:36 |
| lifeless | bzr --version | 02:36 |
| lifeless | will tell you the place that is stored | 02:36 |
| RenatoSilva | this way it will work for any branches in my machine right | 02:37 |
| RenatoSilva | I think it's better for now leave it for the branch itself | 02:37 |
| poolie | hello spiv? what are you up to today? | 02:38 |
| RenatoSilva | but it's good to know of locations.conf, thanks! | 02:38 |
| garyvdm | Hi poolie - Please can you help me or point me to some who can. | 02:40 |
| poolie | garyvdm: with what? | 02:40 |
| garyvdm | I want to get an inventory from a WorkingTree that includes unknown items? | 02:40 |
| garyvdm | and merge that with information from iter_changes | 02:41 |
| poolie | oh i see | 02:41 |
| poolie | garyvdm: at the moment no, you need to call .unknowns() (??) separately and merge that | 02:41 |
| poolie | i think | 02:42 |
| poolie | fullermd: maybe you can ease off on it a bit? | 02:42 |
| * garyvdm looks | 02:42 | |
| poolie | oh | 02:43 |
| poolie | actually there is iter_changes(want_unversioned=True) | 02:43 |
| poolie | will that do it? | 02:43 |
| RenatoSilva | Is there a way to change history to replace the committer for some commits | 02:47 |
| garyvdm | poolie: I'm going to merge iter_changes into a inventory. That would help if there was also iter_changes(.., want_ignored=True) | 02:47 |
| RenatoSilva | bzr log --replace-commiter "Renato Silva mail@company" "Renato Silva mail@other" | 02:48 |
| RenatoSilva | Is this possible? | 02:48 |
| AfC | No | 02:48 |
| lifeless | garyvdm: want_unversioned=True | 02:49 |
| lifeless | garyvdm: and then filter the unversioned files | 02:49 |
| lifeless | oh poolie already answered :P | 02:50 |
| garyvdm | poolie: But there is not, so I think I'm going to use tree.extras which I found from you .unknowns() pointer | 02:50 |
| garyvdm | lifeless: I also may need to get ignored to. | 02:50 |
| lifeless | Have you checked that want_unversioned doesn't include ignored files? | 02:50 |
| * garyvdm checks | 02:51 | |
| garyvdm | lifeless: it doesn't. | 02:51 |
| lifeless | hmm | 02:51 |
| lifeless | well, I thin it would be reasonable to add a want_ignored then | 02:52 |
| === rocksta`` is now known as rockstar | ||
| lifeless | if your use case is at all common | 02:52 |
| garyvdm | lifeless: yes - maybe I should submit a patch. | 02:53 |
| garyvdm | poolie, lifeless: I also will want to drill into a dir (only when the user expands it in the gui) | 02:54 |
| garyvdm | is there anything that will help me with this? | 02:55 |
| poolie | garyvdm: i see iter_changes lets you specify a directory to list | 02:57 |
| poolie | i'm not sure if there's a way to say "but don't go any deeper" | 02:57 |
| spiv | poolie: hi, currently (after sleeping in...) I'm looking at landing http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C20090424063000.GA29688%40steerpike.home.puzzling.org%3E, which has been approve (tweak) for ages. | 02:57 |
| poolie | perhaps there should be | 02:57 |
| garyvdm | poolie: ok - let me look at that | 02:58 |
| poolie | lifeless: re bug 351459 would i be right in thinking subunit is used in the implementation of parallel testing? | 02:58 |
| ubottu | Launchpad bug 351459 in bzr "Error in parallel selftest: cannot import name ConcurrentTestSuite" [Undecided,Incomplete] https://launchpad.net/bugs/351459 | 02:58 |
| poolie | spiv, jolly good | 03:01 |
| garyvdm | poolie: Last question: To merge the information from iter_changes into a Inventory, I need to create a in memory copy of the inventory, and then add the unversioned items into that? | 03:04 |
| garyvdm | would that be possible, or should I create my on Inventory like object to do that? | 03:05 |
| garyvdm | s/on/own | 03:05 |
| poolie | there's a create_by_apply_delta function on inventory | 03:06 |
| poolie | i think you can use that | 03:06 |
| lifeless | garyvdm: re: single dir expansion | 03:07 |
| lifeless | garyvdm: we found via testing that its faster to do all at once | 03:07 |
| lifeless | garyvdm: its a lot simpler and more consistent. | 03:07 |
| lifeless | garyvdm: I think igc has some patches towards making a nonrecursive flag; I'm not at all convinced that this is needed. | 03:07 |
| lifeless | or in fact beneficial | 03:07 |
| lifeless | garyvdm: re: Inventory - generally as a client of bzrlib you shouldn't be mutating inventories; what is the goal/use case you're working towards | 03:08 |
| garyvdm | lifeless: Goal: I have a widget that displays a inventory | 03:09 |
| garyvdm | and a widget that displays iter_changes. | 03:09 |
| garyvdm | And I want to merge them into one. | 03:09 |
| garyvdm | lifeless: re: single dir expansion - I only want to expand into a dir only when, and if the user specifically asks for it (by expanding the dir on the widget) | 03:11 |
| lifeless | garyvdm: sure. consume the whole iterator and then only show the bits you want | 03:11 |
| * garyvdm looks at create_by_apply_delta | 03:12 | |
| lifeless | I don't quite follow the widget combining though | 03:12 |
| garyvdm | lifeless: We have a widget that shows you the tree for a revision (run bzr qbrowse). This consumes a inventory. | 03:14 |
| garyvdm | lifeless: I want to extend that to something that can show you the working tree, where you can say show unknown, show ignored, hide unchanged | 03:16 |
| jelmer | kirkland: hi | 03:17 |
| kirkland | jelmer: howdy | 03:17 |
| garyvdm | lifeless: To make the code that gets that data from the inventory simple, I want to just add the unknown/ignored into the inventory | 03:18 |
| jelmer | kirkland: the bug in bzr-git importing live-helper you were seeing should be fixed now | 03:18 |
| kirkland | jelmer: rolled out to LP? | 03:19 |
| garyvdm | lifeless: but I guess that I can make it just get data from both the inventory, and what we got from iter_changes at the same time. | 03:19 |
| jelmer | kirkland: no, it'll only work for manual imports | 03:19 |
| jelmer | kirkland: I can upload my personal import though, if that would be useful | 03:19 |
| lifeless | garyvdm: you should make it show a 'Tree' not an 'Inventory' | 03:22 |
| lifeless | garyvdm: Inventories cannot have unknowns/ignored | 03:22 |
| kirkland | jelmer: hmm | 03:22 |
| lifeless | garyvdm: inventories in the bzr 2 format are immutable, you can't change them. | 03:23 |
| kirkland | jelmer: glad to hear you have the bug fixed | 03:23 |
| kirkland | jelmer: I'm mainly interested in this from a vcs-imports into LP perspective | 03:23 |
| lifeless | garyvdm: and if you just want it to show the working tree, using the working tree extras and unknowns methods are much better than doing iter_changes | 03:23 |
| lifeless | iter_changes is a delta operation, and you aren't describing a need to do a delta. | 03:23 |
| jelmer | kirkland: Ah, ok. I'm not a lp dev, mwhudson, jml or thumper should be able to tell you when this would/could land. | 03:24 |
| garyvdm | lifeless: But I also need to show a status for a changed item. | 03:24 |
| kirkland | jelmer: so i'll lean on those guys to get it rolled out to LP :-) | 03:24 |
| kirkland | jelmer: thanks for your help, as always | 03:24 |
| mwhudson | it shouldn't be a big deal | 03:24 |
| lifeless | garyvdm: oh ok. Well then yes iter_changes is appropriate | 03:24 |
| mwhudson | jelmer: did you have to change dulwich too? | 03:24 |
| jelmer | mwhudson: no, just bzr-git | 03:24 |
| mwhudson | dead easy then | 03:25 |
| kirkland | mwhudson: sweet | 03:25 |
| kirkland | fwiw, this is the broken import: https://code.edge.launchpad.net/~vcs-imports/qemu/git | 03:25 |
| jelmer | kirkland: Oh, I was actually talking about the live-helper one, not sure about qemu | 03:26 |
| kirkland | jelmer: oh, hmm, i'm confused | 03:26 |
| kirkland | jelmer: pointer? | 03:27 |
| jelmer | kirkland: I'm sorry, I messed up two bug reports :-( | 03:27 |
| kirkland | jelmer: heh! | 03:27 |
| jelmer | although I guess my last round of fixes could've taken care of the qemu one as well | 03:28 |
| * jelmer checks | 03:28 | |
| jelmer | cody-somerville: hi | 03:29 |
| jelmer | cody-somerville: the live-helper imports should work now. | 03:30 |
| cody-somerville | jelmer, w00t | 03:30 |
| kirkland | jelmer: cool, let me know! | 03:30 |
| cody-somerville | jelmer, Is this with the latest bzr-git or with the version launchpad uses? | 03:33 |
| jelmer | cody-somerville: latest bzr-git as of a few minutes ago, not yet on lp | 03:35 |
| jml | as a rule we don't run few-minutes-old code on lp :) | 03:40 |
| garyvdm | jml: $ bzr qannotate . > bzr: ERROR: bzr qannotate only works for files (got 'directory') | 03:44 |
| garyvdm | </brag> | 03:45 |
| garyvdm | jml: would be cool if that was in bzrlib. | 03:45 |
| ablmf | Which proxy does bazaar use on windows? IE or default browser's setting? | 03:54 |
| lifeless | I think it only uses the http_proxy environment variable setting | 03:56 |
| abadger1999 | Any bzr-gtk people about? | 04:01 |
| abadger1999 | I just want to know what I need to package to go along with our bzr-1.16 release (a snapshot? Which tree? A patch? Where?). | 04:02 |
| jelmer | abadger1999: we should do a release at some point, but for now I'd package a snapshot of trunk | 04:02 |
| jelmer | at least that's what I expect to end up doing for debian | 04:03 |
| jelmer | kirkland: confirmed that qemu also imports fine now | 04:03 |
| kirkland | jelmer: \o/ | 04:03 |
| kirkland | jelmer: thanks | 04:04 |
| kirkland | mwhudson: cool, that getting rolled out to edge anytime soon? | 04:04 |
| abadger1999 | jelmer: lp:bzr-gtk ? | 04:04 |
| jelmer | abadger1999: yep | 04:04 |
| abadger1999 | jelmer: Thanks! | 04:05 |
| mwhudson | kirkland: no, there's no edge for code imports | 04:06 |
| kirkland | mwhudson: ah | 04:06 |
| mwhudson | kirkland: you'll have to wait for the rollout in c. a week | 04:06 |
| kirkland | mwhudson: cool, thanks. | 04:06 |
| jelmer | mwhudson: so, the only bug I'm aware of now is that submodules don't work. All other import bugs I'm aware of should be fixed now. | 04:11 |
| mwhudson | jelmer: sounds good | 04:11 |
| mwhudson | jelmer: what are submodules? | 04:12 |
| lifeless | nested trees | 04:12 |
| jelmer | mwhudson: gitspeak for nested trees | 04:12 |
| mwhudson | ah ok | 04:12 |
| mwhudson | i can understand why they don't work yet then :) | 04:12 |
| igc | hi all | 04:19 |
| ablmf | Oh, I use "set http_proxy=http://10.0.0.3:80" to set the enviroment variable, but bzr still can not reach the repository. | 04:46 |
| ablmf | Web access is OK. | 04:46 |
| mwhudson | it seems to take bazaar quite a while to figure out that it needs to download all revisions when getting a branch for the first time | 05:08 |
| mwhudson | it seems to be sending 30k get_parent_map requests :/ | 05:09 |
| mwhudson | (this is launchpad, so plenty of ghosts and all that) | 05:09 |
| lifeless | mwhudson: bzr versions? | 05:10 |
| mwhudson | lifeless: 1.16rc1 on both sides | 05:10 |
| lifeless | odd | 05:10 |
| lifeless | its meant to cache misses | 05:10 |
| lifeless | file a bug, gather data, etc. | 05:11 |
| spiv | mwhudson: also, I guess you're fetching into an empty shared repo rather than into a new standalone branch? | 05:11 |
| mwhudson | spiv: you are correct | 05:12 |
| mwhudson | spiv: i can try standalone in a bit if you like | 05:12 |
| spiv | Well, that explains why it's doing walk_to_common_revisions, although why it's so slow is a bit of a mystery. | 05:12 |
| spiv | mwhudson: standalone will be much faster; bzr in that case just asks the branch what the last_revision is, then asks the repo to send a complete stream for that revision. | 05:13 |
| spiv | For that revision's ancestry, I should say. | 05:13 |
| mwhudson | spiv: presumably the streaming itself will be the same | 05:14 |
| spiv | Right, it should be. | 05:14 |
| mwhudson | bah, seems to have stalled | 05:16 |
| lifeless | mwhudson: we still want a bug | 05:16 |
| lifeless | the 'shared repo is slower' is a defect we need to fix. | 05:17 |
| spiv | lifeless: just need an "is_empty" method on Repository ;) | 05:17 |
| mwhudson | lifeless: i was thinking of posting a .bzr.log when it's done | 05:17 |
| mwhudson | lifeless: which it isn't yet | 05:17 |
| lifeless | spiv: ENOTAFIX | 05:17 |
| lifeless | mwhudson: start with a bug :) | 05:18 |
| lifeless | spiv: or rather, EYETANOTHERPARTIALFIX | 05:18 |
| spiv | Yeah. | 05:18 |
| ablmf | My bzr refused to use proxy. Nothing seems to work. I set IE proxy. I "set HTTP_PROXY=10.0.0.3:80", I "set HTTP_PROXY=10.0.0.3:80" | 05:25 |
| ablmf | It just ignore all this and try to connect directly. | 05:26 |
| lifeless | it should be in lower case, like 'http_proxy=http://10.0.0.3:80/ | 05:26 |
| spiv | ablmf: set http_proxy=http://10.0.0.3:80/ | 05:26 |
| lifeless | ablmf: note that 'lp:' URL's won't use the proxy | 05:26 |
| lifeless | ablmf: its a known bug in the python xmlrpc library, which we haven't [yet] worked around | 05:26 |
| ablmf | lifeless: Ah, then there is no work around now? | 05:26 |
| lifeless | you can go to the elaunchpad website and get the bzr+ssh or http equivalent url for branches | 05:27 |
| ablmf | OK. I will try | 05:27 |
| spiv | ablmf: use http://bazaar.launchpad.net/... URLs (or bzr+ssh://...) rather than lp: URLs. | 05:27 |
| ablmf | But what is the full url of a lp:xxx ? I can not find it on their web site | 05:35 |
| lifeless | ablmf: go to code.launchpad.net/xxx | 05:36 |
| mwhudson | spiv, lifeless: https://bugs.edge.launchpad.net/bzr/+bug/388269 | 05:36 |
| ubottu | Launchpad bug 388269 in bzr "getting a branch into an empty shared repository takes a long time to figure out revisions to send" [Undecided,New] | 05:36 |
| spiv | mwhudson: thanks | 05:36 |
| lifeless | ablmf: once on that web page, lcok on the branch - the lp:xxx link there | 05:38 |
| lifeless | then you'll be at | 05:38 |
| lifeless | code.launchpad.net/<user>/<xxx>/<branchname> | 05:38 |
| lifeless | in bzr you should use http://bazaar.launchpad.net/<the rest the same> | 05:38 |
| ablmf | OK. finally I found I should use "bzr info https://code.launchpad.net:443/oah" | 05:44 |
| ablmf | Seems that 443 is required | 05:45 |
| ablmf | It starts to downloading! | 05:47 |
| ablmf | Thanks a lot. But I really think it should be included in the "trouble shooting" in bazaar's document. | 05:47 |
| poolie | mwhudson or others: do you care about the 'dots' progress bar type? | 06:01 |
| mwhudson | poolie: no | 06:01 |
| mwhudson | poolie: by 'mwhudson' do you mean launchpad? | 06:02 |
| poolie | heh | 06:02 |
| mwhudson | (either way the answer is still no) | 06:02 |
| poolie | either way | 06:02 |
| === abentley1 is now known as abentley | ||
| poolie | hello abentley | 06:04 |
| RenatoSilva | How to apply a merge directive into a branch? | 06:27 |
| poolie | RenatoSilva: cd ~/my/branch; bzr merge /tmp/mergedirective | 06:28 |
| RenatoSilva | thanks, I'll try that | 06:28 |
| RenatoSilva | bzr branch lp:bzr-email: FATAL ERROR: Disconnected: No supported authentication methods available | 06:29 |
| RenatoSilva | why is it trying to authenticate? | 06:30 |
| poolie | i think it's trying to pull from launchpad over ssh | 06:30 |
| RenatoSilva | if I'm not logged then it should use http | 06:30 |
| RenatoSilva | unless bzr launchpad-login is persistent | 06:31 |
| === abentley1 is now known as abentley | ||
| poolie | it is persistent | 06:40 |
| RenatoSilva | poolie: http://pastie.org/514743 | 06:41 |
| RenatoSilva | something like bzr branch --annonymous, and bzr lp-logout would be nice | 06:42 |
| poolie | interesting point | 06:42 |
| poolie | see bug 349143 | 06:42 |
| ubottu | Launchpad bug 349143 in bzr "no lp-logout command" [Low,Confirmed] https://launchpad.net/bugs/349143 | 06:42 |
| RenatoSilva | nice | 06:43 |
| poolie | it shouldn't be an option to branch | 06:43 |
| poolie | it could be eg lp+anon://blah | 06:43 |
| RenatoSilva | or lpa: | 06:44 |
| RenatoSilva | what'sa this message: Preview patch does not match changes | 06:47 |
| RenatoSilva | when bzr merge | 06:47 |
| poolie | the diff in the bundle is not what the metadata says it should be | 06:47 |
| poolie | maybe because | 06:47 |
| poolie | 1- someone edited the diff after running bzr send | 06:47 |
| RenatoSilva | oh I just cleaned the screen :( | 06:47 |
| poolie | ok | 06:47 |
| RenatoSilva | I missed your 1s msg | 06:48 |
| poolie | ? | 06:48 |
| poolie | maybe because | 06:48 |
| poolie | 1- someone edited the diff after running bzr send | 06:48 |
| poolie | 2- you copy-and-pasted it and that messed it up slightly | 06:48 |
| RenatoSilva | I created a branch and applied the directive | 06:49 |
| RenatoSilva | oh I edited the diff!! | 06:49 |
| poolie | :) | 06:49 |
| RenatoSilva | it seems that it was applyed tough | 06:49 |
| RenatoSilva | Preview patch does not match changes --> is this some kind of hash check? | 06:50 |
| RenatoSilva | preview patch == the hash | 06:50 |
| RenatoSilva | changes == the actual patch | 06:50 |
| RenatoSilva | ? | 06:50 |
| poolie | yes | 06:51 |
| SuperMMX | I got this error after C-c "bzr shelve", bzr 1.14. http://paste.ubuntu.com/197472/ , any idea ? | 06:52 |
| RenatoSilva | poolie: ah ok | 06:55 |
| SuperMMX | anyone / | 06:58 |
| SuperMMX | my dirstat get corrupted ? | 07:04 |
| === abentley1 is now known as abentley | ||
| RenatoSilva | Hey! https://code.launchpad.net/~renatosilva/bzr-email/mail-customization :) | 07:08 |
| SuperMMX | can anyone see my problem? (13:52:03) SuperMMX: I got this error after C-c "bzr shelve", bzr 1.14. http://paste.ubuntu.com/197472/ , any idea ? | 07:09 |
| SuperMMX | I can't do anything useful now with my tree. | 07:10 |
| vila | hi all | 07:14 |
| Peng_ | SuperMMX: Beloved dirstate got screwed up. I'd move .bzr/checkout out of the way and run "bzr checkout". I'm pretty sure it won't clobber your working tree, but not 100%. | 07:14 |
| vila | jml: ping | 07:15 |
| vila | jml: Where should I land https://code.edge.launchpad.net/~vila/bzr/284038-push-strict/+merge/7373 ? 1.16 or trunk ? It should apply cleanly in both (modulo NEWS conflicts) | 07:16 |
| poolie | hello vila | 07:16 |
| SuperMMX | Peng_, thanks, I will try | 07:18 |
| jml | vila, busy right now, gimme a few minutes -- sorry | 07:21 |
| poolie | vila, hi? | 07:22 |
| vila | jml: np as long as you reply before the end of your day :) | 07:22 |
| vila | poolie: hi ! | 07:22 |
| * vila swears about losing sound support in its VM... | 07:22 | |
| poolie | vila did you see my pm? | 07:23 |
| * vila meant curse | 07:23 | |
| vila | ho ! | 07:23 |
| poolie | 'swears' means what i think you think it means there :) | 07:24 |
| SuperMMX | Peng_: yes, it works, except some modified files are moved. | 07:25 |
| jml | vila, I'll do that. | 07:28 |
| lifeless | vila: if its not a regression, it should only be landed in trunk | 07:34 |
| lifeless | vila: standard policy | 07:34 |
| lifeless | [regression or otherwise deemed 'really important' | 07:34 |
| ablmf | A problem when downloading code by brz : http://pastebin.com/d15ad9e89 | 07:44 |
| lifeless | I would guess you have in intercepting proxy where you are, one that is broken (e.g. older versions of squid) | 07:46 |
| lifeless | vila: ^ we *do* handle a 200 response to a range request correctly don't we? | 07:46 |
| lifeless | poolie: EODing | 07:48 |
| jml | vila, what lifeless said. | 07:49 |
| poolie | bye lifeless | 07:50 |
| vila | lifeless: 99% sure, want 100% ? | 07:51 |
| lifeless | vila: huh? | 07:51 |
| vila | lifeless: 200 response is a while file even if range was requested right ? So without looking at the code, I'm 99% sure | 07:52 |
| vila | s/while/whole/ | 07:52 |
| lifeless | vila: good enough for me | 07:52 |
| lifeless | sugguests that whatevere made it into a 200 broke on a subsequent request | 07:52 |
| vila | lifeless, jml: Ok, I'll land to trunk then | 07:52 |
| Peng_ | I can confirm that getting the whole file is handled properly. I don't remember if the response was 200 or 206, though. | 07:53 |
| lifeless | vila: you should only ever land to trunk FWIW. cherrypicks to release branches are separate ;) | 07:53 |
| jml | vila, thanks. | 07:53 |
| Peng_ | (I mean, it's inefficient as hell, but it won't break anything.) | 07:53 |
| lifeless | Peng_: if you ask for ranges and get 200, is the specific case. | 07:53 |
| lifeless | 206 *is* a range response. | 07:53 |
| Peng_ | lifeless: Yeah, but it could be a range over the whole file. Or something. | 07:53 |
| * Peng_ shrugs. | 07:53 | |
| vila | lifeless: right, you want 100%, let me look at when we issue that message :) | 07:54 |
| Peng_ | I am 100% sure -- I did it a few weeks ago. | 07:54 |
| ablmf | Ah, it seems that the only way to bzr work for me is to find a computer which doesn't need a proxy to access internet. | 07:55 |
| ablmf | Hope some day bazaar will be stable enough to avoid these kind of small problems. :) | 07:56 |
| Peng_ | (When testing Loggerhead's server, FWIW. Paste's static file server doesn't support Range requests -- or at least the version I have.) | 07:58 |
| vila | lifeless: so that message is issued when we realized the problem and we warn only once | 08:00 |
| vila | lifeless: if realized you EODed, but I'm not sure I understand: "sugguests that whatevere made it into a 200 broke on a subsequent request". Hmm, in fact I'm sure I don't understand :-) | 08:08 |
| vila | Peng: can you shed some light ? The warning intent is to help people realize they get poor performance because their server... sucks :) | 08:10 |
| lifeless | vila: see the pastebin ablmf linked | 08:10 |
| lifeless | ablmf: bzr doesn't generally have trouble with http proxies; its just some proxy versions are broken. | 08:10 |
| Peng_ | vila: Me? It's dark over here. :P | 08:11 |
| vila | Peng: sorry for the noise then | 08:11 |
| vila | lifeless: The warning intent is to help people realize they get poor performance because their server... sucks :) As in: without ranges many bzr optimizations are useless. Other than that the processing should be fine. Modulo broken proxies detection for which we never found a reliable way (AFAIR). | 08:12 |
| lifeless | vila: yes, I know. | 08:13 |
| lifeless | vila: but *see the pastebin* | 08:13 |
| RenatoSilva | bug 388300 | 08:13 |
| ubottu | Launchpad bug 388300 in bzr-eclipse "Error after installing bzr-xmloutput" [Undecided,New] https://launchpad.net/bugs/388300 | 08:13 |
| RenatoSilva | what could that be? | 08:13 |
| vila | lifeless: I have already read it twice, hoooo, the second part, invalid boundary, I need a -Dhttp for that, it may be two different requests | 08:14 |
| vila | bah, launchpad involved, good server, so that's a broken proxy, 90% sure | 08:14 |
| vila | ablmf: I'm pretty sure you have a broken proxy, as far as I recall, even issuing whole file requests may not be enough to cure your problem, | 08:15 |
| vila | ablmf: try issuing the same command but adding '-Dhttp' so that we get more precise informations in .bzr.log | 08:16 |
| vila | lifeless: sorry, I need one more coffee :-) | 08:17 |
| ablmf | vila: ok, I am trying. | 08:19 |
| ablmf | vila: Maybe I met a bad proxy, but it's good enough for surf internet. And it also works fine with other version control tools. | 08:20 |
| vila | ablmf: It will help if you can find what proxy software you're using, each time that bug has been hit in the past, upgrading the proxy was the true solution | 08:20 |
| ablmf | :( That's out of my control | 08:21 |
| Peng_ | ablmf: Bazaar over HTTP makes uncommonly large range requests, which some broken proxies can't handle. | 08:21 |
| Peng_ | ablmf: If you register on Launchpad, you can use bzr+ssh. | 08:22 |
| vila | Peng: nope. the bug is triggered by small requests over very large files | 08:22 |
| Peng_ | vila: Oh. That's weird. | 08:22 |
| vila | ablmf: and that's why it has such an impact on perfs, it will consume a lot more bandwidth | 08:23 |
| vila | ablmf: knowing that may help address 'not under your control' by providing a really good reason to upgrade | 08:23 |
| vila | ablmf: it's a company proxy right ? | 08:24 |
| ablmf | vila: yeah, it's my company's proxy | 08:24 |
| vila | ablmf: anyway, even if you can't upgrade, it will be good for us to *know* what software/version causes that (if only to report the problem0 | 08:25 |
| vila | ablmf: bzr triggers the bug, but the bogus proxy behavior (downloading whole files instead of ranges) can be experienced by other softwares without trigerring the bug | 08:27 |
| ttyType | hi all | 08:48 |
| vila | hi alone ;) | 08:49 |
| ttyType | i am new to bazaar, having used SVN previously. i have read some stuff, and am wondering, is it possible for two people to "push" to the same branch server location(sftp) | 08:49 |
| vila | ttyType: sure | 08:50 |
| ttyType | ah, hmm | 08:50 |
| ttyType | ok | 08:50 |
| ttyType | ty | 08:50 |
| vila | ttyType: additionally, if bzr is installed there, using bzr+ssh instead of sftp may provides better performances | 08:50 |
| ttyType | vila: is that similar to the svn+ssh system, whereby an svnserve-like program is invoked on the server? | 08:51 |
| AfC | ttyType: yes | 08:52 |
| ttyType | ah, could be an issue. you see, my server has 32MB of RAM | 08:52 |
| ttyType | and a 150MHz CPU | 08:52 |
| ttyType | and no swap space | 08:52 |
| lifeless | yes, could well be an issue ;) | 08:53 |
| ttyType | with svnserve -t, it was just running out of memory | 08:53 |
| AfC | (The same code is also invoked if you run bzr as a full-time standalone [read-only] server, bzr://) | 08:53 |
| ttyType | i'm using one of these jobbies: http://bifferos.bizhat.com/ | 08:54 |
| ttyType | it's a little power hungry for it's MIPS, but it was £30 | 08:54 |
| vila | ttyType: forget bzr+ssh then :) | 08:54 |
| ttyType | :) | 08:55 |
| * vila notes that dumb server support rocks ;-) | 08:55 | |
| Peng_ | So, um. I'm messing around with bzr+http's jailing, and I want to make sure I didn't screw up and make it horribly insecure. How do you think I should do that? | 08:56 |
| ttyType | w00t | 08:56 |
| AfC | ttyType: that looks like fun to play with | 08:57 |
| ttyType | AfC: indeedy. sure it's not a powerful as a gumstix board, but doodd!!!! £30!! | 08:57 |
| AfC | I was just going to suggest gumstix | 08:59 |
| ttyType | actually, if i wanted that kind of power, i would probably use a beagleboard | 09:00 |
| ttyType | same guts as teh gumstix | 09:00 |
| ttyType | *th | 09:00 |
| ttyType | *the | 09:00 |
| * ttyType fails at typing | 09:00 | |
| ttyType | yeah, get a beagleboard, run a windows CE server :D | 09:01 |
| === abentley1 is now known as abentley | ||
| ttyType | it's a shame the beagleboard has no ethernet :-/ | 09:03 |
| Peng_ | spiv: ping | 09:05 |
| spiv | Peng_: pong | 09:06 |
| spiv | Peng_: about bzr+http jailing? A good way to experiment would be with hitchhiker. | 09:08 |
| spiv | Peng_: see if it lets you access unexpected stuff. | 09:08 |
| Peng_ | spiv: I wrote an evil monkeypatch that works (just for me, not for other users), and was hoping you could tell me if it's horribly unsafe. | 09:08 |
| Peng_ | spiv: http://paste.pocoo.org/show/123617/ | 09:09 |
| * igc dinner | 09:11 | |
| spiv | Peng_: that looks ok off the top of my head, please add it to the bug | 09:18 |
| Peng_ | spiv: FWIW, I made it a bit more paranoid by making sure it is a ChrootTransport. | 09:19 |
| lifeless | Peng_: I don't know that that is beneficial, for all that its typical. | 09:20 |
| Peng_ | Paranoia is fun. | 09:20 |
| Peng_ | lifeless: Unless you meant something else? | 09:20 |
| lifeless | it could be a ReadOnlyDecorator | 09:20 |
| lifeless | legitimately I mean, you have three layers: t, readonly+, chroot+ | 09:21 |
| lifeless | and I don't know that forcing the chroot to the top is good | 09:21 |
| Peng_ | So, get rid of the paranoia? | 09:21 |
| lifeless | I would | 09:22 |
| Peng_ | OK. | 09:22 |
| === KX__ is now known as KX | ||
| Peng_ | spiv & lifeless: Thank you! :) | 09:24 |
| Peng_ | This was only a few minutes of work. I really should've thought to do it 3 months ago. :\ | 09:24 |
| vila | Peng_: But shouldn't you add part of that 3 months of though to the few minutes of work ? | 09:27 |
| lifeless | vila: ?! | 09:41 |
| lifeless | what are you doing to bug 388020 | 09:41 |
| ubottu | Launchpad bug 388020 in bzr "UnknownErrorFromSmartServer when pushing (or committing to a bound branch) with 1.16rc1 " [High,Confirmed] https://launchpad.net/bugs/388020 | 09:41 |
| vila | lifeless: it was assigned to bzr-search, I've seen it without bzr-search, doesn't make sense to leave assigned to bzr-search, no ? | 09:42 |
| lifeless | check the back traces | 09:42 |
| lifeless | you have a different bug | 09:42 |
| lifeless | UnknownError just means its an error that can't be translated | 09:42 |
| lifeless | you really do need more coffee I think | 09:43 |
| AfC | EINSUFFICIENTCAFFEINE | 09:45 |
| vila | 2 backtraces out of the 3 doesn't involve bzr-search | 09:46 |
| vila | Let me look my .bzr.log, right, mine seems to be triggered by bzr-email instead :-) ... | 09:49 |
| lifeless | vila: then yours is a bzr-email bug | 09:50 |
| lifeless | vila: my rule of thumb is 'file new bugs' | 09:50 |
| lifeless | dups are easier to deal with than conflated bugs | 09:50 |
| vila | lifeless: yeah, sorry, doing that right now | 09:50 |
| vila | I didn't realize the error was generic (as mentioned, it was lost in the noise) | 09:51 |
| ttyType | lo, all | 09:56 |
| ttyType | is there a way to make bzr push via HTTP? | 09:56 |
| ttyType | or any other protocol for that matter, just nothing that involves invoking something on the server that will suck up memory like svnserve does | 09:57 |
| lifeless | ttyType: sftp:// is your best bet | 09:58 |
| lifeless | you could use webdav if you want, but thats in a plugin | 09:58 |
| ttyType | that's what i was going to do, but the only ftp servers in the opkg repo are vsftpd and pure-ftpd | 09:59 |
| wgrant | sftp is over SSH. | 09:59 |
| wgrant | It's not real FTP. | 09:59 |
| ttyType | vsftpd fails, and pure-ftpd doesn't wanna do ssl for some reason | 09:59 |
| ttyType | hmm | 09:59 |
| wgrant | OpenSSH implements SFTP by default. | 09:59 |
| wgrant | So you should just need an SSH server on there. | 09:59 |
| wgrant | Which I presume you already have. | 09:59 |
| ttyType | wgrant: indeed i do, but i tried doing svn+ssh before, and it just nommed all of my memory(32MB) | 10:00 |
| wgrant | ttyType: svn+ssh and bzr+ssh actually execute svn or bzr on the server. sftp doesn't. | 10:00 |
| wgrant | sftp just pushes the files up. | 10:00 |
| ttyType | wgrant: ah! this sounds like what i want | 10:01 |
| ttyType | so how do i set up the server to take sftp? | 10:01 |
| ttyType | a link to a guide would be fine | 10:01 |
| wgrant | ttyType: You don't need to do anything. | 10:01 |
| wgrant | Just try pushing. | 10:01 |
| wgrant | It should work. | 10:01 |
| ttyType | wgrant: ah, hmmm | 10:01 |
| ttyType | awesomes :) | 10:01 |
| Peng_ | ttyType: SSH servers usually have SFTP enabled by default. | 10:01 |
| ttyType | wgrant: so where on the server's filesystem does the push go to? | 10:02 |
| Peng_ | ttyType: It's relative to the root. | 10:02 |
| wgrant | ttyType: The root. | 10:02 |
| ttyType | ah..hmmm | 10:02 |
| ttyType | this sounds like a good idea | 10:02 |
| wgrant | So, 'bzr push sftp://some.server/home/user/blah' would work. | 10:02 |
| * ttyType disables pure-ftpd on his teeny linux SBC | 10:02 | |
| Peng_ | ttyType: You can use sftp://server/~/relative/to/your/home | 10:02 |
| === LenZGr_ is now known as LenZ | ||
| === LenZ is now known as LenzGr | ||
| fullermd | poolie: Already [not] done. | 10:27 |
| ttyType | hi again, people | 10:29 |
| ttyType | after pushing a revision via sftp to a server, how would i go about updating another branch to that? | 10:29 |
| ttyType | (without redownloading the whole thing | 10:30 |
| ttyType | ) | 10:30 |
| ttyType | like if it was on another computer | 10:30 |
| poolie | cheers, goodnight fullermd | 10:30 |
| fullermd | Good morning ;p | 10:31 |
| lifeless | ttyType: in that other branch, bzr pull <url> | 10:38 |
| === kkubasik_ is now known as kkubasik | ||
| ttyType | lifeless: ah...hmm, well, i just googled around some more and found "bzr merge, and that seems to do it" | 10:39 |
| ttyType | here's the output from my script, could i have a free sanity check from one of you people who knows what they are doing? http://pastebin.com/m5bb7ae37 | 10:39 |
| lifeless | you can use pull or merge depending on your needs | 10:40 |
| lifeless | if you're moving from one machine to the other and back, push + pull is likely whast you want | 10:40 |
| lifeless | if you're making concurrent edits you'll want to be doing push then merge+commit | 10:40 |
| ttyType | lifeless: commit first, i imagine, otherwise merge gets upset about uncommitted changes | 10:40 |
| lifeless | ttyType: doing a merge doesn't commit what it merged, | 11:05 |
| lifeless | ttyType: so if you had uncommitted changes before merging, yes you should commit them first, but still do the commit after the merge. | 11:05 |
| ttyType | you just said two opposite things i think :-S | 11:06 |
| ttyType | lifeless: so..i would do commit -> merge -> commit -> push | 11:08 |
| spiv | ttyType: probably, yes. | 11:18 |
| spiv | ttyType: the reason why you need to commit after merge is that merge *creates* uncommitted changes (the changes that are being merged in from the other branch). | 11:19 |
| ttyType | spiv: i see | 11:20 |
| ttyType | thanks | 11:20 |
| ttyType | spiv: the commit after the merge is giving this: | 11:23 |
| ttyType | aborting commit write group: PointlessCommit(No changes to commit) | 11:23 |
| ttyType | bzr: ERROR: No changes to commit. Use --unchanged to commit anyhow. | 11:23 |
| ttyType | should i just ignore that | 11:23 |
| lifeless | ttyType: then you had nothing to merge | 11:24 |
| lifeless | ttyType: and the merge would have told you that | 11:24 |
| ttyType | lifeless: isee | 11:25 |
| ttyType | what is the difference between bzr branch and bzr checkout? | 11:50 |
| lifeless | ttyType: branch makes a new branch [and sets you up to edit it]. checkout lets you edit an existing branch | 11:55 |
| ttyType | lifeless: but both commands pull the repo from a server, and edit it, don't they? | 11:56 |
| ttyType | s/and edit it/and let you edit it/ | 11:57 |
| lifeless | yes. In a new branch when yo ucommit the original branch isn't altered. In a checkout when you commit the origin branch *is* altered. | 11:58 |
| lifeless | I'm heading off now | 11:59 |
| ttyType | ok, bye | 11:59 |
| ttyType | thanks | 11:59 |
| fullermd | ttyType: For a checkout, you can think of the repo it pulls as just a local cache, to speed some things up. It's not an independant branch, even though it has everything it needs to be. | 12:02 |
| === sabdfl1 is now known as sabdfl | ||
| fullermd | Man, I speak up, and everybody quits or loses connection... :( | 12:04 |
| ttyType | fullermd: ah, i see | 12:05 |
| ttyType | so what is bzr pull? | 12:05 |
| ttyType | my synchronization process involves: add -> commit -> merge -> commit -> push | 12:06 |
| ttyType | why would i need a pull? | 12:06 |
| fullermd | pull is for updating one branch to contain what another does; think of it as 'mirror'. | 12:06 |
| fullermd | This is as opposed to merge, which brings over the revisions from the other branch, and prepares them as a merge into your branch (which may have additional changes not in the other) | 12:06 |
| fullermd | So, generally speaking, if you want to keep up a local mirror of another branch, you'd use 'pull'. If you're doing work separate from another branch, but want to keep bringing in its changes and combining them with yours, you'd use merge. | 12:08 |
| ttyType | ah ok, thanks | 12:09 |
| ttyType | very helpfulz | 12:10 |
| fullermd | I have my moments :) | 12:10 |
| ttyType | :D | 12:10 |
| ttyType | ok, i have a problem | 12:36 |
| ttyType | when i push to the server, it repushes all the files | 12:37 |
| ttyType | is there a way to make it only push what it needs? | 12:37 |
| fullermd | It generally does. What makes you think it's repushing everything? | 12:39 |
| ttyType | fullermd: because i moved 1 file into a folder, and when i ran push, it transferred 1530 or something | 12:41 |
| ttyType | oh...wait, it appears to be not doing that now | 12:42 |
| ttyType | i think it's because i have to do it once | 12:42 |
| ttyType | ok, we are all done :D | 12:46 |
| ttyType | and my script is working too :D http://pastebin.com/m23361a03 | 12:46 |
| === mrevell is now known as mrevell-lunch | ||
| === mrevell-lunch is now known as mrevell | ||
| ttyType | hi again | 14:40 |
| ttyType | an odd thing i have noticed - if i have modified my main repository, and i merge to it on a different computer, the next push i do UPLOADS all that stuff to the server i merged from | 14:42 |
| ttyType | :-S | 14:42 |
| vila | ttyType: s/i merge to it /I merge *from* it/ ? 'all that stuff' what do you mean ? | 14:44 |
| ttyType | vila: yeah, i mean merge from it. and by all that stuff, i mean what came down in the merge | 14:45 |
| ttyType | bzr for some reason sees a need to push it to the server | 14:45 |
| ttyType | even though it's definitely present on there, because i merged from there. | 14:46 |
| vila | bzr should push only the revisions that are not know on the remote server | 14:46 |
| ttyType | vila: that's what i thought | 14:46 |
| vila | if you commit locally, you create a new revisions, it should be pushed | 14:46 |
| ttyType | indeed | 14:46 |
| vila | so only that new revision is pushed, not the ones you merged | 14:46 |
| ttyType | i committed to the remote host from another computer, and merged that host's repository with the local one of another computer | 14:47 |
| ttyType | now, if i ask the other computer to do a push, it pushes everything that came down in the merge | 14:47 |
| ttyType | which takes ages | 14:47 |
| ttyType | if i do the push once, that seems to make it happy, and future pushes are only stuff the remote host DOESN'T have(like it should) | 14:48 |
| ttyType | but the push itself is insanely long, and seems to take up extra space on my server! | 14:48 |
| ttyType | s/server/remote host/ | 14:49 |
| ttyType | this is the sequence of steps i perform leading up to the push, which, if never done before, pushes everything: merge -> commit -> push | 14:50 |
| ttyType | should i be using a pull command in there somewhere?? | 14:51 |
| === CardinalFang is now known as statik-puppet | ||
| === statik-puppet is now known as CardinalFang | ||
| Keybuk | bzr: ERROR: File exists: '/srv/bazaar.launchpad.net/push-branches/00/00/17/d0/backup.bzr' | 15:14 |
| Keybuk | hmmm... ;) | 15:14 |
| beuno | Keybuk, yes, Launchpad isn't incredibly upgrade-friendly | 15:16 |
| beuno | lftp into it, and delete the backup.bzr | 15:16 |
| vila | jam: lp:~vila/bzr/gdfo-heads, I'll appreciate a reality check before going further and/or any talk about it and related impacts | 15:18 |
| jam | vila: downloading now | 15:19 |
| Keybuk | beuno: lftp into what? | 15:19 |
| beuno | Keybuk, bazaar.launchpad.net | 15:20 |
| Keybuk | beuno: with what protocol? | 15:20 |
| Keybuk | quest scott% lftp sftp://bazaar.launchpad.net | 15:20 |
| Keybuk | lftp bazaar.launchpad.net:~> cd /srv/bazaar.launchpad.net/push-branches/00/00/17/d0/backup.bzr | 15:20 |
| Keybuk | cd: Access failed: No such file: '/srv/bazaar.launchpad.net/push-branches/00/00/17/d0/backup.bzr' | 15:20 |
| jam | vila: it is still a 2-pass | 15:20 |
| jam | dict.fromkeys(nodes.keys()) == 1 pass | 15:20 |
| * beuno tries to remember the magic encantation | 15:20 | |
| beuno | mthaddon, around? | 15:21 |
| beuno | Peng_, ? | 15:21 |
| vila | jam: not really all I need is *a* size, I don't process the nodes | 15:22 |
| jam | 'dict.keys()" == 1 pass | 15:22 |
| jam | it has to walk all the nodes to get the names | 15:22 |
| beuno | rockstar`, do you remember how to lftp into Launchpad to delete a backup dir? | 15:22 |
| vila | jam: strictly speaking, yes, but there alternates implementations for C | 15:22 |
| vila | jam: alternatively I can use an attribute in each node, but doing that didn't change the perfs | 15:23 |
| jam | vila: was it actually faster? | 15:24 |
| jam | well, I guess you are competing with the C version | 15:24 |
| vila | jam: not really, I tried to compare to your python version, but mostly I wanted to avoid processing a node more than once (do it right) | 15:25 |
| jam | oh, and your impl is still a > 1 pass | 15:25 |
| jam | for gdfo | 15:25 |
| jam | since you walk all of "nodes.itervalues()" | 15:25 |
| jam | and *then* you walk all of pending + children | 15:25 |
| jam | still 2 pass | 15:25 |
| vila | jam: yes, but again, that could be pre-calculated for free at __init__ time if needed | 15:26 |
| jam | vila: we only "_find_gdfo" 1 time during init | 15:26 |
| vila | jam: right, but initializing pending can be done there without additional cost | 15:27 |
| jam | vila: so ultimately, optimizing _find_gdfo is not the best spent time, though it is interesting, I'll admit | 15:27 |
| jam | it is <800ms on OOo, and we are spending many *seconds* in heads() | 15:27 |
| jam | so I would focus on making heads() faster. | 15:27 |
| vila | jam: then have a look at heads then :) | 15:27 |
| jam | For _find_gdfo() as long as it is correct, I don't really mind | 15:27 |
| jam | Whatever method is reasonably fast, and easy to maintain. | 15:28 |
| jam | (I realize I'm guilty of it, too :) | 15:28 |
| jam | vila: does you're new version of heads() pass the whole test suite still? | 15:28 |
| jam | I'm also guessing that our >2 heads tests are a bit incomplete | 15:29 |
| vila | yes (the only failures are unrelated, one I mentioned while reviewing your patch, the other is about assertion (not mine :-P)) | 15:29 |
| jam | vila: KnownGraph has landed in bzr.dev, btw | 15:29 |
| jam | so I think the main difference here is the "min_gdfo" change | 15:30 |
| jam | and the fact that you don't track *which* parents have been seen at a node | 15:30 |
| === ttyType is now known as bizarrefish | ||
| vila | jam: my fear too about >2 heads (but in other parts of the code) | 15:30 |
| jam | just that it has been seen by someone | 15:30 |
| vila | time_graph.py says: 0.220s instead of the previous 7.350s, what does that represent in terms of code validation ? | 15:31 |
| jam | so... node.parent_keys can be None if the node is a ghost, I'm not sure that you would get that for a *candidate* node | 15:31 |
| abentley | jelmer: For some reason, your merge directive for lp:~jelmer/trac-launchpad-migrator/merge didn't cause a branch to be created. Do you mind sending me a copy of that email? | 15:31 |
| vila | jam: I added tests for it | 15:31 |
| vila | jam: but more importantly my question was did you leave parent_keys at None on purpose at __init__ time ? Or can we do that and get rid of the checks | 15:32 |
| jam | vila: you have to explicitly walk the list again to set them to something else | 15:33 |
| === bizarrefish is now known as leeguy92 | ||
| jam | I think it is *useful* to have a way to know that a node is a ghost rather than just has no parents | 15:33 |
| jam | as for "time_graph" | 15:34 |
| === leeguy92 is now known as TheFeIIow | ||
| jam | we do assert the value is the same as the slow path | 15:34 |
| jam | but only for the 'last' method | 15:34 |
| jam | just a sec | 15:34 |
| === TheFeIIow is now known as bizarrefish | ||
| jam | I'll run it again and see | 15:35 |
| jam | seems to still be correct for the bzr.dev revs | 15:36 |
| vila | jam: so, should I try a pyrex version or cancel the pyrex version ? or do you want more tests for corectness ? | 15:38 |
| jam | vila: so just adding "min_gdfo" to the pyrex version drops the time down to 0.137s | 15:40 |
| jam | from 0.453s | 15:40 |
| jam | (of the python version) | 15:40 |
| jelmer | abentley: sure | 15:40 |
| jam | so the pyrex version seems still a bit worthwhile | 15:40 |
| jelmer | abentley: I sent a unsigned version of that merge request earlier that was refused, perhaps that's relevant? | 15:41 |
| abentley | jelmer: Seems unlikely to be relevant. | 15:41 |
| vila | jam: Err, I don't understand what modification you made. Just min_gdfo into your heads() version ? | 15:42 |
| vila | jam: not the new algorithm ? | 15:42 |
| jam | vila: just adding the "if parent.gdfo < min_gdfo: skip" | 15:42 |
| jam | I sent you a patch | 15:43 |
| vila | jam: ok | 15:43 |
| jam | note that this doesn't seem to have a big impact on 'time bzr annotate' times, but it probably has a much more significant impact on the ancestry graph stuff | 15:44 |
| jam | since you know you have unique heads there | 15:45 |
| jam | I take that back. 11.2s => 10.1s for NEWS | 15:45 |
| jam | vila: nice catch | 15:45 |
| jam | the pure python version is 11.9s | 15:46 |
| jam | so slower than the existing pyrex version for NEWS | 15:47 |
| jam | though only just | 15:47 |
| vila | jam: and there are more tricks I can do in C... | 15:47 |
| jam | vila: btw, you should have "seen" be a *set* not a dict | 15:47 |
| jam | no reason to set True everywhere | 15:47 |
| jam | since you never set anything *but* true | 15:48 |
| vila | jam: nice catch ! :-) I did two implementations, the first one was buggy :) | 15:48 |
| jam | so thinking about using 'seen' rather than using the list of ancestors | 15:48 |
| vila | jam: and more complicated... | 15:48 |
| jam | let me think if I can come up with a way to break it | 15:48 |
| jam | It does make things simpler | 15:49 |
| jam | but I'm thinking of a case where you have 3-candidates that share some nodes, etc. | 15:49 |
| vila | jam: Yes please ! The huge perf difference makes me more nervous than happy so far :-) | 15:49 |
| jam | also, you don't use linear_dominators anymore | 15:49 |
| jam | which is... maybe unimportant? | 15:49 |
| vila | jam: I have no idea so far... it's just that I was cautious and could still be a useful optimization | 15:50 |
| jam | well, it is more important when you are walking more ancestry | 15:50 |
| jam | min_gdfo caps how far back you go, which is good | 15:50 |
| vila | The more I think about them the less reason I see to break the new algorithm | 15:51 |
| jam | I think it would be worthwhile to instrument to see how much linear_dominators, etc give us now that we have min_gdfo | 15:51 |
| mthaddon | beuno: hi | 15:51 |
| jam | and see if it is worthwhile | 15:51 |
| jam | I can say that pyrex is faster than your implementation, but I don't know *why* :) | 15:51 |
| jam | (something like 4x faster still... :) | 15:52 |
| vila | jam: and was about my implementation in pyrex ? ;P | 15:52 |
| vila | jam: I didn't try because: 1) I wanted some rough validation, 2) I've yet to deep dive in pyrex ;-) | 15:52 |
| jam | so... I think your algorithm is always *correct* but in some cases it walks more of the graph than it needs to | 15:53 |
| jam | maybe | 15:53 |
| jam | we may need to always walk to min_gdfo anyway | 15:53 |
| jam | in which case, it is minimal anyway | 15:53 |
| jam | yeah, I think we do | 15:54 |
| vila | the basic assumption is: a node can't appear in another node ancestry if they have the same gdfo | 15:54 |
| jam | because you have to walk until you know that your current tips could not be children of all heads | 15:54 |
| jam | and that is min_gdfo | 15:54 |
| vila | yes | 15:54 |
| jam | so even if 2 heads converge, if you have a third you have to walk until you know you don't have convergence | 15:54 |
| vila | jam: yes, at first I thought about soring pending by gdfo, but it's useless anyway, then is difference the best way to exclude the seen keys ? | 15:56 |
| vila | s/soring/sorting/ | 15:56 |
| === bizarrefish is now known as leeguy92 | ||
| === leeguy92 is now known as bizarrefish | ||
| jam | vila: so avoiding pop() only to push() is a 'niceity' that helps for very linear histories | 15:56 |
| jam | which is one of the heapreplace tricks | 15:57 |
| jam | otherwise you're right that sorting isn't particularly helpful | 15:57 |
| jam | seen() grows with the size of the graph | 15:57 |
| jam | while nodes.ancestor_of() doesn't | 15:57 |
| jam | not a big deal | 15:57 |
| jam | it is nice to use a structure that cleans up itself | 15:57 |
| jam | rather than having to track "_cleanup" | 15:57 |
| jam | (which grows with how much you walked anyway... :) | 15:57 |
| === Kissaki^0ff is now known as Kissaki | ||
| vila | jam: One C trick I have in mind is that I can malloc(size(graph)) and free() at the end, (or even alloca() if available) | 15:58 |
| jam | vila: easier to do in C than in Pyrex, since it wants to manage objects a bit differently | 15:59 |
| jam | I have that comment "# slab allocate" | 15:59 |
| vila | jam: since there is really no python involved in that method, may be C is relevant ? | 15:59 |
| jam | vila: however, realize that PyMalloc does slab allocation as well | 15:59 |
| jam | IIRC it does 256k allocations for objects < 256 bytes in size | 16:00 |
| vila | jam: ha, that's the meaning of slab... I should have ask :-/ | 16:01 |
| jam | vila: "a slab" is a large chunk | 16:01 |
| jam | http://www.google.com/search?q=define%3Aslab&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a | 16:01 |
| jam | at least in my head :) | 16:02 |
| vila | jam: hehe, my dictionary gave me at least 6 different meanings, you usage in context was far more enlighting ;) | 16:03 |
| jam | vila: sure, though realize that is how *I* use it, which may not conform to English standards :) | 16:04 |
| vila | jam: ok :) | 16:05 |
| jam | I think of a slab as something like a large block of concrete | 16:05 |
| jam | sort of the key being "bigger than normal" and "all one big piece" | 16:06 |
| jam | which seems to fit "slab allocate" | 16:06 |
| jam | http://en.wikipedia.org/wiki/Slab_allocation | 16:06 |
| jam | Actually, I think that fits just fine :) | 16:06 |
| jam | So I guess it is standard terminology | 16:07 |
| jam | And I wasn't just making it up | 16:07 |
| vila | lol, once again, I reinvented the wheel (16 years ago in that case ;-) | 16:07 |
| vila | this was, indeed, my silver bullet against fragmentation | 16:07 |
| fullermd | Well, if people would stop making square wheels, we'd stop having to reinvent them ;p | 16:08 |
| jam | fullermd: but I like the way they go "bounce bounce bounce" down the road | 16:08 |
| fullermd | That can be reproduced with round wheels and explosives... | 16:11 |
| vila | or sinusoidal roads | 16:11 |
| vila | jam: so, if the approach sounds conceptually sound, I'd like to continue with a pyrex version, submit that and then see about topo_sort | 16:14 |
| jam | vila: I think the approach is quite good | 16:15 |
| jam | I'm curious about linear dominators | 16:15 |
| vila | jam: You're damn right ! Gee, I almost forget | 16:15 |
| * vila still needs to optimize his revision belief system | 16:16 | |
| === gdmfsob is now known as mishok13 | ||
| vila | jam: turning seen into a set is... slower 8-/ | 16:33 |
| vila | jam: argh, no, bad measure (aanotate NEWS is too big to be relevant) | 16:34 |
| alaa_ | hey guys. So silly question. I want to set up a central repo on a server where everyone has accounts. The repo needs to have universal write permissions, right? If we're using bzr+ssh? | 16:55 |
| fullermd | alaa_: It'd have to have write to everybody one way or another. Group probably beats world... | 17:03 |
| alaa_ | fullermd: thanks. | 17:11 |
| === Muttley_ is now known as Muttley | ||
| Muttley | hi, I currently have a wordpress plugin in the bzr repository on launchpad. However I want to host the plugin with wordpress.org. Part of that is you have to use their subversion repository. I know I can use bzr to push my changes to SVN. However I'd still like to have them on Launchpad too | 17:23 |
| Muttley | is it possible to push them to both? | 17:23 |
| fullermd | Probably. You can use bzr-svn to push a mirror of the bzr branch into svn, and just keep using bzr and updating that mirror 'once in a while'. | 17:26 |
| fullermd | That's pretty simple. It gets more complex if there's intended to actually be development happening in svn at the same time, but... | 17:27 |
| Muttley | I suppose I could just push to svn when I have a new release | 17:27 |
| Muttley | so to switch between where I want to push to I just put that on the command line? e.g. bzr push lp:blahplugin | 17:28 |
| Muttley | or the svn address when i want to push to svn | 17:28 |
| Muttley | and it remember the last one? | 17:28 |
| fullermd | It remembers what you push --remember (or push when there isn't one rememeber yet). You could type it manually when you want to do the svn mirror, you could bang up a bzr or shell alias for it, you could have a separate branch that you use just to gateway... number of possibilities. | 17:30 |
| Muttley | cool, thanks | 17:31 |
| Muttley | I guess best option is to just use the svn when I'm doing a new release | 17:31 |
| Muttley | happy enough keeping currently development in launchpad, it's just a requirement by wordpress for hosting your plugin | 17:32 |
| fullermd | Oh, it probably wouldn't be too hard to just do it every few days, or whenever you've done a far bit of work. A shell/bzr alias would make it pretty easy; "bzr push ; bzr push-to-svn" | 17:32 |
| Muttley | fair enough | 17:33 |
| Muttley | thanks for the help | 17:33 |
| vila | jam: no list().extend() in pyrex ? | 18:10 |
| jam | vila: nope | 18:14 |
| jam | well, you can do 'foo.extend()' | 18:14 |
| vila | haa | 18:14 |
| jam | but no PyList_Extend | 18:14 |
| vila | and sets ? http://docs.python.org/c-api/set.html says new in 2.5 ? wtf ? | 18:15 |
| dash | before that, there was the 'sets' module | 18:15 |
| jam | I'm pretty sure it is 2.4 | 18:15 |
| vila | jam: ok, not a big deal, it's only for 'seen' anyway | 18:16 |
| === bizarrefish is now known as ttyType | ||
| jam | well, try it, see if it fails on PQM :) | 18:16 |
| vila | jam: hehe, *you* are my pyrex PQM ;-) | 18:17 |
| === ttyType is now known as bizarrefish | ||
| eydaimon | how can I show what files were modified in a particular rev? | 18:21 |
| fullermd | eydaimon: `bzr stat -cREV` | 18:22 |
| eydaimon | thanks | 18:22 |
| alaa_ | So looking for opinions. I want to keep a php website under bzr. So typically, apache would be serving the working tree. Is there anyway i can hide the .bzr dir? | 18:22 |
| eydaimon | why is it using -c for the rev instead of -r? | 18:22 |
| mario__ | alaa_: htaccess? :p | 18:23 |
| beuno | alaa_, you can use bzr-upload | 18:23 |
| fullermd | eydaimon: A lot of commands have a -c. -cREV is shorthand for -rparent:REV..REV. | 18:23 |
| eydaimon | ok, thanks | 18:23 |
| beuno | alaa_, which will just upload the files, not the repostory | 18:23 |
| eydaimon | fullermd: understanding helps me remember :) | 18:23 |
| fullermd | eydaimon: It doesn't make sense to say things like 'stat REV' or 'diff REV', since stat/diff/etc are for comparison between TWO revs. | 18:24 |
| fullermd | eydaimon: So since you often want to ask "what changed in X relative to its parent", -c gives a convenient shorthand. | 18:24 |
| alaa_ | beuno: yes, i've used that before. i don't know why i'm thinking i'd like to do a bzr up within the working tree that is being served, but without the branch itself...that doesn't seem possible, right? | 18:25 |
| eydaimon | fullermd: oh, I've been using just -r anyway, especially with diff. doesn't it default to the current head if nothing is specified? | 18:26 |
| fullermd | eydaimon: Well, for stat/diff, with no arg given, it compares the base rev of the WT (which usually means the head of the branch) against the current working files. | 18:26 |
| beuno | alaa_, right | 18:26 |
| fullermd | eydaimon: Doing "stat -r5" would compare rev 5 against the current tree. "stat -r5.." is the same as "stat -r5..-1", comparing 5 against the current head. | 18:27 |
| alaa_ | beuno: alright thanks. | 18:27 |
| alaa_ | mario__: thank you too | 18:28 |
| eydaimon | fullermd: thank you much for taking the tim eto explain. I appriciate it :) | 18:28 |
| === mario__ is now known as pygi | ||
| volodya | Can I somehow make bzr-svn not do this "analyzing repository layout" step on each pull? Making cache enabled caused it to try fetch something about every single revision, eating >500MB of disk space. | 18:59 |
| SamB | volodya: what version of SVN are you using? | 19:13 |
| SamB | how did you create your working tree? | 19:13 |
| SamB | and do you have commit access? | 19:13 |
| bizarrefish | hi people | 19:14 |
| volodya | good question. It is 1.5.1 locally. It is supposed to be 1.5 remotely (and I took extra painful steps to that effect), but I still got warning about "upgrade to 1.5", so maybe the repository is not upgradeted | 19:14 |
| volodya | I've used "bzr branch URL trunk" | 19:14 |
| volodya | I do have commit access. | 19:14 |
| SamB | volodya: did you do a dump and reload of the repository ? | 19:14 |
| volodya | no, that's why I suggest it's 1.4 still. | 19:15 |
| volodya | it's probably not gonna happen soonish | 19:15 |
| * SamB wonders if that can possibly be done incrementally | 19:15 | |
| volodya | unlikely, I'd guess. | 19:15 |
| SamB | I find it rather easy to imagine how that could be done | 19:16 |
| bizarrefish | i want to use bazaar to keep a personal repository for a few computers. i need to come up with a 'syncing' method, to synchronize each computer's repository with the master repository. | 19:17 |
| bizarrefish | so far i have this script for each machine: add -> commit -> merge with master repo -> commit -> push to master repo over sftp | 19:17 |
| alaa_ | Another question. I am using the upload plugin, and it is not preserving group ownership bits. Does anyone know why? | 19:17 |
| SamB | alaa_: not preserving them between what and what ? | 19:18 |
| volodya | SamB: but, do you expect 1.5 on server will stop bzr from analysing repository layout all over? | 19:18 |
| bizarrefish | the problem is, say if during the merge, a file came down, when i do the final "push", that file would be re-uploaded to the master | 19:18 |
| SamB | volodya: not sure | 19:18 |
| volodya | or just make it so fast as to be unimportant? | 19:18 |
| SamB | volodya: it's not the only way to get it tolerable, though | 19:19 |
| alaa_ | SamB: I need my files with www-data group and they are. but when i bzr upload them, it creates the files with my group. | 19:19 |
| volodya | alternatively, maybe those 1000 revisions it analyzes can be cached -- without grabbing metadata of all 250K of revisions | 19:19 |
| SamB | jelmer: is it possible to add a "bzr help svn-faq" topic? | 19:20 |
| SamB | jelmer: or perhaps just include the FAQ's web address in "bzr help svn" ? | 19:20 |
| === AnMaster is now known as Because | ||
| === Because is now known as AnMaster | ||
| volodya | SamB: FWIW, the bzr svn faq is unhelpful. Unless there is more than one FAQ | 19:23 |
| jelmer | volodya: what's the problem exactly? | 19:25 |
| jelmer | SamB: Perhaps a help topic would be useful I guess, though it'd be annoying to keep up to date | 19:26 |
| volodya | jelmer: I've done "bzr branch URL trunk", and I had no-cache set for SVN repository at this time. Now, 'bzr pull' spends a minute analysing reposiotry layout. If I try to enable caching back, bzr pull appears to try get metainfo for every revision, which takes huge time. | 19:27 |
| volodya | And in my earlier tries, caching of metainfo ate 500MB, and were not even half-way through | 19:27 |
| jelmer | volodya: what version of bzr-svn? | 19:27 |
| jelmer | volodya: do you have python-tdb installed? | 19:27 |
| volodya | Bazaar (bzr) 1.15. I guess latest release in ppa. | 19:28 |
| volodya | I don't have python-tdb | 19:28 |
| huf | hi. how do i debug errors like this: [Wed Jun 17 18:28:53 2009] [warn] mod_fcgid: read data timeout in 40 seconds | 19:30 |
| huf | i'm running a bazaar server with apache + mod_fcgid + a bzr-smart.py | 19:30 |
| jelmer | volodya: I would recommend trying with python-tdb installed, that should reduce the size of the cache | 19:30 |
| huf | and this python script seems to be dying hard | 19:30 |
| jelmer | volodya: Do you have a slow svn server perhaps? The only thing that's done to guess the repository layout is basically 'svn log -v <url> --limit 300' | 19:31 |
| volodya | jelmer: it appears to fetch around 2000 revisions; the server is across the globe. Why can't bzr remember guessed layout? | 19:34 |
| jelmer | volodya: newer versions do | 19:36 |
| volodya | jelmer: I assume those versions not in PPA yet? | 19:37 |
| jelmer | volodya: actually, only development snapshots (also reduces the number of revisions that is fetched to 300) | 19:39 |
| jelmer | volodya: the remembered guessed layout is used now, if the location you're pulling from matches that layout | 19:39 |
| jelmer | volodya: you can set the layout to use explicitly and it won't try to guess it | 19:40 |
| jelmer | volodya: even in 0.6.1 (which is what's in PPA I think) | 19:40 |
| volodya | jelmer: command line option or config file? | 19:40 |
| alaa_ | Is it safe to expose the .bzr of a lightweight checkout on the web? I wouldn't want anybody to see the code or the history. | 19:42 |
| jelmer | volodya: e.g. "layout = trunk0" in the right section in ~/.bazaar/subversion.conf | 19:42 |
| volodya | jelmer: where are possible values are documented? | 19:45 |
| jelmer | volodya: "bzr help svn-layout" has some explanation | 19:46 |
| jelmer | volodya: actually, "bzr svn-layout" may be a better way to set this value | 19:46 |
| jelmer | volodya: but at the moment it's readonly | 19:46 |
| volodya | jelmer: thanks. Putting "branches = ..." in the subversion.conf stops guessing of layout from happening | 19:49 |
| volodya | I'll now trying using bzr for real. | 19:50 |
| huf | is there some place a bazaar smart server would log errors? | 19:50 |
| jelmer | volodya: is this a very large repository? It seems quite unusual to have such a large cache file | 19:57 |
| jelmer | volodya: e.g. the cache file for OpenOffice.org (270k revisions, 75k files in each tree) is "only" 380Mb | 19:58 |
| volodya | jelmer: there's 250K revisions, it's hard to estimate the number of files. | 19:59 |
| huf | what do you people do when a bazaar repo just shits itself and you can no longer commit to it? | 20:00 |
| volodya | jelmer: but given that linux tree is just one of the components kept there, I'd imagine the total number of files to be fairly high | 20:02 |
| jelmer | huf: why would you no longer be able to commit? | 20:02 |
| huf | the only solution i know is to ssh to the server, remove the dir and push the whole thing from another mirror) | 20:02 |
| huf | jelmer: how should i know? the smart server dies hard, and all i get back is a useless error msg | 20:02 |
| huf | but even that is from the fcgi level, so it's just a timeout | 20:02 |
| huf | we run into this once every few months | 20:03 |
| fullermd | Never had such a thing happen. But have you tried 'check'ing it? | 20:04 |
| huf | bzr: ERROR: Generic bzr smart protocol error: Invalid http response for http://host/branch/.bzr/smart: Unable to handle http code 500: Internal Server Error | 20:04 |
| huf | bzr check? on the server or remotely? | 20:04 |
| fullermd | On the server, since remotely things are being questionable. | 20:05 |
| jelmer | huf: nothing about the actual error in the apache logs? | 20:05 |
| fullermd | Cut down the number of variables. | 20:05 |
| huf | jelmer: nope. just that fcgi timed out and got no headers | 20:05 |
| fullermd | How big a repo are we talking about? | 20:05 |
| huf | 25M | 20:06 |
| huf | so pretty small | 20:06 |
| fullermd | So, somewhere between disk and bzr+http client, things are going screwy. Doing a 'check' on the server would give you a pretty good guess as to whether the problem is in the branch/repo there. | 20:07 |
| fullermd | If that's good, I'd try doing something with sftp:// or [non-bzr+]http://. Then try bzr+ssh (to try the SS without the Apache/FCGI layers). Add on layers until it dies. | 20:07 |
| huf | if i rm the entire dir on the server and re-push it from a local branch, it works again | 20:09 |
| huf | but i'm running the check now | 20:09 |
| huf | check didnt report any errors | 20:15 |
| fullermd | 'k. So the branch/repo is itself probably fine. | 20:17 |
| fullermd | What dies over the SS? push, pull, commit, branch, anything you do? | 20:18 |
| huf | fullermd: commit and push died, missing and up worked | 21:05 |
| fullermd | Hm. So, maybe the problem is just things that write? | 21:08 |
| === omichael is now known as omichael_afk | ||
| fullermd | Try a push over bzr+ssh, see if cutting out the CGI layer does anything. | 21:09 |
| GPHemsley | Is there a specific format for tags? | 21:15 |
| jelmer | GPHemsley: all modern formats support tags | 21:19 |
| GPHemsley | I meant for tag names | 21:19 |
| jelmer | GPHemsley: ah | 21:20 |
| jelmer | GPHemsley: there are some conventions in use | 21:20 |
| GPHemsley | hmm... can you not push tags? | 21:20 |
| jelmer | GPHemsley: The two most common ones seem to be using the version number as the tag or using PROJECT-VERSION | 21:20 |
| jelmer | GPHemsley: "bzr push" will push tags | 21:20 |
| GPHemsley | even if there aren't any new revisions? | 21:20 |
| GPHemsley | because that's what it says | 21:21 |
| GPHemsley | it doesn't mentiont ags | 21:21 |
| GPHemsley | tags | 21:21 |
| jelmer | the message could be clearer | 21:21 |
| jelmer | it did actually push the tags | 21:21 |
| GPHemsley | OK, thanks | 21:21 |
| GPHemsley | Is there a way to see them in Loggerhead? | 21:22 |
| jelmer | GPHemsley: afaik not yet | 21:22 |
| GPHemsley | k | 21:22 |
| GPHemsley | jelmer: BTW, are you in charge of bzr-svn? | 21:23 |
| jelmer | GPHemsley: yeah | 21:23 |
| GPHemsley | or, subvertpy? | 21:23 |
| * GPHemsley forgets | 21:23 | |
| GPHemsley | because I haven't been able to get it set up | 21:24 |
| GPHemsley | subvertpy causes trouble | 21:24 |
| jelmer | GPHemsley: in what way? | 21:24 |
| GPHemsley | it doesn't compile | 21:25 |
| GPHemsley | no matter what way I try to install it | 21:25 |
| jelmer | GPHemsley: what platform are you on? | 21:28 |
| jelmer | what errors do you get? | 21:28 |
| GPHemsley | Mac OS X 10.4 | 21:28 |
| GPHemsley | oh | 21:33 |
| GPHemsley | um | 21:33 |
| GPHemsley | hang on | 21:33 |
| GPHemsley | jelmer: Exception: Subversion development files not found. Please set SVN_PREFIX or (SVN_LIBRARY_PATH and SVN_HEADER_PATH) environment variable. | 21:35 |
| jelmer | GPHemsley: do you have the subversion development libraries installed? | 21:35 |
| GPHemsley | this is where I was getting into trouble | 21:35 |
| GPHemsley | they're somewhere | 21:35 |
| GPHemsley | but setting SVN_PREFIX via export doesn't do anything | 21:35 |
| GPHemsley | and/or no, I don't, and I don't know where to get them | 21:37 |
| GPHemsley | I've been through this a number of times that I don't even remember anymore | 21:37 |
| jelmer | I don't know much about Mac OS X so I can only give you some generic pointers | 21:37 |
| GPHemsley | ah, OK | 21:37 |
| GPHemsley | also, I'm using Python 2.5 | 21:38 |
| jelmer | On Linux the distributions usually provide packages that include the Subversion development files, not sure if there's anything like that on Mac OS X | 21:38 |
| jelmer | For Windows, you can download the headers from the Subversion web site | 21:38 |
| GPHemsley | fink and MacPorts are the two main ones, I think | 21:38 |
| GPHemsley | but I can't seem to find the right dev files | 21:38 |
| jelmer | I think one of them was also packaging bzr-svn | 21:38 |
| GPHemsley | it's possible, but even that wasn't installing because it couldn't compile | 21:39 |
| GPHemsley | I think that's what I tried at first, using macports | 21:39 |
| GPHemsley | but that installation errored out | 21:39 |
| GPHemsley | so I tried to do things manually, with no more luck | 21:39 |
| jelmer | GPHemsley: Sorry, I'm afraid I can't provide much help here. This sounds like it is Mac OS X-specific. :-( | 21:42 |
| GPHemsley | Yeah, I think so | 21:42 |
| GPHemsley | thanks, though | 21:42 |
| jelmer | I know there's various people using bzr-svn on Mac OS X | 21:42 |
| GPHemsley | I'm sure... but, for one thing, how many of them are on 10.4? | 21:43 |
| GPHemsley | most are probably on 10.5 | 21:43 |
| jelmer | Some are on 10.4 | 21:44 |
| GPHemsley | ah, well, then IDK | 21:46 |
| GPHemsley | Exported releases do not contain any bzr information, correct? | 22:03 |
| === phinze_ is now known as phinze | ||
| === ttyType is now known as bizarrefish | ||
| bizarrefish | hi all | 22:33 |
| bizarrefish | when i run "bzr push", it complains about not specifying a push location, how do i specify it? | 22:33 |
| bizarrefish | is there a config file somewhere? | 22:33 |
| fullermd | Just specify it on the command line. | 22:34 |
| bizarrefish | i know i can just provide it like "bzr push sftp://someaddr/apath", but for some reason, that makes it PUSH the whole repository to the place i just branched it from :S | 22:35 |
| beuno | bizarrefish, bzr push LOCATION | 22:35 |
| fullermd | Well, pushing to the location you specify is what it's supposed to do ;p | 22:35 |
| bizarrefish | fullermd: but how can i make it just push changes? | 22:35 |
| bizarrefish | rather than update the whole repo | 22:36 |
| bizarrefish | the weird thing is that all subsequent pushes do just that | 22:36 |
| bizarrefish | but the first push the branch ever does, pushes the whole thing, and that's.....annoying | 22:36 |
| fullermd | If it's pushing the whole history, then you're pointing at at a location that doesn't already have a repo with the history. | 22:36 |
| bizarrefish | fullermd: but i used that location to do bzr branch. | 22:37 |
| bizarrefish | that's how i got hold of the local repo in the first place | 22:37 |
| awilkins | Does SFTP still try packing once in a while? | 22:39 |
| fullermd | Well, if you're just pushing back to the same location, you could shortcut the command line with 'bzr push :parent'... | 22:39 |
| fullermd | It's certainly _possible_ there's a bug that causes it to push the whole history into a repository that already contains it. It seems unlikely though. | 22:40 |
| bizarrefish | ah, ok i have got it working.....somehow | 22:40 |
| bizarrefish | the trick seems to be to do a push RIGHT after you create the branch | 22:40 |
| bizarrefish | no adding, commiting, merging beforehand | 22:41 |
| bizarrefish | then you can do all the adding, committing etc... you like, and the push works | 22:41 |
| * fullermd is pretty sure something different is going on than you think. | 22:41 | |
| bizarrefish | fullermd: so am i | 22:41 |
| bizarrefish | there is another interesting problem though - i have broken off a few big transfers in the past, and these half-revisions appear to be taking up some space on the filesystem | 22:43 |
| bizarrefish | i know git has a prune thingy for this | 22:44 |
| bizarrefish | is there an equiv for bzr@? | 22:44 |
| bizarrefish | *bzr? | 22:44 |
| === omichael_afk is now known as omichael | ||
| fullermd | Not builtin, no. | 22:47 |
| bizarrefish | right, ok.... | 22:47 |
| fullermd | In-progress uploads go into a staging dir somewhere and can probably be deleted manually. Not sure, I've never had it happen. | 22:47 |
| fullermd | Presumably the smart server will clean up stuff from broken connections, though that doesn't help when you're using dumb protocols. | 22:48 |
| bizarrefish | fullermd: hmm, you are right, something different WAS going on | 22:50 |
| bizarrefish | it seems i was simply creating the branch with a different hostname to which i was doing the push | 22:51 |
| bizarrefish | even though they both point to the same host | 22:51 |
| fullermd | That hardly seems that it would matter. | 22:52 |
| bizarrefish | well, i'm giving them the same now, and it's not doing the peculiar "push everything" thing | 22:52 |
| bizarrefish | fullermd: you are right again, i am incorrect | 22:55 |
| bizarrefish | i just tried adding a file to the local repo, committing, then pushing to the server, and it's deciding to push everything there | 22:56 |
| fullermd | What makes you think it's pushing everything? | 22:56 |
| bizarrefish | it seems it only refrains from pushing everything as long as the local repo is the same as the remote repo | 22:56 |
| bizarrefish | fullermd: because i added an empty file, and it's transferring dozens of megabytes | 22:57 |
| bizarrefish | the whole thing is about 100MB at the moment | 22:57 |
| awilkins | How big is the repository? | 22:57 |
| awilkins | Is it because you are using SFTP? | 22:57 |
| bizarrefish | awilkins: that would cause it? | 22:57 |
| fullermd | Check the repository after the push is finished, I suspect you'll find one new smallish pack, not a new huge one. | 22:57 |
| awilkins | Can you use the smart server? If you have SFTP access you are likely to also have SSH access? Can you get bzr installed on server? | 22:58 |
| fullermd | It may well have to transfer a very large amount of information over a dumb protocol to figure out what it need to push. And I think there's some bugorother that makes them worse than they have to be. | 22:58 |
| bizarrefish | awilkins: the server itself has 32MB of RAM | 22:59 |
| bizarrefish | fullermd: i see | 22:59 |
| bizarrefish | :-/ | 22:59 |
| awilkins | Well, that could be awward | 22:59 |
| bizarrefish | indeed | 22:59 |
| awilkins | wakward | 22:59 |
| awilkins | aGah, typing. Tired. | 22:59 |
| fullermd | It has WHAT? | 22:59 |
| bizarrefish | the server is about 1 x 2.5 inches big | 22:59 |
| bizarrefish | it has a 1GB flash drive for a filesystem, and a 150MHz CPU | 23:00 |
| awilkins | It's one of those wallplug things with a HD attached, yes? | 23:00 |
| bizarrefish | nah, they don't make them for the UK | 23:00 |
| bizarrefish | and those plug thingies have WAY more grunt than this | 23:00 |
| awilkins | Router with a USB port? | 23:00 |
| bizarrefish | (also more expensive) | 23:00 |
| bizarrefish | this doohicky: http://bifferos.bizhat.com/ | 23:01 |
| bizarrefish | £30 | 23:01 |
| * bizarrefish couldn't let that pass | 23:01 | |
| bizarrefish | alas, it's x86, so it chomps 1 watt | 23:01 |
| bizarrefish | for only 50bogomips | 23:01 |
| bizarrefish | it's just sitting in my lounge at the moment, being warm | 23:03 |
| * bizarrefish mutters something about ARM supremacy | 23:03 | |
| bizarrefish | aaanyway, i gotta be up early tomorrow. 'nite all. | 23:04 |
| === Kissaki is now known as Kissaki^0ff | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!