| dash | jelmer: http://yellow5.com/pokey/archive/pokey80_3.gif | 00:19 |
|---|---|---|
| lifeless | james_w`: around? | 00:43 |
| TDJACR | Bazaar just took up 765 MB of ram | 00:44 |
| spiv | TDJACR: you're adding some large files to bzr? | 00:48 |
| === james_w` is now known as james_w | ||
| james_w | lifeless: briefly | 01:03 |
| lifeless | nvm, filed a bug | 01:04 |
| TDJACR | spiv: No, I branched launchpad | 01:09 |
| spiv | TDJACR: oh, right. That's a very large branch, we've been working on improving the memory use in bzr's trunk | 01:11 |
| spiv | TDJACR: bzr's trunk plus a couple of patches that will land shortly uses roughly 2/3rds of the memory of 2.0.1 I believe, and that should keep improving as we work towards 2.1 | 01:13 |
| spiv | TDJACR: (there's ~65000 revisions in Launchpad's history last time I checked, and about 7000 files!) | 01:15 |
| spiv | TDJACR: so, basically, known problem, but we're working on it | 01:16 |
| lifeless | vila: buildbot trunk has my subunit patch | 01:20 |
| igc | back | 01:59 |
| spiv | lifeless: so, how far away is a proper fix for the --subunit issue that's preventing PQM from rejecting test failures? | 02:48 |
| spiv | lifeless: I'm wondering if we should temporarily remove the --subunit option until we figure out a better fix. | 02:49 |
| lifeless | spiv: I'm hoping to start on the cleanup this avo | 02:49 |
| lifeless | just want to get one of the dx ppa builds up first | 02:49 |
| lifeless | still solving teething problems | 02:50 |
| spiv | lifeless: cool, "this arvo" is a good enough answer for me. | 02:50 |
| spiv | lifeless: mind if I assign the bzr bug to you? | 02:51 |
| * spiv updates the bug description | 02:54 | |
| lifeless | spiv: uhm | 02:55 |
| lifeless | spiv: I don't particularly care, but its a different bug I think | 02:55 |
| lifeless | spiv: and its not my top priority, I'm just trying to squeeze it it | 02:55 |
| lifeless | *in* | 02:55 |
| spiv | Hmm. | 02:56 |
| lifeless | right now I don't recall how messy the badly mapped things are | 02:57 |
| lifeless | basically need to un-messy them and get detection out of the TestResult and back to the TestCase | 02:57 |
| lifeless | it might be an hour, it might be a day | 02:57 |
| spiv | and then we'll need the subunit in the pqm updated? | 02:59 |
| lifeless | possibly. I won't try to depend on the latest, but I may have to. | 03:00 |
| lifeless | have a look at the code ;) | 03:00 |
| spiv | Ok. I think I will temporarily disable the --subunit option then. The niftiness isn't quite worth the discomfort, and it'll be easy to turn back on when it's sorted. | 03:00 |
| spiv | Thanks. | 03:01 |
| * spiv has a late lunch | 04:33 | |
| lifeless | spiv: subunit doesn't need improving | 04:43 |
| lifeless | spiv: I've tried to correct this meme in the bug, but its not seeming to stick, so I'm coming direct :) | 04:43 |
| spiv | lifeless: please feel free to edit the description and summary directly :P | 04:44 |
| spiv | lifeless: I wrote the most recent comment before seeing yours about it not being subunit that needs improving, though. | 04:45 |
| lifeless | spiv: kk | 04:45 |
| lifeless | spiv: I'm not stressed, I just want to fix the meme :) | 04:45 |
| _Andrew | hi | 05:06 |
| _Andrew | I'm getting the error "These branches have diverged. Use the missing command to see how." | 05:07 |
| _Andrew | What's the "missing" command and if it's missing how do I use it? | 05:07 |
| spiv | "bzr missing" | 05:08 |
| _Andrew | ah, I was doing it wrong.. --missing | 05:08 |
| spiv | And you'll probably want to use "bzr merge" rather than "bzr pull" to combine the different changes made on the two branches. | 05:08 |
| _Andrew | ah ok | 05:09 |
| _Andrew | Yes that's working | 05:09 |
| _Andrew | Since I'm already here could you tell me what "M*" means? It's that a conflicted merge? | 05:10 |
| spiv | See "bzr help status-flags" | 05:10 |
| spiv | M means the contents of the file have changed (been modified), * means the execute bit changed. | 05:11 |
| _Andrew | ok thanks for the help! :) | 05:12 |
| _Andrew | Actually I have another question, sorry. Say I have branch A with a file and I want to merge changes from branch B, but I don't want branch A to merge changes from a specific file, how do I do that? | 05:35 |
| spiv | _Andrew: You can do "bzr merge path/to/branch-A/some/file" | 05:52 |
| spiv | (IIRC) | 05:52 |
| spiv | _Andrew: note that cherrypicking a change like that won't be tracked by bzr though, i.e. bzr won't remember that you've done that merge (unlike most merges), so it might cause conflicts next time you merge from that branch. | 05:54 |
| _Andrew | Can't you just lock the file or something? | 05:56 |
| _Andrew | It's an image and I don't want the images to change | 05:56 |
| spiv | _Andrew: oh, you want to ignore changes to a specific file | 06:36 |
| spiv | _Andrew: you can do "bzr revert that_file" after the merge | 06:37 |
| spiv | (sorry, I misread your question) | 06:37 |
| spiv | _Andrew: in general there's no way to say "only these parts of this branch should change". You can split a project into multiple branches, though, which may help. | 06:38 |
| KhaZ_ | Question: for shared repositories to work, do you need to have them be subdirectories in the shared parents root? Or could I have them (on Windows for instance) as far apart as on different drives? | 06:45 |
| spiv | KhaZ_: you need the branches to be inside the shared repository directory, but you can have the working tree(s) for those branches anywhere. | 06:47 |
| KhaZ_ | Fascinating. I never thought about separating the branch from the working dir, but I suppose that's always been the case; I just assumed they were one in the same. | 06:49 |
| spiv | [Branches inside a shared repository are tiny; the things that take up space are the history (which is inside the shared repo) and the working copy that you can edit (which does not have to be co-located with the branch)] | 06:49 |
| spiv | If you do "bzr init-repo --no-trees" (or later "bzr reconfigure --with-no-trees"), then branches in that repo by default will have no working tree. You can then do "bzr checkout /path/to/repo/branch" from any directory you like. | 06:50 |
| spiv | Er, | 06:51 |
| spiv | "bzr checkout --lightweight ..." | 06:51 |
| spiv | The --lightweight is important, otherwise it will make a full copy of the history rather than use the branch's repo :) | 06:51 |
| KhaZ_ | Interesting. So say I currently have two repos that (I believe) are 'standalone', but they really are just clones of each other that I do work in. I can use reconfigure to change it to a shared repository scheme? | 06:52 |
| spiv | Yes, I believe you can do "bzr reconfigure --use-shared", although I don't know the precise details. | 06:53 |
| KhaZ_ | Hrmm, I'll have to read into that. Do shared repo's have any other benefit besides space saving? | 06:54 |
| spiv | Just space-saving, really. | 06:54 |
| spiv | (Although that can in turn lead to speed improvements) | 06:54 |
| dash | well branching is quicker inside it because you don't have to copy as much | 06:54 |
| dash | right yes | 06:55 |
| spiv | e.g. the time to do "bzr branch" will be much much faster, as dash says :) | 06:55 |
| KhaZ_ | Right. Hrmm, maybe I'll put it on the backburner then... Don't do much branching luckily. :) Still, good to know. | 06:56 |
| spiv | KhaZ_: If you have two branches inside a parent, and you cd to that parent and do "bzr init-repo ." then you should be able to cd to each branch and do "bzr reconfigure --use-shared". | 06:56 |
| spiv | s/inside a parent/inside a parent directory/ | 06:57 |
| KhaZ_ | But literally the parent - not just any common ancestor, yeah? | 06:58 |
| KhaZ_ | I currently have two paths that could be shared, but they're basically about four levels apart from each other (I'm versioning the contents of my work (Perforce) repo, but source code only, is why I ask). | 06:58 |
| KhaZ_ | (On a side note, shazbot is sourceforge's git cloning slow!) | 06:59 |
| spiv | I'm not sure how fussy bzr reconfigure is. | 07:00 |
| KhaZ_ | Interesting. I might try that then. | 07:00 |
| spiv | I suppose you could always make the repo in the immediate parent and then after the reconfigures move the .bzr of the repo up a few levels. | 07:01 |
| vila | hi all | 07:01 |
| spiv | Hey vila | 07:02 |
| spiv | vila: I've disabled --subunit in make check for now until lifeless figures out what needs to be done to make it do what we need | 07:03 |
| spiv | vila: so hopefully babune will stay nice and green from now on | 07:03 |
| vila | spiv: I've read that and lifeless replies and announce that it will work on it on the bzr side, thanks | 07:04 |
| vila | spiv: well, babune has a bad flu since a couple of weeks with the leaking tests and then the terminal width saga took me a while to figure, so it's good to know *that* failure source is closed :-) | 07:06 |
| lifeless | hi vila | 07:22 |
| jelmer | what's this babune thing people are talking about? | 07:59 |
| igc | jelmer: buildbot test server that vila runs | 07:59 |
| jelmer | ah, thanks | 07:59 |
| igc | hi vila | 07:59 |
| vila | hi Ian ! | 08:00 |
| vila | jelmer: BAzaar BUild botNEt | 08:00 |
| jelmer | :-) | 08:01 |
| vila | jelmer: https://launchpad.net/bzr-buildbot-net and http://babune.ladeuil.net:26862/ for the full monty | 08:02 |
| * igc dinner - night all | 08:03 | |
| jelmer | g'night Ian | 08:05 |
| cpf_ | Just a quick question, how do I install the bzr explorer (and run it?) | 09:09 |
| cpf_ | I executed the setup.py install, tried "bzr explorer", but the explorer plugin cannot be loaded... | 09:09 |
| === weigon__ is now known as weigon | ||
| cpf_ | Ok, reinstalling qbzr fixed the issue ^^ | 09:32 |
| vila | cpf_: what OS/versions are you using ? | 09:33 |
| cpf_ | vila: debian, python 2.5.4, bzr 2.0.1 | 09:37 |
| vila | cpf_: ok, so you're installing the plugins system-wide and not in your ~/.bazaar directory ? | 09:38 |
| vila | cpf_: and when you said "but the explorer plugin cannot be loaded" did you get a proper message telling you about an unmet dependency on qbzr or just a "can't load plugin" kind of message ? | 09:39 |
| cpf_ | vila: Uh, 10:32 < cpf_> Ok, reinstalling qbzr fixed the issue ^^ | 09:42 |
| cpf_ | I ended up installing in ~/.bazaar/plugins, but it's all the same now, it works like a charm XD | 09:43 |
| cpf_ | vila: Oh, and no message about an unmet dependency. Just: "Unable to load plugin 'explorer' from '/usr/lib/python2.5/site-packages/bzrlib/plugins'" (When it was installed globally) | 09:45 |
| vila | cpf_: ha, that was my fear, hence my question | 09:45 |
| vila | cpf_: can you file a bug against bzr-explorer on lp mentioning your versions so that a better error message can be issued | 09:46 |
| vila | and by the way, what made you suspect qbzr ? | 09:46 |
| cpf_ | http://doc.bazaar-vcs.org/explorer/en/install-source.html << End of page | 09:46 |
| cpf_ | I had all the rest... | 09:46 |
| cpf_ | Thought I had qbzr already (used to have it at least) | 09:46 |
| cpf_ | Must've lost it somewhere xD | 09:46 |
| vila | either bzr-explorer setup.py or __init__.py should report it more nicely IMHO :-/ | 09:48 |
| cpf_ | I agree, but __init__.py looks scary :( | 09:49 |
| gioele | Can BZR_PLUGIN_PATH point directly to a directory that contains a single plugin or should it point to a directory that contains other directories with plugins (like ~/.bazaar/plugins)? | 10:34 |
| hmeland | The latter. | 10:35 |
| gioele | :( | 10:35 |
| hmeland | Maybe you can trick it with some symlinks? | 10:36 |
| lifeless | vila: what do you think of allowing a path to name a plugin | 10:37 |
| gioele | I think I'll have to. I am developing a plugin. Right now the development is in a subdir of ~/.bazaar/plugins/. But I'd like to move it to another local repo (point 1) and use the pipelines plugin that creates a serires of directories/branch (point 2). | 10:38 |
| lifeless | e.g/ foo:pluginname@directory | 10:38 |
| vila | lifeless: I think it's an inferior solution if you want to test a specific version of a plugin *because* that plugin may depend on other plugins | 10:39 |
| lifeless | vila: well yes, but its a recurring request | 10:39 |
| vila | so I think it's better to create a dedicated directory for the tests where you put symlinks to whatever plugins you want | 10:39 |
| vila | lifeless: true | 10:39 |
| vila | may be we should add two command lines options: --plugins and --single-plugin ? | 10:39 |
| vila | adding the command-line option is more or less missing right now (I use BZR_PLUGIN_PATH=-site all the time and far more typing than --plugins=-site | 10:40 |
| lifeless | vila: I'd rather come up with a good syntax to specify in the path | 10:40 |
| vila | lifeless: like a leading-but-otherwise-forbidden char ? | 10:41 |
| gioele | Maybe the semantics of BZR_PLUGIN_PATH could be changed to mean: if the directory itself does not contain a module at the top level, then it act like it does not. Otherwise, if the BZR_PLUGIN_PATH contains a plugin in the top level, then load that without recursion | 10:41 |
| lifeless | gioele: can't do that | 10:41 |
| vila | gioele: 8-( | 10:41 |
| lifeless | need a plugin name | 10:41 |
| gioele | lifeless: why? | 10:42 |
| gioele | (btw I cannot find a complete example on the use of BZR_PLUGIN_PATH in the documentation, just quick references) | 10:42 |
| lifeless | gioele: because plugins get loaded into bzrlib.plugins.NAME | 10:42 |
| vila | gioele: there is, wait | 10:43 |
| lifeless | gioele: which makes them regular python packages/modules rather than 'different' things | 10:43 |
| gioele | lifeless: can't you say "load the python module that lies in exactly that directory"? | 10:44 |
| lifeless | gioele: load it as what | 10:44 |
| lifeless | what would its name be? | 10:44 |
| vila | gioele: http://doc.bazaar-vcs.org/bzr.2.1.0b1/en/user-reference/index.html?highlight=bzr_plugin_path#bzr-plugin-path | 10:44 |
| gioele | lifeless: basename `dirname $path` | 10:45 |
| bialix | hi all | 10:45 |
| vila | lifeless: +plugin:<path> ? | 10:45 |
| lifeless | gioele: that would be wrong far too often | 10:45 |
| lifeless | vila: something; too tired to thing through consequences; my sketch was the one with @ before | 10:46 |
| vila | hmm, using ':' is bad here :-/ | 10:46 |
| gioele | vila: oh, I was looking into the dev documentation. Thanks for the link | 10:46 |
| vila | oh, that was a skecth, sorry, didn't realize | 10:46 |
| vila | hmm, so you could override the dir name, right, that should be optional though, but I see the point | 10:47 |
| vila | lifeless: @ is a good idea and since '+' is already mandatory, I think +[name]@directory will do fine, but the main problem I can see is that it's not a real PATH spec and will need special handling | 10:51 |
| lifeless | vila: whats the + for? | 10:52 |
| vila | +/- is used to add or remove from BPP (BZR_PLUGIN_PATH), see url abov | 10:53 |
| lifeless | vila: + isn't needed then | 10:53 |
| lifeless | vila: unless soeone wants to edit the path | 10:53 |
| vila | by default you start with +user:+core:+site so if you say BPP=-site you ends up with +core | 10:53 |
| vila | because +user is the default value for BPP | 10:54 |
| vila | it's needed to identify magic values | 10:54 |
| lifeless | I dispute that | 10:54 |
| lifeless | its just code | 10:54 |
| vila | oh, you mean when using @ | 10:54 |
| vila | lifeless: look at the tests: | 10:56 |
| vila | ['myplugin'], ['myplugin', '-user', '-core', '-site'] | 10:56 |
| vila | ['myplugin', '+core', '+site', '+user'] | 10:57 |
| vila | the former is myplugin only, the later is myplugin first | 10:57 |
| lifeless | vila: I don't understand your point | 10:57 |
| vila | lifeless: what are you disputing (I may misunderstand that :-) ? | 10:58 |
| lifeless | that + is needed to use @ as I propose it be used | 10:58 |
| vila | yes, my latest remark, + is not needed for @ | 10:58 |
| lifeless | well, your latest remark was telling me tolook at the tests | 10:59 |
| vila | because - makes no sense | 10:59 |
| lifeless | so, you can understand my confusion | 10:59 |
| vila | lifeless: sorry, I meant my remark after you said 'I dispute that' | 10:59 |
| lifeless | so, I don't understand your point *after* that remark | 11:00 |
| lifeless | why are you telling me to look at the tests | 11:00 |
| === rml_ is now known as rml | ||
| lifeless | what do I have wrong | 11:00 |
| vila | lifeless: forget it then, I thought you disagreed with 'you mean when using @' | 11:00 |
| lifeless | vila: I didn't ssay *anything* after that, except to express confusion | 11:01 |
| vila | lifeless: ok, let's reset at: '@ does not need +' ok ? | 11:02 |
| * spiv expresses confusion with a confusing expression ;) | 11:02 | |
| lifeless | ok | 11:02 |
| === weigon_ is now known as weigon | ||
| phcoder | hello, all. I develop in a project which uses svn as main repo. I previously worked with it through git-svn and now due to general dev move to bzr I move to it too. I imported my git stuff with bzr-git but now I find myself unable to merge anything coming from bzr-svn with anything coming from bzr-git. Any help? | 11:49 |
| === lamont`` is now known as lamont | ||
| === mtrudel_ is now known as cyphermox | ||
| Bear10_ | I'm having a bit of trouble figuring out how bazaar works, can someone help me out? I've created my repository, and comitted the initial files, now I don't know how working on a remote repository works. Sure I can connect fine, but in the xplorer when I connect it says its on revision one and that there are no working branches. | 13:52 |
| jam | morning all | 14:02 |
| bialix | hello jam | 14:02 |
| bialix | Bear10_: read tutorial from this section and down http://doc.bazaar-vcs.org/latest/en/mini-tutorial/index.html#publishing-your-branch-with-sftp | 14:03 |
| === davidstrauss__ is now known as davidstrauss | ||
| Bear10_ | thanks | 14:12 |
| Bear10_ | bialix, okay I understand this concept, but are all branches you create first local? then you upload the whole branch, and it then creates that branch on the server for others to work on it? | 14:14 |
| jam | Peng_: the chk_map patch is on its way to pqm | 14:15 |
| jam | vila: let me know if there is babune fallout | 14:15 |
| bialix | Bear10_: you can create branch on server first | 14:15 |
| phcoder | bialix: would you by chance know how to import git-svn to bzr and have same ids on files as bzr-svn'ed branches? | 14:15 |
| bialix | it does not realy matter | 14:15 |
| * jam needs to go wrestle bzr-rewrite into submission so I can officially announce 2.1.0b1 | 14:15 | |
| vila | morning jam ! | 14:15 |
| Bear10_ | sorry im new to this heh read everything i could now its a matter of putting it into practice | 14:15 |
| vila | jam: if you ping me as soon as it lands, I'll make a run just for you | 14:16 |
| jam | Bear10_: you can do it either way | 14:16 |
| vila | jam: or if I happen to see it lands before you ping me, I'll telll you | 14:16 |
| bialix | phcoder: I can't say for sure. Try asking jelmer, jam, vila and lifeless | 14:16 |
| jam | *I* tend to create branches locally, and then push them when I'm ready for it | 14:16 |
| bialix | hi guys | 14:16 |
| vila | hey abilx | 14:16 |
| jam | phcoder: svn => git => bzr is going to be very difficult to get identical to svn => bzr | 14:17 |
| Bear10_ | jam, that seems most logical (to me) | 14:17 |
| bialix | lol | 14:17 |
| jam | I would recommend using "git dpush" back into svn, and then pulling from there | 14:17 |
| bialix | vila: :-# | 14:17 |
| jam | Bear10_: of course, I create *lots* of branches, and push fairly regularly | 14:17 |
| vila | wow, how did I typoed that.... | 14:17 |
| phcoder | jam: you mean dcommit? It could work. I need to setup local svn for this | 14:18 |
| Bear10_ | jam, where is the "main" build / revision of the app stored? in a branch? the root? | 14:18 |
| jam | phcoder: right | 14:18 |
| jam | dcommit | 14:18 |
| jam | Bear10_: I don't quite understand the question | 14:18 |
| jam | what "app" ? | 14:18 |
| Bear10_ | jam, the project | 14:18 |
| vila | sorry Alexander, I meant to type bialix, may be I should use the completion more :) | 14:18 |
| bialix | vila: I was under impression it was intended | 14:18 |
| bialix | vila: anyway you made me good lol | 14:19 |
| vila | not at all, no idea how it occurred :-/ | 14:19 |
| Peng_ | jam: Great. :) | 14:19 |
| vila | ha good :) | 14:19 |
| === EdwinGrubbs is now known as Edwin-afk | ||
| bialix | vila: everything is fine | 14:19 |
| bialix | :-D | 14:19 |
| jam | phcoder: note, though, that I think you need the *same* svn UUID, and some other such bits | 14:19 |
| phcoder | Actually git preserves svn ids. Can I perhaps somehow hack bzr-git to use them to create IDs? | 14:19 |
| === mrevell is now known as mrevell-lunch | ||
| Bear10_ | okay i think i understand this now | 14:21 |
| Peng_ | I think a recent revision of bzr-git has some git-svn stuff. | 14:21 |
| phcoder | the last line in log entries looks like " git-svn-id: svn+ssh://svn.savannah.gnu.org/grub/trunk/grub2@2618 d0de0278-0dc1-4c01-8a07-af38b3205e46" | 14:22 |
| phcoder | Peng_: oh. Looks like my sid is outdated. Going to find bzr dev repo | 14:22 |
| bialix | jam: official announce will be good. it becomes bad habit to wrap tarball, build installers and then announce after a month | 14:22 |
| bialix | jam: no pun intended | 14:22 |
| jam | bialix: well, since the 2.1.0b1 installer still doesn't work | 14:23 |
| jam | I haven't announced | 14:23 |
| jam | I was hoping jelmer would release an updated bzr-rewrite | 14:23 |
| jam | but he didn't seem to notice my queries | 14:23 |
| Peng_ | phcoder: Note that I didn't claim it will work or anything! :P | 14:23 |
| jam | so I'm going to have to do it myself | 14:23 |
| bialix | jam: I know. But they to gold almost 2 weeks ago | 14:23 |
| bialix | *going to gold | 14:24 |
| phcoder | Peng_: I guess I'll have to find out and hack if needed. Can someone provide me an insight on how file UUIDs are generated? | 14:25 |
| phcoder | or a link to dev doc should be ok | 14:25 |
| jam | phcoder: it depends on the source and converter | 14:29 |
| jam | I believe bzr-svn's codebase is where you want to look | 14:29 |
| jam | IIRC it was something like branch@revno+path | 14:29 |
| Peng_ | I think the syntax might be a little different, but that's basically it. It includes the repo UUID. | 14:30 |
| Peng_ | (I think?) | 14:30 |
| phcoder | How can I look at File IDs in my repo? | 14:30 |
| Peng_ | phcoder: Various commands accept a "--show-ids" argument. "inventory" might. | 14:30 |
| jam | vila: what is the status of: https://code.edge.launchpad.net/~vila/bzr/353370-notty-no-term-width/+merge/13832 | 14:32 |
| jam | Did you decide to abandon it? | 14:32 |
| vila | huh ? Certainly not, but you said you wanted it to be discussed, so I'm waiting :-) | 14:33 |
| vila | Well, may be I should have summarize some more ideas I had since, but I thought there was already some meat (and code !) to start the discussion | 14:34 |
| === mrevell-lunch is now known as mrevell | ||
| vila | like, we may want to move some parts of that into bzrlib.ui.... | 14:34 |
| vila | ...fater our discussion friday, I wasn't sure about the outcomes, having thought a bit more about COLUMNS, it seems that if we see it in os.environ, it means the user set it, so I stand by my design to obey it if present (unless proved wrong, but all my tests on various OSes so far...) | 14:36 |
| vila | s/fater/after/ damn fingers | 14:36 |
| * vila removes his boxing gloves | 14:37 | |
| phcoder | bzr is downloading at 2 KB/s on otherwise decent connection. What may be the cause? | 14:41 |
| vila | jam: what were you referring to in 'Peng_: the chk_map patch is on its way to pqm' ? | 14:41 |
| jam | vila: https://code.edge.launchpad.net/~jameinel/bzr/2.1-static-tuple-chk-map/+merge/13740 | 14:42 |
| jam | using StaticTuple in the CHKMap code. | 14:42 |
| vila | pqm queue is empty... | 14:43 |
| bialix | phcoder: bzr ls --show-ids | 14:44 |
| phcoder | bialix: already found it, thanks. When I'll download bzr at this 2KB/s I'll get hacking on it. | 14:46 |
| phcoder | I'll probably go with lightweight checkout | 14:46 |
| bialix | you can get tarball then | 14:47 |
| vila | jam: so you didn't submit it to pqm yet ? | 14:47 |
| jam | vila: it is submitted, and going through testing now | 14:47 |
| jam | unless it got rejected... | 14:47 |
| jam | hmm.... I sent it, I'll try again, I guess | 14:48 |
| vila | may be some delay between you and pqm... | 14:48 |
| jam | No, I'm just full of it | 14:49 |
| jam | I realized I wanted to update NEWS before submitting | 14:49 |
| jam | and then forgot to push and then submit | 14:49 |
| vila | happens :-/ | 14:49 |
| phcoder | Tarball downloading is at 400KB/s. Checkout is at 2KB/s. Why is this? Unfortunately I have the same problem on grub2 bzr too | 14:51 |
| jam | phcoder: what version of bzr? | 14:52 |
| jam | vila, Peng: now it is *really* there | 14:52 |
| phcoder | phcoder@debian:~/repos$ bzr version | 14:53 |
| phcoder | Bazaar (bzr) 2.0.1 | 14:53 |
| vila | jam: ok | 14:53 |
| vila | jam: I haven't read the patch in detail, so just a quick check: it doesn't makes the C extension mandatory right ? (Welll babune *will* tell, but you're faster :-) | 14:54 |
| jam | vila: it isn't supposed to. It *is* supposed to make using one of the StaticTuple implementations mandatory | 14:55 |
| vila | errrr, I thought spiv said he desactivated --subunit on qpm but I'm still seeing the progress report... | 14:55 |
| vila | ohhh, I missed more than I thought then, you made python and C impls. for StaticTuple ? | 14:56 |
| vila | I thought you keep using tuple for python... | 14:56 |
| phcoder | link here http://bazaar-vcs.org/BzrPlugins to bzr-svn is broken can somone provide me the good one? | 14:57 |
| jam | vila: he did, and it is a different progress indicator | 14:58 |
| jam | hence why it says "0%" | 14:58 |
| jam | vila: _static_tuple_py.py inherits from 'tuple' | 14:58 |
| jam | rather than wrapping it | 14:58 |
| jam | so that you don't get 2x memory *bloat* when not running the extensions | 14:58 |
| vila | ok | 14:58 |
| jam | phcoder: 'bzr branch lp:bzr-svn' ? | 14:58 |
| Peng_ | jam: BTW, when using _static_tuple_py, does intern() intern forever? | 15:00 |
| vila | jam: by the way, one of the expected outcome from reducing memory consumption was also to reduce time spent handling it, did you see some significant performance improvement there ? | 15:00 |
| jam | Peng_: yes, I can't mutate the refcount of native python objects | 15:00 |
| phcoder | jam: worked. Thanks | 15:00 |
| jam | vila: 'time bzr branch launchpad' went from 10-11m => 8.5m | 15:01 |
| vila | jam: nice ! | 15:01 |
| jam | vila: I think it is mostly from removing GC objects | 15:01 |
| jam | which I *think* has a quadratic effect | 15:01 |
| jam | everytime you allocate N gc objects, it does a gc sweep | 15:02 |
| jam | and then you have +N objects | 15:02 |
| Peng_ | jam: ...That's kind of bad. | 15:02 |
| vila | often more than linear yes | 15:02 |
| jam | so after doing 100k objects, you have triggered 100k / 700 sweeps, and each one at 700 objs, 1400objs, ... etc | 15:02 |
| jam | anyway, I expect small to no improvement for "bzr branch bzr" but a modest improvement for 'bzr branch lp' | 15:04 |
| jam | and probably an even bigger on for "bzr branch mysql"... probably quite significant for "bzr branch OOo" | 15:04 |
| visik7 | is there a way to tell the webdav plugin to remember user and pass ? | 15:06 |
| vila | visik7: yes, use authentication.conf | 15:09 |
| visik7 | vila but I need to specify the user/pass in that file ? | 15:10 |
| visik7 | what's the difference of specifying if in branch.conf as http+webdav://username:password@domain/path ? | 15:11 |
| vila | visik7: well, either that or you type them | 15:11 |
| visik7 | I would a way to autosave from the command line when I first branch/checkout | 15:11 |
| vila | autosave is a can of worms nobody want to open now | 15:12 |
| vila | visik7: but patches welcome ! | 15:12 |
| vila | specifying them in branch.conf is more risky and branch specific whereas authentication.conf will allow you to specify them *once* for each host | 15:13 |
| vila | or even a whole domain depending on your usage, see the doc | 15:13 |
| visik7 | ok | 15:14 |
| vila | visik7: http://doc.bazaar-vcs.org/development/en/user-reference/index.html#authentication-definitions | 15:14 |
| nyu | $ bzr upgrade --format=rich-root-pack | 15:28 |
| nyu | bzr: ERROR: Cannot convert from format Branch format 7 to format <class 'bzrlib.branch.BzrBranchFormat6'>. No converter | 15:28 |
| nyu | am I out of luck? | 15:28 |
| nyu | with bzr 2.0.1 | 15:28 |
| jam | nyu: that is a downgrade, is there a reason you want to do so? | 15:30 |
| nyu | jam: I want to remain compatible with bzr 1.5 | 15:30 |
| jam | nyu: I guess that isn't something we specifically worked on. let me check the code a bit | 15:32 |
| jam | yeah, i think Branch7 was introduced in bzr 1.6... | 15:34 |
| * nyu screams vendor lock-in ;-) | 15:34 | |
| jam | is there a reason 1.5? | 15:34 |
| nyu | well | 15:34 |
| nyu | I use 1.5 myself, as it comes in debian lenny | 15:34 |
| nyu | and I wouldn't want to make it harder for all lenny users to access the repo | 15:35 |
| d1b | nyu: just make it available via svn / git as well..? | 15:35 |
| nyu | actually it comes from svn, but we only have trunk there | 15:36 |
| nyu | uhm. I guess most users can live with just trunk | 15:36 |
| d1b | nyu: do users use svn / bzr? | 15:37 |
| nyu | well, I was thinking more s/users/casual contributors/ | 15:38 |
| nyu | the kind of people who send a patch once and are never seen again | 15:39 |
| jam | nyu: well, it is trivial to do the downgrade | 15:39 |
| jam | we just didn't implement it | 15:39 |
| jam | I think it will be about a 10-line plugin | 15:39 |
| jam | give me a sec | 15:39 |
| nyu | oh | 15:39 |
| nyu | phcoder: sounds like an easier approach | 15:39 |
| phcoder | nyu: what an effect when a GNU maintainer asks ;) | 15:40 |
| nyu | hey, I wasn't asking | 15:40 |
| nyu | just suggesting :-) | 15:40 |
| nyu | want me to give up with 1.5 completely? | 15:41 |
| d1b | nyu: what project is this btw ? | 15:42 |
| nyu | d1b: GRUB | 15:42 |
| d1b | oh. | 15:42 |
| d1b | grub uses bzr? | 15:42 |
| nyu | to some extent yes :-) | 15:42 |
| d1b | i only see svn on the site tho. | 15:42 |
| nyu | maybe we end up switching completely | 15:43 |
| nyu | oh, haven't had time to update it | 15:43 |
| nyu | besides, the website is still in *CVS* | 15:43 |
| d1b | nyu: plz do provide another version control system to download stuff via tho :) -> im also on lenny and don't want to update foo just to get the dev current stuff | 15:43 |
| d1b | etc. | 15:43 |
| jam | nyu: well, I looked at implementing a converter, but it looks like the upgrade code doesn't want to do it cleanly. So I'll give you the real secret way | 15:44 |
| jam | echo "Bazaar Branch Format 6 (bzr 0.15)" > .bzr/branch/format | 15:44 |
| jam | nyu: as long as you aren't using stacking, format 6 is identical to format 7 | 15:44 |
| nyu | jam: lol | 15:44 |
| nyu | ok :-) | 15:45 |
| jam | the format bump was mostly a 'compatibility' flag. | 15:45 |
| jam | We didn't want older bzr's to think they could write to a stacked branch | 15:45 |
| jam | and then bork the content | 15:45 |
| nyu | if I don't know what stacking is, does that mean I'm not using it? | 15:45 |
| jam | 'bzr branch --stacked' | 15:45 |
| jam | I doubt you are using it | 15:46 |
| jam | possibly on Launchpad, but that doesn't sound like where you are doing this stuff | 15:46 |
| nyu | $ bzr branch sid/mips | 15:46 |
| nyu | bzr: ERROR: Unknown working tree format: 'Bazaar Working Tree Format 6 (bzr 1.14)\n' | 15:46 |
| nyu | uhm | 15:46 |
| jam | nyu: 'bzr2.0 remove-tree' 'bzr1.5 co .' | 15:47 |
| jam | actually, I think "bzr remove-tree; bzr co" would do just fine with 2.0 | 15:48 |
| nyu | still same error | 15:49 |
| nyu | note this branch is an import from git | 15:49 |
| jam | nyu: well, if you just do "bzr remove-tree" then it shouldn't be possible. Though I'm wondering if there is another WT somewhere that is confusing it. | 15:51 |
| nyu | WT? | 15:52 |
| nyu | well, this branch is inside a rich-pack | 15:52 |
| nyu | and I'm branching to outside of it | 15:52 |
| nyu | same problem when branching to inside the rich-pack | 15:53 |
| bialix | WT == working tree | 15:57 |
| vila | jam: babune run started | 16:04 |
| jam | vila: thx | 16:18 |
| === sdboyer is now known as agentrickards_lu | ||
| === agentrickards_lu is now known as sdboyer | ||
| === deryck is now known as deryck[lunch] | ||
| phcoder | which API function is used to add a file to a repo? | 16:49 |
| === beuno is now known as beuno-lunch | ||
| Tak | I'm using WorkingTree.smart_add | 16:57 |
| Milo- | hello, is there a documentation somewhere how to handle binary conflicts? | 17:10 |
| Milo- | mv file.ext.OTHER file.ext causes 'unknown file.ext' message to status, so that sounds like a bad idea. | 17:11 |
| GaryvdM | Milo-: That's odd - Are you sure you did not have a typo. | 17:19 |
| Milo- | it gives two messages to status | 17:19 |
| Milo- | "removed file.ext" and "unknown file.ext" | 17:19 |
| Milo- | and when you finally hit bzr resolve, it says all is fine, but when you commit is says "missing file.ext.OTHER" | 17:20 |
| GaryvdM | Milo-: If not confidential, please pastebin the actual output | 17:20 |
| Milo- | I'm thinking I should move file over another like that. | 17:20 |
| Milo- | I shouldn't* | 17:20 |
| Milo- | can't, team mate handled that conflict | 17:21 |
| Milo- | with my instructions. | 17:21 |
| Milo- | and he used windows's bazaar integration.. | 17:21 |
| === deryck[lunch] is now known as deryck | ||
| GaryvdM | Milo-: "missing file.ext.OTHER" - that sounds like "file.ext.OTHER" was committed. | 17:21 |
| Milo- | GaryvdM indeed :/ | 17:22 |
| mzz | that sounds like something/someone did a "bzr add file.ext.OTHER", and then "bzr resolve" removed that .OTHER file | 17:23 |
| mzz | hmm, I can't reproduce anything but a cosmetic problem if I do that though. | 17:26 |
| mzz | specifically I get a "missing a.OTHER" when I commit, but the commit succeeds and a.OTHER doesn't seem to get committed anywhere. | 17:26 |
| mzz | that doesn't seem to be a merge/resolve-specific thing, actually. | 17:27 |
| mzz | if I touch, bzr add, and rm a new file I get that same "missing b" on commit (and it's not mentioned at all in status) | 17:28 |
| jfroy|work | Does bazaar support relative dates for logging? | 17:28 |
| jfroy|work | For example, " | 17:28 |
| jfroy|work | *For example, "give me the logs for the past week" | 17:28 |
| Milo- | I did the binary conflict now with openoffice | 17:28 |
| jfroy|work | (for some definition of week) | 17:28 |
| Milo- | made file.odt, changed it in two locations | 17:29 |
| Milo- | commited the other one | 17:29 |
| Milo- | updated on the other checkout and got conflict, now I only have "file.odt.OTHER, file.odt.THIS, file.odt.BASE" | 17:29 |
| mzz | jfroy|work: skimming "bzr help revisionspec" says it can do yesterday, today, and tomorrow, but I see no other relative things there | 17:30 |
| Milo- | file.odt has been renamed to file.odt.OTHER | 17:30 |
| Milo- | thought THIS had my changes and OTHER the other person's changes. | 17:30 |
| mzz | Milo-: checkouts are special like that, iirc | 17:30 |
| jfroy|work | I guess you could use -r date:{last's week date}.. | 17:31 |
| Milo- | so how do you resolve the conflict? | 17:31 |
| Milo- | should I manually merge the stuff to the .OTHER and then just hit resolve? | 17:31 |
| Milo- | or what? | 17:31 |
| mzz | Milo-: I'm pretty sure you should just put the right content in file.odt and then "bzr resolve" | 17:32 |
| IslandUsurper | Milo-, if file.ext is the way you want it, you can probably bzr rm file.ext.OTHER | 17:32 |
| mzz | Milo-: normally bzr gives you a bunch of files to make that easier: your version, the other version, the closest ancestor version, and a merge | 17:32 |
| Milo- | hehee | 17:33 |
| mzz | Milo-: it can't give you a merge for a binary format, which is probably why file.odt is now missing | 17:33 |
| Milo- | did `bzr resolve file.odt` | 17:33 |
| Milo- | that removed the .OTHER .THIS and .BASE | 17:33 |
| Milo- | and now I don't even have the file.odt :D | 17:33 |
| mzz | yes | 17:33 |
| mzz | ah | 17:33 |
| mzz | that's odd | 17:33 |
| Milo- | renamed: file.odt => file.odt.OTHER | 17:33 |
| mzz | normally you just do "bzr resolve" and it detects which conflicts you actually resolved | 17:34 |
| Milo- | that was one of the lines that I got when I did bzr update | 17:34 |
| mzz | bah, the term I did this in has no scrollback | 17:34 |
| Milo- | what if I just want to ignore the changes my team mate did? | 17:34 |
| mzz | you'd cp or mv the right file to file.odt and bzr resolve | 17:34 |
| Milo- | that's what I told my team mate to do | 17:35 |
| Milo- | and we had the missing 'error' | 17:35 |
| Milo- | since it committed all nicely it doesn't 'really' matter | 17:35 |
| mzz | I tend to avoid checkouts in cases where you actually end up merging, because they're a little confusing. | 17:35 |
| mzz | I don't understand why you'd get that error unless something went and bzr added that file | 17:36 |
| mzz | (it's entirely possible some integration thing did that, I don't use those) | 17:36 |
| Milo- | I use branches with my laptop and checkout with my desktop | 17:36 |
| Milo- | since laptop is mostly offline (or can't reach port 4155), and desktop isn't | 17:36 |
| Milo- | well, I used bash, and that renamed the .odt file completely | 17:36 |
| mzz | I think the message you're getting is just cosmetic (it noticing the file vanished from the working tree since the last time it looked) | 17:37 |
| jam | Milo-: "bzr resolve file.odt" forcibly resolves the conflict. (giving an explicit name tells us that you want this file to be unmarked.) | 17:38 |
| mzz | yes | 17:38 |
| Milo- | jam yes | 17:38 |
| jam | as for "mv file.odt => file.odt.OTHER" | 17:38 |
| jam | that would hint that you had deleted the file locally | 17:38 |
| jam | and someone else made changes that you merged | 17:38 |
| Milo- | yes I know | 17:38 |
| Milo- | thought it would bring the local copy back | 17:38 |
| jam | if you still want the file gone "bzr revert file.odt" should do the right thin | 17:38 |
| Milo- | by re-renaming the OTHER | 17:38 |
| jam | Milo-: it *did*, but as "file.odt.OTHER" to indicate it was deleted locally | 17:39 |
| mzz | it's trying to prevent you from accidentally resurrecting the file, afaict. | 17:39 |
| Milo- | but now if I move some other file as 'file.odt', the change history points to some other file, that gets destroyed along with file.odt.OTHER ? | 17:40 |
| mzz | I'm not sure if this is exactly *always* the case, but if you do get a conflict it's pretty unusual to be able to commit the conflicting file as-is. | 17:40 |
| mzz | I don't follow. | 17:40 |
| mzz | if you put some completely unrelated file in as file.odt and say "bzr resolve" or "bzr resolve file.odt" I'd expect it to remove file.odt.{THIS,BASE,OTHER} | 17:41 |
| mzz | I don't understand what "the change history points to some other file" means | 17:41 |
| Milo- | it removes them, but the repo still has history of that file.odt that had the conflict in the first place.. | 17:41 |
| mzz | yes | 17:41 |
| mzz | (how could it not have that history?) | 17:42 |
| Milo- | and now that the file.odt is no longer that file, the history isn't exactly 'his' now is it? | 17:42 |
| mzz | what? | 17:42 |
| Milo- | file.odt is replaced with some other file | 17:43 |
| mzz | well, he did "bzr merge somebranch", and committed. | 17:43 |
| mzz | so the history from branch "somebranch" is now part of the history of that branch too | 17:43 |
| Milo- | the history points to the old file.odt, right? | 17:43 |
| mzz | that's what a merge *does*, very roughly. | 17:43 |
| Milo- | but this wasn't from merge.. | 17:43 |
| mzz | if you run "bzr log file.odt" you'd see those old revs, yes. | 17:43 |
| Milo- | ok | 17:43 |
| mzz | if this is a checkout that got out of date and got updated that *is* a merge | 17:44 |
| mzz | I am confused about what you're confused about! | 17:44 |
| Milo- | heh | 17:45 |
| nyu | how do I extract a diff of the whole branch? (other than searching the branch point + bzr diff -r<branchpoint>..<head>) | 17:49 |
| dash | nyu: bzr diff -rancestor:../parentbranch | 17:50 |
| dash | where "../parentbranch" is the path to the branch you want to diff against | 17:50 |
| === beuno-lunch is now known as beuno | ||
| nyu | thanks | 17:55 |
| beuno | Peng_, hi | 18:14 |
| beuno | would you like to take a peak at my YUI3 mp? | 18:14 |
| Peng_ | beuno: Sure, but I can't really review it. | 18:15 |
| Peng_ | I'd be happy to poke at it a bit, though. | 18:15 |
| beuno | Peng_, poking at it and seeing if there's anything broken is good progress :) | 18:15 |
| Peng_ | beuno: What do you mean by the search results being "off"? | 18:17 |
| beuno | Peng_, if you search, the autocomplete doesn't appear beneath the search box, it ends up middle aligned or something like that | 18:17 |
| Peng_ | Oh, fun. | 18:19 |
| beuno | yeah, I will fix that | 18:19 |
| Peng_ | Well, I just put it up on http://bzr.mattnordhoff.com/loggerhead/. | 18:21 |
| beuno | it seems to work for me | 18:22 |
| Peng_ | beuno: The YUI module pluginhost is getting loaded too | 18:22 |
| Peng_ | I mean, and it isn't declared in the page, so it always gets loaded from Yahoo! instead of using the local copy. | 18:22 |
| beuno | Peng_, that's interesting | 18:23 |
| Peng_ | beuno: Mind if I assign bug #439155 to you? | 18:24 |
| ubottu | Launchpad bug 439155 in loggerhead "Upgrade to YUI 3.0.0" [Low,Triaged] https://launchpad.net/bugs/439155 | 18:24 |
| beuno | Peng_, not at all, I could use the karma! | 18:24 |
| Peng_ | :D | 18:25 |
| Peng_ | beuno: Ah, sorry, pluginhost doesn't get loaded after I refresh everything. | 18:27 |
| beuno | Peng_, good. Those things are a PITA to debug | 18:28 |
| Peng_ | beuno: Poking around a bit, everything does seem to work. :) | 18:29 |
| beuno | Peng_, super. Could you comment on the MP so we encourage mwhudson to approve? :) | 18:30 |
| === raimue is now known as Raim | ||
| === asac_ is now known as asac | ||
| * beuno waves at mwhudson | 19:16 | |
| mwhudson | beuno: hello! | 19:16 |
| beuno | mwhudson, how are you? | 19:17 |
| mwhudson | beuno: i am ok | 19:17 |
| mwhudson | slightly disheartened by how much email even a single day off has resulted in | 19:17 |
| mwhudson | beuno: how are you? | 19:17 |
| beuno | mwhudson, pretty good, doing the release week dance, but good | 19:18 |
| mwhudson | ah yes | 19:18 |
| beuno | mwhudson, did you have time to look at me yui3 branch? | 19:21 |
| mwhudson | beuno: no | 19:22 |
| mwhudson | beuno: did you do the merge proposal thing? | 19:22 |
| beuno | mwhudson, https://code.edge.launchpad.net/~beuno/loggerhead/yui3-0-0/+merge/13744 | 19:22 |
| mwhudson | strange, i don't have that mail | 19:23 |
| beuno | mwhudson, it ooped :) | 19:23 |
| mwhudson | oh yeah :) | 19:23 |
| mwhudson | hm, it doesn' | 19:25 |
| mwhudson | t have a diff either | 19:25 |
| vila | jam: breathe again ! | 19:31 |
| vila | jam: babune just finished (and except for random leaking tests related faliures on OSX all is well) | 19:31 |
| vila | jam: well, and one random on gentoo, but that doesn't count either :-/ | 19:32 |
| fullermd | Oh, does that means it's safe to go back in the bzr.dev? | 19:34 |
| vila | fullermd: hehe, it has always been safe :-) | 19:36 |
| === abentley is now known as abentley-lunch | ||
| fullermd | Famous last words... | 19:40 |
| mwhudson | beuno: replacing region.left with search_box.get('offsetWidth') doesn't seem like it's going to work | 19:44 |
| beuno | mwhudson, it doesn't :) | 19:45 |
| mwhudson | i see | 19:45 |
| beuno | I need to fix that before landing | 19:45 |
| mwhudson | beuno: why does region no longer work? | 19:45 |
| beuno | mwhudson, it's a great question. I haven't been able to find out. I went around in circles for a good hour, and gave up (that includes asking in #yui3) | 19:46 |
| mwhudson | i love the way noone actually knows what they're doing in js :( | 19:47 |
| beuno | :) | 19:47 |
| mwhudson | i mean, i know _i_ don't | 19:47 |
| mwhudson | beuno: basically i agree with Peng | 20:05 |
| mwhudson | beuno: it looks fine, but fix the bug before landing, eh? | 20:05 |
| beuno | mwhudson, sure, I will and land, thanks | 20:06 |
| mwhudson | beuno: i might try to poke at fixing the bug today if i get a moment | 20:06 |
| beuno | that would be nice | 20:07 |
| huf | hi, we used to have a working bzr smart server (with bzr+http, fcgi, apache) | 20:10 |
| huf | the bzr on that system was upgraded to 1.16.1, and now a bzr push (from a client with bzr 2.0.1) returns this: | 20:10 |
| huf | bzr: ERROR: Server sent an unexpected error: ('error', "An attempt to access a url outside the server jail was made: 'chroot-139343724:///'.") | 20:10 |
| huf | what could this be, where should i look for answers? | 20:11 |
| mwhudson | it's a bzr bug i think | 20:11 |
| GaryvdM | huf: What was the bzr version of the client? | 20:11 |
| Peng_ | huf: Bug #348308. | 20:12 |
| ubottu | Launchpad bug 348308 in bzr "Smart server jail breaks bzr+http with shared repos" [High,Fix released] https://launchpad.net/bugs/348308 | 20:12 |
| Peng_ | The one bug number in the world I have memorized. | 20:12 |
| Peng_ | huf: The fix is in bzr.dev; upgrade your server to it. Or, you can use the monkeypatch listed in that bug. | 20:13 |
| === abentley-lunch is now known as abentley | ||
| huf | thanks, that patch seems to have fixed it | 20:19 |
| huf | how long should a branch of a ~200M repo take? | 20:33 |
| huf | roughly | 20:33 |
| huf | okay ;) i managed to segfault apache's mod_fcgid process handler with a bzr branch command | 20:51 |
| Peng_ | That's awesome. | 20:55 |
| huf | oookay, now i get a timeout in the fastcgi process handler | 21:05 |
| huf | FastCGI: comm with (dynamic) server "/var/www/bzr.nws.hu/bzr-smart.py" aborted: (first read) idle timeout (30 sec) | 21:06 |
| jam | mwhudson: hmm.. I've been getting a lot of "Internal Server Errors" in loggerhead today. Does that get recorded as an OOPs ? | 21:08 |
| mwhudson | jam: no :( | 21:08 |
| jam | mwhudson: http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/annotate/head%3A/bzrlib/_simple_set.pyx | 21:08 |
| jam | now, that turns out to be a bad URL | 21:09 |
| jam | since it is "_simple_set_pyx.pyx" | 21:09 |
| mwhudson | jam: hooray loggerhead error reporting | 21:09 |
| jam | but I wouldn't have thought a bad path would cause an ISE | 21:09 |
| mwhudson | it shouldn't, indeed | 21:09 |
| Peng_ | There's an open bug on better handling of bad input. | 21:16 |
| huf | what's the "best practice" method of making password-protected r/w repos and serving them on the net? | 21:23 |
| jam | huf: anonymous readonly ? or no access? | 21:26 |
| jam | http? or ssh? | 21:26 |
| jam | The most common is to just provide bzr+ssh:// and require full ssh authentication | 21:26 |
| AfC | My lord. 120 MB of download to propagate a few patches to Eclipse. Someday, oh someday we'll have a binary delta distribution system that is as efficient as the source delta distribution system aka bzr. | 21:59 |
| awilkins | Can you just push branches into Ubuntu One? | 22:33 |
| gioele | abentley: hi | 23:15 |
| abentley | gioele: hi. | 23:15 |
| gioele | abentley: is bzr-pipeline supposed to work only with bzr 2.1 and not with 2.0? | 23:16 |
| abentley | gioele: The 2.0.0 branch is supposed to work with 2.0, and the trunk branch is supposed to work only with 2.1 | 23:17 |
| gioele | abentley: I didn't see a 2.0 branch. Is it on launchpad? | 23:18 |
| abentley | gioele: Yes: https://code.edge.launchpad.net/~abentley/bzr-pipeline/2.0.0/ | 23:19 |
| gioele | abentley: ah, OK. The Launchpad page for bzr-pipeline didn't show a 2.0 branch. Could you add that to the list of branches? | 23:20 |
| abentley | gioele: There isn't a 2.0 branch, it's called 2.0.0. | 23:21 |
| gioele | abentley: well, the problem is that launchpad says that it is merged, so it is no longer active, no it will not be shown by default in the list of bzr-pipeline's branches | 23:22 |
| abentley | gioele: Right. I have just fixed that. | 23:23 |
| gioele | abentley: thank you | 23:23 |
| larsemil | what do i do when a branch has diverged= | 23:26 |
| dash | well, it means there are changes in your version and the other version | 23:27 |
| dash | you can merge them if you like | 23:27 |
| AfC | Hm. I wonder what would happen if used bzr to transfer songs to my MP3 player, rather than using rsync/unison. Be interesting to see what would happen with such a large amount of opaque data [interesting and no doubt ugly]. | 23:28 |
| dash | AfC: do you often use diff on yor mp3s? :) | 23:29 |
| lifeless | AfC: it would work | 23:29 |
| AfC | dash: :) | 23:29 |
| larsemil | i did. and then i get a main.cpp a main.cpp.THIS and .BASE | 23:29 |
| lifeless | just use a little more memory | 23:29 |
| AfC | lifeless: the width (ie GBs) wouldn't be a problem? | 23:29 |
| lifeless | AfC: the size of an individual song matters | 23:29 |
| lifeless | in aggregate, it matters for the packing - db file balancing | 23:30 |
| lifeless | personally, I wouldn't use bzr to put files on an mp3 player, because I have many more songs than disc space on such devices | 23:30 |
| AfC | So, the situation is that I'm using Rockbox now on my iPod. It's pretty good! Some rough edges, but quite innovative in other areas. Rather than using (say) gtkpod to get files there, one just copies files to its [vfat :(] filesystem. | 23:30 |
| AfC | Over time, I delete songs I've decided I don't like. This happens on both sides. So I've started using Unison (rather than rsync --delete). | 23:31 |
| AfC | and that's fine, except that it takes Unison almost an hour (!) to find out what the change map is. | 23:31 |
| AfC | [one strangeness is that the mtimes of the files on the device seem to be perennially off by one hour] | 23:32 |
| AfC | so that's why I'm speculating that bzr might do a better job. | 23:32 |
| AfC | on the other hand, there is the question of where to keep the Repository, the fact that the repo would be huge like the Working Tree that I play from normally is, etc | 23:33 |
| AfC | and, of course, I realize full well that this is not what bzr was meant for. | 23:33 |
| larsemil | i dont get it - if a branch has diverged do i have to put up the two documents and manually change and edit to the version i would want? | 23:34 |
| dash | larsemil: do 'bzr merge <otherbranch>' | 23:35 |
| abentley | AfC: I suggest putting the repo on your computer, and keeping a lightweight checkout on the rockbox. | 23:35 |
| AfC | larsemil: are you talking about source code [or a text based document] or a binary [ie, compressed zip, proprietary binary data, etc, word processor] document? | 23:35 |
| abentley | You'll only commit when you want to sync. | 23:35 |
| AfC | abentley: yeah | 23:36 |
| abentley | You could have a standalone tree on the computer, and a lightweight checkout of that on the rockbox. | 23:36 |
| AfC | abentley: [I'm mentioning this largely to elicit either a "it'll be interesting to see how you go" or a "you're on drugs, Cowie."] | 23:37 |
| AfC | abentley: that would make sense | 23:37 |
| spiv | AfC: I don't think those two options are mutually exclusive ;) | 23:37 |
| AfC | hic | 23:37 |
| lifeless | AfC: the time offset thing is probably vfat mount options | 23:40 |
| AfC | lifeless: that was my guess | 23:40 |
| lifeless | AfC: vfat time storage is local, and you've had daylight savings transition recently | 23:40 |
| lifeless | ext stores timestamps in utc, so doesn't do that | 23:40 |
| lifeless | AfC: I know one guy managing a 100+GB photo collection with bzr | 23:41 |
| AfC | lifeless: I must admit that much as the automounter magic is convenient, I haven't the faintest idea how to go about configuring options for specific devices | 23:41 |
| lifeless | it does it tolerably | 23:41 |
| AfC | huh | 23:41 |
| AfC | [yeah, the DST thing was my guess, though it wasn't a once-off across the transition date, it seems to keep coming up] | 23:42 |
| spiv | mwhudson: I'm working on that path escaping patch now | 23:44 |
| mwhudson | spiv: awesome | 23:44 |
| spiv | mwhudson: I can tell that the existing test wasn't written by me because I always use \N{INTERROBANG} when I need a unicode character ;) | 23:45 |
| mwhudson | :) | 23:45 |
| Peng_ | spiv: No snowman? | 23:45 |
| spiv | Peng_: you mean, no snowman‽ | 23:47 |
| Peng_ | Heh. | 23:47 |
| dash | zing | 23:47 |
| spiv | Someone should make a deck of playing cards with some wacky unicode glyphs rather than the traditional suits. "My 9 of Interrobangs trumps your 8 of Snowman!" | 23:49 |
| Peng_ | That's a really good idea. | 23:50 |
| Peng_ | I'm still mostly not a fan of novelty playing cards, though. | 23:51 |
| dash | spiv: also use cuneiform numbers | 23:51 |
| lifeless | Peng_: if your branches are not on launchpad, consider using lp apis to tell lp that you have updated your branch | 23:56 |
| lifeless | in a post push hook | 23:56 |
| Peng_ | lifeless: Ehh, that's a little complicated. But yeah, I know I need to set something up. | 23:58 |
| lifeless | Peng_: should be pretty easy | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
