| Kobaz | whoops | 00:18 |
|---|---|---|
| Kobaz | i broke bze | 00:18 |
| Kobaz | bzr | 00:18 |
| === Iso_ is now known as IsoSchiz | ||
| Kobaz | http://pastebin.com/m3850ffa2 | 00:19 |
| spiv | Kobaz: you upgraded bzr, but have an old bzrtools shelf | 00:20 |
| spiv | Kobaz: you can use "bzr shelve1"/"bzr unshelve1" to keep using the bzrtools shelf, IIRC. | 00:20 |
| Kobaz | oh | 00:20 |
| Kobaz | should probably be a warning for that or something | 00:21 |
| Kobaz | ii bzr 1.10-1~bazaar1~intrepid1 easy to use distributed version control syst | 00:22 |
| Kobaz | ii bzrtools 1.10-1~bazaar1~intrepid1 Collection of tools for bzr | 00:22 |
| Kobaz | both are the same version | 00:22 |
| spiv | Right; what happened was that bzr shelve became part of the core, rather than provided only by a plugin. | 00:23 |
| Kobaz | k | 00:23 |
| spiv | But the implementation in the core is new and improved compared to the bzrtools one :) | 00:23 |
| Kobaz | k | 00:23 |
| Kobaz | so how would i use the new one? | 00:23 |
| spiv | "bzr shelve", in theory. | 00:24 |
| Kobaz | hmm | 00:24 |
| Kobaz | but that is what croaked | 00:24 |
| spiv | I'm not sure why it's breaking for you, there seems to be a broken shelve file there. | 00:24 |
| spiv | My guess is it's a bzrtools shelf, but that's just a guess. | 00:25 |
| spiv | I could easily be wrong about that... | 00:25 |
| spiv | Please file a bug. At a minimum it shouldn't give a traceback just because of a damaged file. | 00:25 |
| Kobaz | k | 00:26 |
| Odd_Bloke | There already exists a bug for that. | 00:31 |
| Odd_Bloke | Bug 303569. | 00:32 |
| ubottu | Launchpad bug 303569 in bzr "shelving a patch with no new line at end of file fails" [Undecided,Confirmed] https://launchpad.net/bugs/303569 | 00:32 |
| Odd_Bloke | Kobaz: ^ | 00:33 |
| lifeless | spiv: ping | 00:33 |
| IsoSchiz | Hi, I was wondering if someone could help. I am attempting to create a bzr repository from an svn one. I'm running Intrepid (bzr 1.6.1-1, bzr-svn 0.4.13-2) and used the following command: "bzr svn-import --all --scheme=trunk --prefix=endets/ svn+ssh://<hostname>/var/repository endets". It seems to work initially (build a cache, then 'Importing branches with prefix /endets/', which takes a while), but it appears to stop abruptly a | 00:34 |
| lifeless | IsoSchiz: your coment cuts off at 'abruptly a' | 00:34 |
| IsoSchiz | Darn it. :-) Ok, after that it goes: | 00:34 |
| lifeless | rather ironic I thought | 00:35 |
| IsoSchiz | but it appears to stop abruptly and gives the following error when I try to co or branch from it: 'bzr: ERROR: Not a branch: "/home/martin/bzr/endets/.bzr/branch/".' What's gone wrong? :-) | 00:35 |
| IsoSchiz | Yes, it is rather.. | 00:35 |
| lifeless | IsoSchiz: svn-import creates a set of branches | 00:35 |
| lifeless | so run 'bzr branches endets' and you should get the relative url of the branches it made | 00:35 |
| spiv | lifeless: pong | 00:35 |
| IsoSchiz | That gives no output at all... | 00:36 |
| lifeless | spiv: I want to chat [irc] briefly about a refactoring | 00:36 |
| lifeless | IsoSchiz: so, it sounds like it may have errored/failed - what return code did it give? Is there anything in ~/.bzr.log | 00:36 |
| spiv | lifeless: btw, I discovered https://edge.launchpad.net/compiz-colorfilter. I wonder if it could be used for non-colour-blind people to simulate e.g. red-green blindness? | 00:38 |
| IsoSchiz | The svn-import command ends with: 202.125 return code 0 - I haven't checked that's actually the return code though. | 00:38 |
| spiv | lifeless: fire away | 00:38 |
| lifeless | spiv: ok, so I'm going to tackle the stuff we discussed just-in-time, working on the round trips for that blackbox test | 00:38 |
| lifeless | spiv: format.intialize_on_transport() is the code called to make a .bzr dir | 00:39 |
| lifeless | spiv: MetaDirFormat is the concrete class used | 00:39 |
| lifeless | spiv: so I'm thinking in MDF' initialize_on_transport can do a check to see if there is a remote capable transport | 00:40 |
| lifeless | now the question | 00:41 |
| lifeless | at this point I could create a RemoteBzrDirFormat and pass on the format details to it | 00:42 |
| lifeless | and then call that new instance's initialize_on_transport | 00:42 |
| lifeless | or I could do something different | 00:42 |
| lifeless | making a RemoteBDF seems appropriate to me | 00:43 |
| Odd_Bloke | Should the Windows installers work on 64-bit Windows? | 00:44 |
| spiv | Hmm. So asking a MDF to initialize_on_transport might actually give you a Remote thing instead? | 00:44 |
| spiv | That feels a bit weird, but I don't know of anything that would actually break. | 00:44 |
| lifeless | spiv: ok | 00:45 |
| lifeless | spiv: do you know of a good place to put a test that this happens? | 00:45 |
| IsoSchiz | lifeless: Re-ran the import: it returns 0. The log file claims it returns 0, and looks fine otherwise (though I am unsure what to expect). bzr branches gives no output, but returns 0 too. | 00:45 |
| lifeless | IsoSchiz: are there any subdirs in the output? | 00:45 |
| spiv | Hmm. I suppose you could put that test in test_remote. Although I'd probably expect to find it in a test_bzrdir_format module -- if we had one ;) | 00:46 |
| IsoSchiz | lifeless: Only the .bzr, which contains branch-format, branch-lock/, README, repository/ and svn-import-revision | 00:46 |
| lifeless | spiv: we have that | 00:46 |
| lifeless | IsoSchiz: sounds like its not finding any branches to import | 00:47 |
| spiv | Well there's TestBzrDirFormat in test_bzrdir, yeah | 00:47 |
| lifeless | IsoSchiz: have you tried the simpler 'bzr svn-impoprt svn+ssh://<hostname>/var/repository outputdir' | 00:47 |
| spiv | I'd probably lean towards adding it there, I think. | 00:47 |
| IsoSchiz | lifeless: I am just trying that now :-) | 00:48 |
| IsoSchiz | lifeless: slightly more exciting: bzr branches now prints a blank line. :-) | 00:51 |
| IsoSchiz | lifeless: I don't quite understand why it would find *no* branches. Surely at least the trunk would become a branch (even if it doesn't correctly identify the copies in the 'branches' directory as actual branches)? | 00:52 |
| lifeless | IsoSchiz: you might like to try bzr-svn 0.5 which has lots of improvements, you need a newer bzr at the same time too | 00:53 |
| IsoSchiz | lifeless: Is there a PPA containing these for Intrepid? Or do I need to install manually? | 00:55 |
| lifeless | IsoSchiz: yes | 00:57 |
| lifeless | IsoSchiz: http://bazaar-vcs.org/Download | 00:57 |
| baxissimo | Q about this tutorial: http://doc.bazaar-vcs.org/bzr.dev/en/tutorials/centralized_workflow.html | 00:58 |
| baxissimo | It says create a new branch by first doing "bzr init REMOTE/newbranch" then "bzr checkout REMOTE/newbranch" locally. | 01:00 |
| baxissimo | Seems like it's also legit to do "bzr init LOCAL/newbranch" and later "bzr branch LOCAL/newbranch REMOTE/newbrach" | 01:00 |
| bob2 | yes | 01:01 |
| baxissimo | Sound ok? | 01:01 |
| bob2 | + bzr bind REMOTE/newbranch | 01:01 |
| baxissimo | bob2: Ok, yeh, bind if you want automatic pushes. | 01:01 |
| bob2 | if you don't do bind, they do NOT do the same thing | 01:02 |
| baxissimo | bob2: ok. I see. | 01:02 |
| bob2 | but both are reasonable ways to use it | 01:02 |
| baxissimo | bob2: and if you don't bind, then "bzr send" will do the equvalent of "hg push" | 01:03 |
| baxissimo | bob2: ? (if you know hg at all...) | 01:04 |
| bob2 | no idea what hg push does | 01:04 |
| bob2 | bzr send will generate a bundle (ie patch with metadata) and dump it in a file or open your email client | 01:04 |
| baxissimo | It send revisions in the local branch that aren't in the remote branch to the remote branch. | 01:05 |
| bob2 | bzr push will push changes back to the remote branch | 01:05 |
| baxissimo | Ohh.. ok yeh that's the equiv of "hg push" | 01:05 |
| baxissimo | bzr send is I guess analogous to "hg bundle", though sounds like it does a bit more. | 01:06 |
| baxissimo | hg bundle just doesn't have the --mail-to option. | 01:08 |
| baxissimo | bob2: thanks! | 01:08 |
| lifeless | spiv: I'm moving the smart call log to TestCaseWithMemoryTranspirt | 01:10 |
| IsoSchiz | lifeless: newer versions don't work either. :-( Without the --prefix arg, 'bzr branches' produces blank line; with --prefix gives the error: bzr: ERROR: The specified path is inside a branch. Specify a different URL or a different repository layout. | 01:13 |
| spiv | lifeless: +1 | 01:13 |
| spiv | lifeless: I've been increasingly tempted to add something like "start a smart server backed by self.get_url(...)" to TestCaseWithMemoryTransport too | 01:15 |
| lifeless | IsoSchiz: I suggest filing a question on bzr-svn | 01:17 |
| IsoSchiz | lifeless: never done that before. Is this some feature of Launchpad? Perhaps the 'Answers' section...? | 01:19 |
| IsoSchiz | Ok, worked that out, ignore the last question. | 01:20 |
| IsoSchiz | Thanks for your help lifeless. | 01:21 |
| lifeless | IsoSchiz: np | 01:23 |
| lifeless | spiv: so, its 15 round trips to init a bzr meta dir remotely | 01:30 |
| lifeless | spiv: hows the polish on that branch coming | 01:30 |
| lifeless | spiv: 15 -> 2 for initialize_on_format | 01:59 |
| mwhudson | that sounds like a nice improvement :) | 02:01 |
| lifeless | mwhudson: cheap too, server already has the RPC | 02:07 |
| lifeless | it's use got lost during stacking cloning behaviour rearrangments | 02:08 |
| mwhudson | oh right | 02:08 |
| lifeless | bundle sent | 02:09 |
| jelmer | lifeless: thanks! | 02:15 |
| jelmer | lifeless: you forgot to mention that this also fixes initial push in a format unknown to the remote server | 02:15 |
| jelmer | which I think has a bug or two open | 02:15 |
| lifeless | jelmer: I don't think it alters that case at all | 02:16 |
| jelmer | lifeless: not completely, no | 02:18 |
| jelmer | lifeless: but at least you don't end up with a unusable branch on the remote side | 02:18 |
| jelmer | oh, you do | 02:19 |
| jelmer | it just gives the warning earlier | 02:19 |
| jelmer | never mind me | 02:19 |
| lifeless | jelmer: :P | 02:23 |
| jelmer | I guess I was just too eager to see that bug fixed... | 02:23 |
| lifeless | :) | 02:25 |
| * igc lunch | 02:43 | |
| === abentley1 is now known as abentley | ||
| lifeless | so jelmer | 03:20 |
| lifeless | if you read my patch, you could bb:approve it :) | 03:20 |
| poolie | i'm going to push that EC2 build and its docs along a bit further | 03:22 |
| lifeless | 40 calls to do init-repo url | 03:33 |
| poolie | down from 100? | 03:45 |
| lifeless | no | 03:45 |
| lifeless | tested right now as a reasonable component to measure while working on push | 03:45 |
| lifeless | spiv: ping; a test for a new verb - its test_remote for the client, test_smart for the request method backend? | 03:54 |
| poolie | jam, if you're still up, which i suppose you're not, i'm going to mess with the ec2 machine now | 03:54 |
| spiv | lifeless: that's right | 04:04 |
| spiv | lifeless: nice results for the RPC count | 04:04 |
| spiv | lifeless: I just fired off external_references / scan_unvalidated_index patch. | 04:04 |
| === abentley1 is now known as abentley | ||
| lifeless | spiv: ping; it seems really hard to write a test for this using FakeClient, because of all 40 calls I need to emulate for backwards compatibility | 04:35 |
| lifeless | spiv: I'd be happier using a hook to capture the calls and assert that it tried a newer one, and worked. | 04:35 |
| lifeless | spiv: assuming there is some way to say 'give me a old server' | 04:36 |
| lifeless | spiv: -> is there? | 04:36 |
| spiv | An old server? bzr-v2:// ? | 04:39 |
| lifeless | let me pastebin my 'old servers work test' one sec | 04:40 |
| spiv | (The client code usually knows better than to try new methods if the protocol encoding is only v2) | 04:40 |
| spiv | You could also modify the request_handlers dict buried in the server instance somewhere... | 04:42 |
| lifeless | spiv: uhm | 04:44 |
| lifeless | so I don't really care if its a really-old-server | 04:44 |
| lifeless | or just the server-before-I-write-this-method | 04:44 |
| lifeless | http://paste.ubuntu.com/119949/ | 04:45 |
| lifeless | I want to be able to have that be the test | 04:45 |
| lifeless | because it seems clear and complete, if we can be sure the server doesn't support the verb | 04:45 |
| lifeless | thoughts/suggestions? | 04:46 |
| spiv | TestRemotePackRepositoryAutoPack.test_backwards_compatibility does a small monkey-patch to achieve something a bit similar | 04:47 |
| spiv | I don't quite follow the intent of that pastebinned test, though. | 04:48 |
| spiv | Why is asserting that exactly 1 BzrDir.create_repository call a test that the client is backwards compatible with old servers? | 04:49 |
| lifeless | well | 04:49 |
| lifeless | we should try the call (most servers will be up to date | 04:49 |
| lifeless | and it should still work :) | 04:49 |
| lifeless | we shouldn't try more than once | 04:50 |
| spiv | Oh, the missing bit of that test as written is the bit that makes that call not exist on the server? | 04:50 |
| lifeless | yes | 04:51 |
| spiv | If the assertion could be "there's exactly 1 BzrDir.create_repository call, and it got a no-such-method response", that'd be much clearer. | 04:51 |
| spiv | But the existing logging doesn't lend itself to that... | 04:51 |
| lifeless | does the smart server client hook show the result? | 04:51 |
| lifeless | I don't think the precision gained is that important, if we're sure the server can't handle the call | 04:52 |
| lifeless | we can test that by calling it directly, if we care | 04:52 |
| spiv | It doesn't, but it'd be nice if it did. | 04:52 |
| spiv | A brief comment can make it clear enough, we don't have to fall down a rabbit-hole... | 04:53 |
| spiv | So I think ideally you'd be able to modify the server in the test to have no implementation for that method. | 04:57 |
| spiv | Unfortunately it's a bit hard to get at the relevant commands dict atm, there's a little more refactoring needed to make that possible. | 04:57 |
| spiv | You could modify the global request_handlers registry, though. | 04:58 |
| lifeless | yeah try:finally for the win | 04:59 |
| spiv | Yeah. Or addCleanup, and hide all the mucking about in a helper. | 05:00 |
| lifeless | http://paste.ubuntu.com/119961/ | 05:02 |
| lifeless | well | 05:02 |
| lifeless | one line != mucking aorund | 05:02 |
| spiv | I count six, but sure. The test is readable enough. | 05:04 |
| lifeless | spiv: in the finally block, but yeah I see what you mean. Next time, refactor++ | 05:06 |
| * spiv nods | 05:07 | |
| stub | I suspect I have a rather unusual problem I want to solve. I have a copy of a CVS tree, and I want to export a single file and its commit history to a bzr branch. | 05:26 |
| stub | Is there any tool available that will import a single RCS style ,v file? I think it contains everything that is needed. | 05:26 |
| lifeless | spiv: test_smart vs test_smart_request | 05:34 |
| lifeless | spiv: the former has everything in it I'd expect to be in the latter | 05:34 |
| lifeless | stub: take a full copy of the CVS tree. delete everything in the module the ,v file is in except the ,v file, and move it to the top of the module | 05:34 |
| lifeless | stub: then use any CVS history importer (such as cvs-fastexport or cscvs or cvsps-import) | 05:35 |
| spiv | lifeless: yeah, I can see that. And what's in test_smart_request could stand to be split up a bit too I think. | 05:36 |
| lifeless | spiv: so I'm going to add to test_smart | 05:36 |
| lifeless | spiv: because that has the test for FindRepository | 05:36 |
| lifeless | spiv: also, exception handling | 05:37 |
| * spiv nods | 05:37 | |
| lifeless | you've been improving that, how should I handle the main failures (no bzr dir present, repository already present) | 05:37 |
| lifeless | or is it still just return an error with a custom string? | 05:38 |
| stub | lifeless: Just trying that :-) Got to the point where cvsps-import is spitting out horrible errors, possibly due to me running 1.12? AttributeError: 'MinimalTree' object has no attribute 'get_file_with_stat' | 05:38 |
| lifeless | stub: yes, seems like a version skew issue | 05:40 |
| lifeless | spiv: so errors? | 05:46 |
| spiv | lifeless: errors? | 05:53 |
| lifeless | 16:33 < lifeless> spiv: also, exception handling | 05:56 |
| lifeless | 16:33 * spiv nods | 05:56 |
| lifeless | 16:34 < lifeless> you've been improving that, how should I handle the main failures (no bzr dir present, repository already present) | 05:56 |
| lifeless | 16:34 < lifeless> or is it still just return an error with a custom string? | 05:56 |
| spiv | Oh, I totally failed to read a couple of lines of IRC. | 06:00 |
| spiv | lifeless: the currently defined errors can all be seen in the function at the bottom of bzrlib/remote.py | 06:01 |
| spiv | lifeless: no bzr dir present should be 'nobranch' on the wire IIRC, which mirrors the confusing NotBranchError that bzrlib gives. | 06:02 |
| spiv | lifeless: I don't think there's an appropriate error for repository already present. | 06:05 |
| lifeless | I'll skip that case until it turns up then :P | 06:07 |
| spiv | :) | 06:08 |
| === montywi|sleep is now known as montywi | ||
| vila | hi all | 07:04 |
| * fullermd waves vila around a bit. | 07:07 | |
| poolie | hi vila | 07:12 |
| vila | I'm sure that will make for a good quote but I can't find the right title :-) | 07:17 |
| lifeless | spiv: success | 07:21 |
| lifeless | I'm really slow today :( cotton wool in the head | 07:21 |
| lifeless | but its done | 07:21 |
| lifeless | 19 rpc's less | 07:24 |
| jfroy | so huh | 07:32 |
| jfroy | is there a fast-import importer for Subversion that does support branches and tags and such trivial things :| | 07:32 |
| Peng_ | jfroy: Does it have to be fast-import, or would bzr-svn work? | 07:33 |
| jfroy | I want to move away from svn | 07:34 |
| jfroy | completely and for ever | 07:34 |
| Peng_ | Sounds good. | 07:34 |
| jfroy | I guess I could force people to use rich roots. | 07:34 |
| jfroy | (for the particular project in question) | 07:34 |
| jfroy | But it felt that fast-import was a better fit than bzr-svn for the task of permanently migrating a set of branches. | 07:34 |
| Peng_ | Shrug. bzr-svn can do it. It doesn't stop you from moving away from svn forever. | 07:36 |
| lifeless | spiv: bombs away | 07:37 |
| lifeless | jfroy: svn-import is the recommended migration tool :) | 07:37 |
| lifeless | jfroy: if you feel strongly about rich roots you could regenerate the output via fast-export | fast-import, but I wouldn't bother. | 07:38 |
| jfroy | I don't actually know what rich roots are :p | 07:38 |
| jfroy | Beyond the concern of carrying extra data for no reason. | 07:38 |
| lifeless | its essential data we left out of the early formats | 07:38 |
| lifeless | going to extra effort not to have it would be... counterproductive | 07:38 |
| jfroy | "--standalone Create standalone branches." <-- huh | 07:40 |
| jfroy | lifeless: if it's essential, why is there still a distinction in the newer formats, e.g. 1.9 versus 1.9-rich-roots | 07:40 |
| Peng_ | jfroy: Because converting is slightly inconvenient, so it hasn't been forced on users yet. | 07:41 |
| lifeless | it takes time and effort to convert; data discrepancies can show up so care needs to be taken; abentley is going to work on the overall thing soon I believe | 07:43 |
| Peng_ | "data discrepancies"? | 07:44 |
| jfroy | I see | 07:44 |
| lifeless | Peng_: parent mismatches mainly | 07:44 |
| Peng_ | You mean it exposes standard "bzr check/reconcile" stuff, or *causes* problems? | 07:44 |
| lifeless | Peng_: exposes | 07:44 |
| Peng_ | Okay. | 07:44 |
| lifeless | Peng_: unchecked branches don't always convert completely 100%, even though they should | 07:45 |
| lifeless | we're regenerating all the inventories after all | 07:45 |
| Peng_ | That sounds ominious. | 07:45 |
| === thekorn_ is now known as thekorn | ||
| lifeless | spiv: if you're still doing stuff, network_name could use a review, as could BzrDir.create_repository RPC verb | 08:03 |
| poolie | bug 331416 sucks a bit | 08:06 |
| ubottu | Launchpad bug 331416 in gdm "gdm fails with "the greeter application appears to be crashing" after upgrading to jaunty" [Undecided,New] https://launchpad.net/bugs/331416 | 08:06 |
| mae^ | ohnoes! you have a valid .bzr control directory, but not a branch or repository. This is an unsupported configuration. Please move the target directory out of the way and try again. | 08:10 |
| mae^ | i did a push that timed out, now I'm getting that error | 08:11 |
| lifeless | spiv: also I can't see the patch you said you sent in | 08:11 |
| lifeless | mae^: right, do what it says :) | 08:11 |
| mae^ | what target directory? I'm trying to push to launchpad. | 08:13 |
| === serg_ is now known as serg | ||
| lifeless | got to launchpad, there is a 'delete branch' button on your branch | 08:13 |
| mae^ | hmm.. what if someone else has made changes to the branch that I dont have locally? tough luck? | 08:15 |
| Peng_ | If it has no branch or repository, what changes could it be storing? | 08:16 |
| mae^ | oh, I found it .. the branch location changed when I changed the branch ownership | 08:17 |
| mae^ | thx | 08:20 |
| beuno | poolie, what do you think about adding a space next to the semicolon on the progress bars? | 08:31 |
| beuno | "Build phase: Adding file contents" instead of "Build phase:Adding file contents" | 08:31 |
| lifeless | beuno: patches :) | 08:33 |
| beuno | lifeless, of course. Just wanted to get extra agreement nods :) | 08:34 |
| === montywi is now known as monty|meeting | ||
| asabil | hi all | 08:36 |
| asabil | does anyone see the problem with this code: http://bazaar.launchpad.net/~asabil/%2Bjunk/bzr-filter-branch/annotate/head%3A/__init__.py ? | 08:36 |
| asabil | I get the following traceback: http://pastebin.ca/1341535 | 08:36 |
| asabil | only when using the plugin inside a rich-root repository | 08:37 |
| Mez | jelmer: using bzr-svn can I just import it to bzr and then "forget" that it was part of svn? | 08:56 |
| Lo-lan-do | Mez: Yes. | 08:57 |
| Mez | how ? | 08:57 |
| Lo-lan-do | rm -r $svn_repo :-) | 08:57 |
| Mez | Lo-lan-do: but surely bzr will still think "oh, I'm parented to $SVN_REPO" | 08:58 |
| Lo-lan-do | Depends on how you did the import. | 08:58 |
| Peng_ | Mez: "bzr pull --remember", then? | 08:58 |
| Mez | branched svn, so I can keep the history | 08:58 |
| Lo-lan-do | If you ran "bzr checkout svn+ssh://...", then "bzr unbind" will unbind. | 08:59 |
| Lo-lan-do | If you ran "bzr branch svn+ssh://...", then you're not bound. | 08:59 |
| Lo-lan-do | bzr remembers the SVN URL as the parent location for subsequent pulls and merges, but that's about it. | 08:59 |
| Lo-lan-do | You can remove the parent_location from .bzr/branch/branch.conf if you don't like to see it in "bzr info". | 09:00 |
| === timchen1` is now known as nasloc__ | ||
| beuno | statik, has your cron for updating bzr nightly gone to sleep and not woken up again? | 09:11 |
| === thunderstruck is now known as gnomefreak | ||
| beuno | vila, why is bug 331288 incomplete? | 11:46 |
| ubottu | Launchpad bug 331288 in bzr "Push should have an option to not stack" [Undecided,Incomplete] https://launchpad.net/bugs/331288 | 11:46 |
| vila | Because I didn't have time to test that it already works and I thought the bug reporter may do that :-) | 11:46 |
| vila | beuno: well to test *again* should I say, because I indeed tested it days ago, but was in a hurry and didn't check all the things I should have checked :) | 11:47 |
| beuno | vila, so maybe add a comment? I'm sure jml will cry if he sees that you think he is incomplete | 11:48 |
| vila | by marking it incomplete, I know either jml will come back after testing or *I* will get more time to test it properly | 11:48 |
| vila | beuno: huh ? I added a comment saying it should work by using '--no-stacked' instead of '--not-stacked' | 11:49 |
| vila | I sure remember having used --no-stacked | 11:49 |
| beuno | vila, ah, I did not see that | 11:49 |
| beuno | ignore me | 11:49 |
| vila | beuno: Argh ! I hate that bug in launchpad: start typing a new comment, realize you should change the status or something, do that, watch your comment vanish :( | 11:50 |
| vila | beuno: comment added again | 11:51 |
| beuno | vila, that will be fixed soon-ish | 11:52 |
| beuno | in an ajax-y kind of way | 11:52 |
| vila | beuno: good :) | 11:52 |
| vila | beuno: so you know about the problem already ? | 11:52 |
| beuno | vila, yes, it's happened to me a few times as well | 11:56 |
| asabil | anyone ? | 12:03 |
| === UdontKnow is now known as root | ||
| === beuno is now known as beuno-lunch | ||
| === beuno-lunch is now known as beuno | ||
| === mvo__ is now known as mvo | ||
| domas | hi! how to make 'bzr log' faster? it takes >24 hours on quite powerful machine | 13:29 |
| * Lo-lan-do suddenly feels *his* performance problems are not that bad after all | 13:30 | |
| beuno | uhm | 13:31 |
| lifeless | domas: wow, it shouldn't be *that* slow | 13:31 |
| beuno | 24 hours seems a bit much | 13:31 |
| beuno | domas, what version of bzr is that using? | 13:31 |
| lifeless | domas: are you running log on a particular file, with -v, or just 'bzr log' ? | 13:31 |
| luks | it's aliased to log -v, I bet | 13:31 |
| domas | beuno: any, 1.12 | 13:31 |
| domas | lifeless: 'bzr log -v' on whole tree | 13:31 |
| domas | it allocates ~800MB of memory | 13:31 |
| domas | and oprofile says it is walking dictionaries all the time | 13:32 |
| lifeless | domas: its a known limit of bzr, it has to do a whole diff on every step in the log output; we're fixing it | 13:32 |
| domas | lifeless: I'd be happy to betatest :) | 13:32 |
| domas | any kind of caching, etc :) | 13:32 |
| lifeless | domas: there is an alpha quality branch at the moment, lp:~bzr/bzr/brisbane-core, where we are assembling the fix | 13:32 |
| domas | lifeless: interesting, thanks! | 13:33 |
| lifeless | domas: we need better disk data structures though; so there is a [somewhat costly] conversion to do to test | 13:33 |
| domas | would that take 24 hours? :) | 13:33 |
| lifeless | domas: there's also discussion on the list, and on the Roadmap page | 13:33 |
| lifeless | domas: I don't know how long it will take on your repo; if its huge or very deep history it could take a while; but I would expect a matter of hours not days | 13:34 |
| lifeless | we're only starting to optimise the conversion logic | 13:34 |
| domas | I was tempted to start hacking bzr too | 13:35 |
| lifeless | domas: I guess i'm saying - please do track this. We're planning a beta quality release for this in March | 13:35 |
| domas | it was spending way more time in walking than calculating | 13:35 |
| domas | lifeless: thanks, subscribed ;-) | 13:36 |
| lifeless | cool | 13:36 |
| lifeless | night everyone | 13:36 |
| domas | lifeless: I'm playing with opengrok | 13:36 |
| domas | it is awesome :) | 13:36 |
| domas | it has bzr integration, but thats too slow on big trees | 13:36 |
| ronny | opengrok? | 13:37 |
| domas | http://dammit.lt:8180/source/xref/mysql-5.1.31/sql/ | 13:37 |
| domas | it is source repository browser with indexing | 13:37 |
| domas | think, lxr on steroids | 13:38 |
| ronny | hmm | 13:38 |
| ronny | that reminds me how far i will have to go with anyvc if i want to make it neat | 13:38 |
| === ja1 is now known as jam | ||
| vila | jam: ping | 14:30 |
| jam | morning vila | 14:30 |
| vila | morning :) | 14:31 |
| vila | I'm trying to fix test_autopack_rpc_is_used_when_using_hpss failing for dev5 formats | 14:31 |
| vila | It turns out we don't use hpss because InterPackToRemotePack rules out the specific autopack | 14:31 |
| vila | Fixing that reveals that we don't have the right Packer | 14:32 |
| vila | Which in turn can't be easily fixed because of our design | 14:33 |
| ronny | jelmer: sup? whats missing in dulwich to give status info about the index/the workdir? | 14:33 |
| vila | jam: because Packer is the root of two class hierarchies: one for the format one for some features (like reconcile) | 14:34 |
| jam | vila: are you talking about for GC repos, or for chk repos? | 14:35 |
| jam | AIUI chk repos use the same Packer | 14:35 |
| vila | I need CHKReconcilePacker._process_inventory_lines ... somwehere it can't be accessed | 14:36 |
| ronny | jelmer: btw, any chance to move dulwich to a bsd style license? | 14:37 |
| vila | jam: hmm, I'm wrong, Packer doesn't define a hierarchy for formats, yey, I need to override Packer._process_inventory_lines without using a ReconcilePacker... | 14:39 |
| jam | So... to start with, I wasn't sure where to push in the autopack RPC, which is why I left that test alone :) | 14:40 |
| jam | I don't quite understand why to get autopack working, you need _process_inventory_lines ? | 14:40 |
| vila | jam: let's rollback | 14:41 |
| jam | As for stuff like "Packer", it would be reasonable to define class attributes | 14:41 |
| jelmer | ronny: hi | 14:41 |
| jam | So PackRepository._packer_class = Packer | 14:41 |
| jam | CHKPackRepository._packer_class = CHKPacker | 14:41 |
| jam | etc | 14:41 |
| jelmer | ronny: We'll be merging some stuff from pyrite soon, that should include an index parser | 14:41 |
| jam | or possible a registry | 14:41 |
| ronny | jelmer: an api that compares to bzr's WorkingTree.iter_changes would be nice | 14:42 |
| vila | InterPackToRemotePack rules out using InterPackToRemotePack if any of the repo supports_chks | 14:42 |
| vila | InterPackToRemotePack rules out using InterPackToRemotePack if any of the repo *doesn't* supports_chks | 14:42 |
| vila | jam: see InterPackToRemotePack.is_compatible in repository.py | 14:43 |
| vila | That seems wrong if both repo supports_chk, so I fixed that but then it fails because Packer._process_inventory_lines calls repo._find_file_ids_from_xml_inventory_lines | 14:43 |
| jelmer | ronny: wrt BSD licensing; there would have to be a very good reason, such as another Open Source project that is definitely going to use Dulwich but is blocked by the licensing | 14:44 |
| ronny | jelmer: at least lgpl? | 14:44 |
| vila | jam: but ReconcilePacker._process_inventory_lines adresses precisely that | 14:44 |
| vila | jam: is that clearer ? | 14:44 |
| vila | jam: and do you agree about InterPackToRemotePack.is_compatible ? | 14:45 |
| ronny | jelmer: since my encounter of not being able to combine different things cause one was glp2 only and the other was gpl3 only im not exactly accepting gpl any more | 14:45 |
| jelmer | ronny: dulwich is GPLv2+ at the moment | 14:46 |
| jam | vila: think you were right in your first statement. InterPackToRemotePack rules out if any repo *does* support chks | 14:46 |
| jam | Second, I don't really think we want to switch to using Packer based fetch | 14:47 |
| jam | I'm pretty sure we are trying to get away from that | 14:47 |
| jam | into the insert_record_stream(get_record_stream()) based APIs | 14:47 |
| jam | So IMO, the real fix is to help insert_record_stream() && commit_write_group() trigger a remote autopack() | 14:48 |
| jam | rather than trying to get it to use InterPackRepo code. | 14:48 |
| jam | vila: does that make sense? | 14:48 |
| vila | jam: At the highest level yes. Concretely it means I will push making that test pass lower in my task list and fix simpler ones first :) | 14:49 |
| vila | time to shelf debug statements :) | 14:50 |
| vila | jam: hmm, not yet, I should first understand where the insert_record_stream route will start | 14:50 |
| vila | s/will start/should start/ | 14:50 |
| jelmer | ronny: I wouldn't be opposed to LGPL, but there would have to be a good enough reason and of course everybody else involved would have to be ok with relicensing as well | 14:51 |
| ronny | hmk | 14:53 |
| jam | vila: also note that Robert and Andrew are working on a new fetch command | 14:53 |
| jam | which also should be preferred to Packer based work | 14:54 |
| jam | and deals with Remote calls | 14:54 |
| jam | as there is some overlap here, I agree that we should wait | 14:54 |
| jam | if you *want* turn those into KnownFailure | 14:54 |
| jam | with a comment like | 14:54 |
| vila | jam: reason enough to wait ? Or can you point | 14:54 |
| jam | "Remote autopack calls is being postponed for improved fetching" | 14:54 |
| vila | lol, s/RETURN/DELETE/ :) | 14:54 |
| vila | jam: deal, I'll do that | 14:55 |
| beuno | statik, has your cron for updating bzr nightly gone to sleep and not woken up again? | 15:02 |
| statik | beuno: oh my i hope not. | 15:02 |
| * statik looks | 15:02 | |
| statik | beuno: they are confused with this error: bzr: ERROR: Unknown repository format: 'Bazaar RepositoryFormatKnitPack6 (bzr 1.9)\n' | 15:04 |
| * statik upgrades bzr on the build machine | 15:05 | |
| beuno | statik, ah! the build machine doesn't install it's own versions? :) | 15:05 |
| statik | beuno: all fixed, and new packages are churning in the PPA now. thanks for letting me know it was stalled! | 15:20 |
| beuno | statik, awesome, thanks for keeping this rolling, it's very useful to dogfood this stuff | 15:21 |
| statik | np, i'm happy to be able to help the project in a small way | 15:21 |
| vila | jam: in bzrdir.py we replaced bzrlib.workingtree_4.WorkingTreeFormat4 by bzrlib.workingtree.WorkingTreeFormat4. Is there a resaon for not doing the same for bzrlib.workingtree_4.WorkingTreeFormat5 ? | 15:41 |
| jam | no | 15:43 |
| jam | we should use the workingtree.XXX ones | 15:43 |
| vila | ok, will fix it in bzr.dev then | 15:44 |
| vila | jam: already fixed there by.... you :) | 15:56 |
| jam | yep, I thought so | 15:56 |
| asabil | anyone to help out with the multiple root issue ? | 16:07 |
| === kiko is now known as kiko-fud | ||
| === nekohayo_ is now known as nekohayo | ||
| === Guest94594 is now known as jelmer | ||
| jam | statik: i'm gettting "build failures" fo rthe ~bzr-nightly-ppa | 16:41 |
| jam | do you know why? | 16:42 |
| === jfroy|work is now known as jfroy | ||
| statik | jam: i don't, i just fixed the system to start uploading daily builds again a couple hours ago (it was failing due to an old version of bzr on the build machine not understanding the branch format). | 17:26 |
| statik | jam: i'll try to take a look today and see what is failing | 17:26 |
| mwhudson | beuno: thanks for the LH reviews :) | 17:31 |
| beuno | mwhudson, I tried to eat through as much LH as I could. Not sure if I managed or not. | 17:32 |
| mwhudson | did you manage to try the diff js goo in IE? | 17:33 |
| beuno | no, I'm in Berlin still | 17:34 |
| beuno | and not back home til next week | 17:34 |
| beuno | where I have all the evil stuff like windows machines | 17:34 |
| mwhudson | ok | 17:35 |
| mwhudson | i'll merge anyway i think :) | 17:35 |
| beuno | yeah, we can fix it later on | 17:35 |
| vila | jam: nearly off for the day, I pushed revno 3832 to bbc, the test suite is passing except for 1 failure and 4 errors | 17:38 |
| === jkakar_ is now known as jkakar | ||
| vila | jam: 2 errors being AttributeError: 'CHKInventory' object has no attribute 'apply_delta' coming from bzrlib.tests.test_repository.TestDevelopment5FindRevisionOutsideSet, so dev5 specific | 17:39 |
| mwhudson | hm | 17:41 |
| mwhudson | i' | 17:41 |
| mwhudson | i'm not sure i like the level of deviousness you can use in css | 17:42 |
| mwhudson | all too tempting :) | 17:42 |
| vila | mwhudson: Just do as you I feel, you will regret it anyway :) | 17:42 |
| vila | mwhudson: Just do as you feel, you will regret it anyway :) | 17:43 |
| vila | and one more joke ruined by a typo :) | 17:43 |
| mwhudson | heh | 17:43 |
| mwhudson | beuno: got time to give a visual opinion on coloring line numbers? | 17:44 |
| beuno | mwhudson, I hear we will eventually get a full blown operating system made in css | 17:45 |
| beuno | sure, shoot | 17:45 |
| mwhudson | beuno: :) | 17:47 |
| mwhudson | beuno: wondering what colour the indicated "cells" should be http://people.ubuntu.com/~mwh/ss.png | 17:47 |
| beuno | mwhudson, one line is for removes | 17:48 |
| beuno | and the other for adds, right? | 17:48 |
| beuno | ah | 17:48 |
| mwhudson | yes | 17:48 |
| beuno | ok | 17:48 |
| beuno | so | 17:48 |
| beuno | how about a lighter tone of red, and a lighter tone of green? | 17:49 |
| mwhudson | hm, that probably works | 17:49 |
| Lo-lan-do | Maybe do both cells as light red and both cells as light green? | 17:51 |
| Lo-lan-do | (Yay bikeshedding) | 17:51 |
| mwhudson | beuno: try lp:~mwhudson/loggerhead/unified-by-default-sbs-by-ajax rev 287 | 18:00 |
| beuno | mwhudson, I like it! | 18:02 |
| mwhudson | beuno: cool | 18:03 |
| mwhudson | i replied to your review, but i think i'm going to merge the branch now | 18:03 |
| beuno | mwhudson, sure, I'll reply back, but as I said, it's in a good state to land | 18:04 |
| mwhudson | cool | 18:04 |
| mwhudson | beuno: i spent most of yesterday when i wasn't being the CHR dude trying to move away from mootools, btw | 18:07 |
| beuno | mwhudson, oh, that sounds like a fantastic thing to do | 18:09 |
| beuno | the slider animations are going to be a PITA | 18:09 |
| mwhudson | yeah, the animations are just commented out at the moment | 18:09 |
| mwhudson | there seem to be totally weird ass interactions between window.addEvenHandler (mootools) and Y.on() (yui) wrt domready :/ | 18:10 |
| mwhudson | beuno: oh right, something I meant to ask | 18:10 |
| mwhudson | beuno: i don't really understand how to spread code between different js files but have them share a Y object | 18:11 |
| statik | jam: the nightly build seems to be failing because it's trying to use python2.6. Any idea why? http://launchpadlibrarian.net/22882024/buildlog_ubuntu-jaunty-i386.bzr_1.13~bzr9.04-4020-1_FAILEDTOBUILD.txt.gz | 18:11 |
| statik | jam: I'm building the source packages on a hardy machine, definitely don't have any python2.6 there | 18:12 |
| jam | statik: I don't know. Is python2.6 the default python on jaunty ? | 18:12 |
| jam | That said, we *should* support python2.6 | 18:12 |
| jam | as vila works hard to ensure compatibility | 18:13 |
| mwhudson | i think jaunty might *only* have 2.6... | 18:13 |
| statik | jam: no, it's not even available in jaunty. yeah, things should absolutely run with python2.6, but the problem is that it's not installed in the chroot in the buildd | 18:13 |
| jam | I see what you mean, though: | 18:13 |
| jam | cd . && python2.6 setup.py build --build-base="/build/buildd/bzr-1.13~bzr9.04-4020/./build" --executable "/usr/bin/python" /bin/sh: python2.6: not found make: *** [python-build-stamp-2.6] Error 127 dpkg-buildpackage: failure: debian/rules build gave error exit status 2 | 18:14 |
| statik | xactly | 18:14 |
| beuno | mwhudson, I've been trying to get that sliding animation to work in lzr-js. Will let you know if I do. | 18:14 |
| jam | that is part of "update-config" | 18:14 |
| jam | can you check your packaging branch? | 18:14 |
| statik | sure, will have a look now | 18:14 |
| jam | It at least seems to be generated from "debian/rules" | 18:14 |
| beuno | mwhudson, as to sharing a Y object among different files... it sounds tricky | 18:14 |
| jam | And it is possible that the latest version from jelmer (for debian) uses python2.6 | 18:14 |
| === mvo_ is now known as mvo | ||
| statik | thats probably what it is | 18:16 |
| jelmer | jam: debian doesn't have python2.6 yet :-) | 18:20 |
| statik | jelmer: yeah, i'm stumped where this reference to 2.6 is coming from | 18:21 |
| jam | statik: It sure looks like it is something with the build daemons themselves | 18:21 |
| jam | the first thing it does is: | 18:21 |
| jam | dh_clean cd . && python2.6 setup.py clean -a /bin/sh: python2.6: not found make: [python-clean-2.6] Error 127 (ignored) cd . && python setup.py clean -a | 18:21 |
| jam | statik: I'm also seeing a problem with "Pyrex" not being found | 18:22 |
| jam | which would also be sort of a bad thing for the final built versions | 18:22 |
| jam | since they don't have the .c extensions | 18:22 |
| jam | I suppose we are a bit stuck.... | 18:23 |
| statik | jam: yeah, the packaging doesn't Build-Depends on python-pryex | 18:23 |
| jam | we don't really want to depend on Pyrex for the final build, because we put the .c files in the tarballs | 18:23 |
| jam | but for intermediate ones | 18:23 |
| jam | we don't bother | 18:23 |
| jelmer | statik: if you have 2.6 it might be trying it if it is thre defualt python | 18:29 |
| jelmer | statik: we just define that we support all pythons since 2.4 | 18:29 |
| statik | jelmer: i don't, thats the weird thing. I'm building a source package on hardy, and uploading it to a jaunty PPA on launchpad | 18:29 |
| statik | and python2.6 is nowhere in sight | 18:29 |
| jelmer | statik: strange indeed :-/ | 18:42 |
| james_w | one thing is that it lists python2.4-dev, python2.5-dev when python-all-dev is probably a good idea | 18:44 |
| james_w | it may be that it got caught in the middle when python2.6 was only partly default | 18:45 |
| === chx is now known as chx_sleeping | ||
| jelmer | james_w: ah, good point | 19:19 |
| === kiko is now known as kiko-afk | ||
| jelmer | james_w: strange, it's fine in the version in Debian | 20:16 |
| === root is now known as UdontKnow | ||
| ronny | lifeless: any plans to have signed tags? (something like git's tag object) | 20:41 |
| jelmer | ronny: fwiw, there are already signed revisions | 20:42 |
| ronny | jelmer: yeah, but not tags | 20:47 |
| ronny | hmm | 20:47 |
| ronny | time to add push/pull support to anyvc | 20:48 |
| mwhudson | hm | 21:05 |
| mwhudson | bzr search -s just broke on me | 21:05 |
| mwhudson | oh, my bzr-search was way out of date | 21:07 |
| lifeless | ronny: I thought gits tag object was just a blob/commit - I didn't see a special object type for it | 21:17 |
| lifeless | asabil: I don't hink anyone trivially knows | 21:18 |
| ronny | lifeless: its an own object type | 21:18 |
| lifeless | asabil: I know I probably need to jump into a debugger to figure it out | 21:18 |
| ronny | they have blob, tree, commit, tag | 21:18 |
| lifeless | asabil: perhaps mail the list? | 21:18 |
| ronny | tags can be put on any objects | 21:18 |
| lifeless | ronny: ok | 21:18 |
| ronny | (ie also blobs/trees) | 21:18 |
| Obmar | Hi there, hopefully I am not asking a question that has been asked 1000 times before, but here goes. I have bzr on my local computer. I have init the project, add the files, commit the project. Now I am trying to merge it to a centralized copy. I have bind and merge and commit, but the files are not on the server. The .bzr folder is there, and it says everything is fine, but the actual source code files are not in the folder. What could I possibly be doin | 21:24 |
| garyvdm | Obmar: 1. did you push to the central server? | 21:24 |
| Obmar | Yes. | 21:25 |
| Obmar | This is to a ftp://... if that makes any difference. | 21:25 |
| RAOF | Obmar: bzr doesn't update the working tree when pushing. This is what you're seeing. | 21:25 |
| garyvdm | Obmar: 2. When you push to a remote protocal - it does not update the working tree. | 21:25 |
| Obmar | The project folder did not exist before, but it was created, along with the .bzr subfolder. | 21:25 |
| garyvdm | Obmar: Is this for a website? | 21:26 |
| Obmar | So... maybe I am confused, how do I get it to update the working tree on the server? | 21:26 |
| ronny | Obmar: all the history is within the bzr folder | 21:26 |
| Obmar | garyvdm: No. | 21:26 |
| === chx_sleeping is now known as chx | ||
| ronny | Obmar: is this for some software on the server, or do you just need a repository there? | 21:26 |
| Obmar | Just the repository. | 21:27 |
| ronny | Obmar: if all you want to do is keep the history there, then you dont need to update on the server-side | 21:27 |
| Obmar | But I develop on serveral different computers. | 21:27 |
| Obmar | I need all the files and the history there. | 21:27 |
| ronny | Obmar: you dont need a workingtree on the server, only the .bzr folder with the history | 21:27 |
| Obmar | So when I go to a new computer, how will I work on the code? | 21:27 |
| ronny | or is this an actual software that has to run on the server? | 21:27 |
| ronny | Obmar: you pull the history | 21:27 |
| Obmar | No, it does not run on the server. | 21:28 |
| ronny | Obmar: the history implies the files | 21:28 |
| Obmar | Are they in that subfolder somewhere then? | 21:28 |
| Obmar | the .bzr folder I mean? | 21:28 |
| ronny | Obmar: the history is in the .bzr dir | 21:28 |
| Obmar | Ah, so it is not going to look like my local copy. | 21:28 |
| Obmar | Since I have .bzr, src/, build, etc... | 21:29 |
| Obmar | But I only see .bzr on the server copy. | 21:29 |
| ronny | Obmar: on your local copy you have a branch with a working directory, on the server you only need the branch, not the working directory | 21:29 |
| Obmar | Ok, I think I follow. | 21:29 |
| Obmar | So the files are safely up there then. | 21:29 |
| Obmar | I was getting a bit worried. | 21:29 |
| Obmar | So when I do a pull on a different computer, I will get a working directory there? | 21:30 |
| ronny | yes | 21:30 |
| Obmar | Ah ha. That is what I was missing. | 21:30 |
| Obmar | So I was doing it right. Just missed a concept. | 21:30 |
| Obmar | Ok, second question, only sort of related. I am using Eclipse, and I have the bzr plugin installed, but the only options under the team menu is Apply Patch and Disconnect. All the other options are disabled (greyed out) | 21:31 |
| ronny | no idea about eclispe | 21:31 |
| Obmar | lol | 21:32 |
| Obmar | Hopefully somebody does. | 21:32 |
| ronny | i avoid it as its mostly wasting my ram and cpu time | 21:32 |
| ronny | same goes for netbeans and other fscking big & laggy ide's | 21:32 |
| Obmar | It is big. Agreed. | 21:33 |
| Obmar | It is what I hae for now. | 21:33 |
| Obmar | It would be nice if I could get the bzr integration working though. | 21:33 |
| lifeless | Obmar: did you follow the bzr eclipse faq? | 21:34 |
| Obmar | Yes, as best as a could. | 21:34 |
| Obmar | It is installed. | 21:34 |
| Obmar | And the init command works. | 21:34 |
| Obmar | The rest are disabled though. | 21:34 |
| ronny | hmm | 21:37 |
| lifeless | verterok: ^ | 21:37 |
| lifeless | Obmar: verterok is the author | 21:37 |
| Obmar | verterok: Any ideas? | 21:38 |
| Obmar | So... on question 1... I have a local repository.. the best path to "upload" that to the server is... push/bind/commit? | 21:40 |
| Obmar | I mean, is that the right order? | 21:40 |
| ronny | Obmar: if you bind, it will imply that each commit is pushed, thats nice for working on more than one computer, but not so nice if you want to work as interuption-free as possible | 21:41 |
| ronny | lifeless: btw - i think i need bzr at least twice as fast as its currently | 21:42 |
| Obmar | I like the bind idea, for me at least. I am on fast links between all the locations. | 21:42 |
| ronny | Obmar: ah, ok | 21:43 |
| Obmar | One less thing to worry about. | 21:43 |
| poolie | hello all | 21:43 |
| Obmar | I just have to update...work...commit | 21:43 |
| Obmar | I think that is all I have to do, if I understand the docs correctly. | 21:43 |
| ronny | Obmar: im not fluent on the bind workflow, im on slow links/disconnected often | 21:44 |
| lifeless | ronny: ok | 21:49 |
| lifeless | ronny: we're working on that :P | 21:49 |
| spiv | lifeless: gar, I screwed up my from address when sending a patch yesterday, re-sent. | 21:50 |
| igc | morning | 21:53 |
| poolie | hello igc | 21:56 |
| poolie | today is going to be a good day for you :) | 21:56 |
| poolie | i have a big block in my diary for content flittering | 21:56 |
| lifeless | spiv: ah :P | 21:58 |
| verterok | lifeless: thanks & hi | 21:58 |
| verterok | Obmar: hi | 21:58 |
| verterok | Obmar: could you check if there are errors in the error log view? | 21:59 |
| verterok | Obmar: or in $WORKSPACE/.metadata/.log, related to bzr-eclipse? | 21:59 |
| Obmar | verterok: http://pastebin.com/m6b21c84d | 22:01 |
| Obmar | Looks like it | 22:01 |
| igc | hi poolie. Time for a review today? :-) | 22:01 |
| poolie | exactly | 22:01 |
| poolie | see above | 22:02 |
| verterok | Obmar: what version of xmloutput have you installed? | 22:02 |
| verterok | Obmar: let me guess: bzr 1.12 and bzr-xmloutput <= 0.8.2? | 22:03 |
| Obmar | Not sure how to tell. | 22:03 |
| Obmar | verterok: Genius. | 22:05 |
| Obmar | I didnt know which one. | 22:05 |
| Obmar | So I went and got the latest. | 22:05 |
| Obmar | All the menu options lit right up. | 22:05 |
| Obmar | Thank you. | 22:06 |
| verterok | Obmar: no problem, glad to help | 22:08 |
| * verterok back to the sprint, bbl | 22:08 | |
| Obmar | verterok: Still here? | 22:09 |
| Obmar | verterok: Trying to authenticate against FTP. | 22:09 |
| === serg is now known as serg|away | ||
| === serg|away is now known as serg | ||
| Obmar | verterok: Nevermind just saw the limitations part of the site. | 22:10 |
| lifeless | spiv: with patch please :) | 22:10 |
| asabil | lifeless: ok thanks, I just sent a mail to the ML | 22:27 |
| lifeless | spiv: reviewed; needs a little work | 22:32 |
| lifeless | spiv: I forgot a vote line - bb:tweak | 22:32 |
| jml | :( | 22:46 |
| lifeless | jam: ping; like to high bandwidth discuss network_name | 22:46 |
| jml | I'm pushing up a stacked branch to Launchpad, one that's already been pushed, and it is still pushing after ~40mins | 22:46 |
| lifeless | jml: anything in the log? | 22:47 |
| jml | yeah. | 22:47 |
| lifeless | are you sure its stacked? | 22:47 |
| jml | It was, at least: https://code.edge.launchpad.net/~jml/launchpad/cloud-style-changes | 22:47 |
| lifeless | jml: 'bzr info lp:~jml/launchpad/cloud-style-changes' should tell you | 22:48 |
| jml | lifeless: the Launchpad page I referred you to does basically the same thing :) | 22:48 |
| jml | but still | 22:49 |
| jml | stacked on: /~launchpad-pqm/launchpad/devel | 22:49 |
| poolie | jam, thanks for your comments on the EC2 thing. i replied - how does that idea suit you of just leaving it up? | 22:49 |
| jml | lifeless: https://pastebin.canonical.com/14025/ | 22:50 |
| jml | lifeless: the logs are filled with variations on that. | 22:50 |
| lifeless | jml: its probing for a tonne of revisions it doesn't have | 22:51 |
| jml | lifeless: what's causing that? | 22:53 |
| jml | and what do I do about it? | 22:53 |
| lifeless | jml: I don't know and let it run | 22:53 |
| lifeless | file a bug afterwards with the log (trimmed to elide the repeated sections in the middle) | 22:54 |
| poolie | igc, could you see today or soon about updating orcadas to run more benchmarks, including if possible the network ones? | 22:54 |
| poolie | there should now be scripts there that let us turn on the slow network | 22:54 |
| jml | HPSS calls: 7898 <bzrlib.smart.medium.SmartSSHClientMedium object at 0x29a7b50> :) | 22:55 |
| jml | it just finished then. | 22:55 |
| spiv | walk_to_common_revisions is the usual problem. | 22:58 |
| lifeless | I've 3 branches pending, all approved except the bottom one (network-names) | 23:01 |
| lifeless | I get the feeling jam is done for the day, he commented - if someone could review and read our thread that would be great | 23:02 |
| jelmer | lifeless: fwiw I'm happy to review some of the smart server stuff | 23:06 |
| lifeless | jelmer: anytime :) | 23:07 |
| jml | lifeless: https://bugs.edge.launchpad.net/bzr/+bug/331823 fwiw | 23:07 |
| ubottu | Ubuntu bug 331823 in bzr "Pushing an update of a stacked branch to Launchpad sometimes takes nearly an hour" [Undecided,New] | 23:07 |
| lifeless | jelmer: the Repository.initialize branch probably addresses some of your 'getting branches we can't use' issues | 23:09 |
| jelmer | lifeless: ok, I'll have a look | 23:10 |
| igc | poolie: I'd like to leave that to Monday if I can - knee deep in code today that I need to get running before the weekend | 23:10 |
| lifeless | jelmer: the network-name one is the only currently unapproved one | 23:10 |
| lifeless | ok, running a full regression and getting food concurrently | 23:10 |
| igc | poolie: as then I can run some big imports on the weekend | 23:10 |
| jelmer | lifeless: I don't feel comfortable enough with that code to do review | 23:11 |
| lifeless | jelmer: ok | 23:11 |
| lifeless | jelmer: given all the work you do with custom formats I'm surprised though :) | 23:11 |
| poolie | igc, ok makes sense | 23:12 |
| jelmer | lifeless: that bit isn't the problem :-) It's more the smart server side of things | 23:13 |
| lifeless | network-name doesn't touch the smart server | 23:18 |
| * igc breakfast | 23:20 | |
| jelmer | lifeless: The code seems ok, the problem is the rationale behind the change | 23:22 |
| === TheMuso_ is now known as TheMuso | ||
| jelmer | lifeless: In particular, you seem to make it possible to have streams that are not necessarily tied to a particular bzrdir format | 23:39 |
| jelmer | lifeless: and potentially having multiple repository formats returning the same string | 23:39 |
| jelmer | lifeless: wouldn't you just want a different format object for the stream ? | 23:42 |
| lifeless | jelmer: they are tied to a particular repository format | 23:46 |
| lifeless | jelmer: bzrdir formats are not particularly useful for the metadir set of flavours | 23:46 |
| lifeless | jelmer: its a registry, so we have the registry uniqueness guarantee (and repositories *could* claim to be a byte-compatible format for compatibility, on the wire) | 23:47 |
| lifeless | jelmer: so consider knits - the record_stream from knits, pack-0.92 are identical | 23:47 |
| lifeless | from pack-1.6 and pack-1.9 they are identical too | 23:47 |
| lifeless | the different between knits, pack-0.92 and pack-1.6,pack-1.9 is that the latter may generate different parents for file texts during reconcile, but for network streams all four will be identical - same serialisers | 23:49 |
| lifeless | jelmer: so the goal is to be able to reconstitute a RepositoryFormat object in the smart server, to handle the stream even though we don't have the source repository available | 23:50 |
| lifeless | brb | 23:50 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
