[00:18] whoops [00:18] i broke bze [00:18] bzr === Iso_ is now known as IsoSchiz [00:19] http://pastebin.com/m3850ffa2 [00:20] Kobaz: you upgraded bzr, but have an old bzrtools shelf [00:20] Kobaz: you can use "bzr shelve1"/"bzr unshelve1" to keep using the bzrtools shelf, IIRC. [00:20] oh [00:21] should probably be a warning for that or something [00:22] ii bzr 1.10-1~bazaar1~intrepid1 easy to use distributed version control syst [00:22] ii bzrtools 1.10-1~bazaar1~intrepid1 Collection of tools for bzr [00:22] both are the same version [00:23] Right; what happened was that bzr shelve became part of the core, rather than provided only by a plugin. [00:23] k [00:23] But the implementation in the core is new and improved compared to the bzrtools one :) [00:23] k [00:23] so how would i use the new one? [00:24] "bzr shelve", in theory. [00:24] hmm [00:24] but that is what croaked [00:24] I'm not sure why it's breaking for you, there seems to be a broken shelve file there. [00:25] My guess is it's a bzrtools shelf, but that's just a guess. [00:25] I could easily be wrong about that... [00:25] Please file a bug. At a minimum it shouldn't give a traceback just because of a damaged file. [00:26] k [00:31] There already exists a bug for that. [00:32] Bug 303569. [00:32] 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:33] Kobaz: ^ [00:33] spiv: ping [00:34] 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:///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] IsoSchiz: your coment cuts off at 'abruptly a' [00:34] Darn it. :-) Ok, after that it goes: [00:35] rather ironic I thought [00:35] 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] Yes, it is rather.. [00:35] IsoSchiz: svn-import creates a set of branches [00:35] so run 'bzr branches endets' and you should get the relative url of the branches it made [00:35] lifeless: pong [00:36] That gives no output at all... [00:36] spiv: I want to chat [irc] briefly about a refactoring [00:36] IsoSchiz: so, it sounds like it may have errored/failed - what return code did it give? Is there anything in ~/.bzr.log [00:38] 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] The svn-import command ends with: 202.125 return code 0 - I haven't checked that's actually the return code though. [00:38] lifeless: fire away [00:38] 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:39] spiv: format.intialize_on_transport() is the code called to make a .bzr dir [00:39] spiv: MetaDirFormat is the concrete class used [00:40] spiv: so I'm thinking in MDF' initialize_on_transport can do a check to see if there is a remote capable transport [00:41] now the question [00:42] at this point I could create a RemoteBzrDirFormat and pass on the format details to it [00:42] and then call that new instance's initialize_on_transport [00:42] or I could do something different [00:43] making a RemoteBDF seems appropriate to me [00:44] Should the Windows installers work on 64-bit Windows? [00:44] Hmm. So asking a MDF to initialize_on_transport might actually give you a Remote thing instead? [00:44] That feels a bit weird, but I don't know of anything that would actually break. [00:45] spiv: ok [00:45] spiv: do you know of a good place to put a test that this happens? [00:45] 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] IsoSchiz: are there any subdirs in the output? [00:46] 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] lifeless: Only the .bzr, which contains branch-format, branch-lock/, README, repository/ and svn-import-revision [00:46] spiv: we have that [00:47] IsoSchiz: sounds like its not finding any branches to import [00:47] Well there's TestBzrDirFormat in test_bzrdir, yeah [00:47] IsoSchiz: have you tried the simpler 'bzr svn-impoprt svn+ssh:///var/repository outputdir' [00:47] I'd probably lean towards adding it there, I think. [00:48] lifeless: I am just trying that now :-) [00:51] lifeless: slightly more exciting: bzr branches now prints a blank line. :-) [00:52] 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:53] 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:55] lifeless: Is there a PPA containing these for Intrepid? Or do I need to install manually? [00:57] IsoSchiz: yes [00:57] IsoSchiz: http://bazaar-vcs.org/Download [00:58] Q about this tutorial: http://doc.bazaar-vcs.org/bzr.dev/en/tutorials/centralized_workflow.html [01:00] It says create a new branch by first doing "bzr init REMOTE/newbranch" then "bzr checkout REMOTE/newbranch" locally. [01:00] Seems like it's also legit to do "bzr init LOCAL/newbranch" and later "bzr branch LOCAL/newbranch REMOTE/newbrach" [01:01] yes [01:01] Sound ok? [01:01] + bzr bind REMOTE/newbranch [01:01] bob2: Ok, yeh, bind if you want automatic pushes. [01:02] if you don't do bind, they do NOT do the same thing [01:02] bob2: ok. I see. [01:02] but both are reasonable ways to use it [01:03] bob2: and if you don't bind, then "bzr send" will do the equvalent of "hg push" [01:04] bob2: ? (if you know hg at all...) [01:04] no idea what hg push does [01:04] bzr send will generate a bundle (ie patch with metadata) and dump it in a file or open your email client [01:05] It send revisions in the local branch that aren't in the remote branch to the remote branch. [01:05] bzr push will push changes back to the remote branch [01:05] Ohh.. ok yeh that's the equiv of "hg push" [01:06] bzr send is I guess analogous to "hg bundle", though sounds like it does a bit more. [01:08] hg bundle just doesn't have the --mail-to option. [01:08] bob2: thanks! [01:10] spiv: I'm moving the smart call log to TestCaseWithMemoryTranspirt [01:13] 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] lifeless: +1 [01:15] lifeless: I've been increasingly tempted to add something like "start a smart server backed by self.get_url(...)" to TestCaseWithMemoryTransport too [01:17] IsoSchiz: I suggest filing a question on bzr-svn [01:19] lifeless: never done that before. Is this some feature of Launchpad? Perhaps the 'Answers' section...? [01:20] Ok, worked that out, ignore the last question. [01:21] Thanks for your help lifeless. [01:23] IsoSchiz: np [01:30] spiv: so, its 15 round trips to init a bzr meta dir remotely [01:30] spiv: hows the polish on that branch coming [01:59] spiv: 15 -> 2 for initialize_on_format [02:01] that sounds like a nice improvement :) [02:07] mwhudson: cheap too, server already has the RPC [02:08] it's use got lost during stacking cloning behaviour rearrangments [02:08] oh right [02:09] bundle sent [02:15] lifeless: thanks! [02:15] lifeless: you forgot to mention that this also fixes initial push in a format unknown to the remote server [02:15] which I think has a bug or two open [02:16] jelmer: I don't think it alters that case at all [02:18] lifeless: not completely, no [02:18] lifeless: but at least you don't end up with a unusable branch on the remote side [02:19] oh, you do [02:19] it just gives the warning earlier [02:19] never mind me [02:23] jelmer: :P [02:23] I guess I was just too eager to see that bug fixed... [02:25] :) [02:43] * igc lunch === abentley1 is now known as abentley [03:20] so jelmer [03:20] if you read my patch, you could bb:approve it :) [03:22] i'm going to push that EC2 build and its docs along a bit further [03:33] 40 calls to do init-repo url [03:45] down from 100? [03:45] no [03:45] tested right now as a reasonable component to measure while working on push [03:54] spiv: ping; a test for a new verb - its test_remote for the client, test_smart for the request method backend? [03:54] jam, if you're still up, which i suppose you're not, i'm going to mess with the ec2 machine now [04:04] lifeless: that's right [04:04] lifeless: nice results for the RPC count [04:04] lifeless: I just fired off external_references / scan_unvalidated_index patch. === abentley1 is now known as abentley [04:35] 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] spiv: I'd be happier using a hook to capture the calls and assert that it tried a newer one, and worked. [04:36] spiv: assuming there is some way to say 'give me a old server' [04:36] spiv: -> is there? [04:39] An old server? bzr-v2:// ? [04:40] let me pastebin my 'old servers work test' one sec [04:40] (The client code usually knows better than to try new methods if the protocol encoding is only v2) [04:42] You could also modify the request_handlers dict buried in the server instance somewhere... [04:44] spiv: uhm [04:44] so I don't really care if its a really-old-server [04:44] or just the server-before-I-write-this-method [04:45] http://paste.ubuntu.com/119949/ [04:45] I want to be able to have that be the test [04:45] because it seems clear and complete, if we can be sure the server doesn't support the verb [04:46] thoughts/suggestions? [04:47] TestRemotePackRepositoryAutoPack.test_backwards_compatibility does a small monkey-patch to achieve something a bit similar [04:48] I don't quite follow the intent of that pastebinned test, though. [04:49] Why is asserting that exactly 1 BzrDir.create_repository call a test that the client is backwards compatible with old servers? [04:49] well [04:49] we should try the call (most servers will be up to date [04:49] and it should still work :) [04:50] we shouldn't try more than once [04:50] Oh, the missing bit of that test as written is the bit that makes that call not exist on the server? [04:51] yes [04:51] 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] But the existing logging doesn't lend itself to that... [04:51] does the smart server client hook show the result? [04:52] I don't think the precision gained is that important, if we're sure the server can't handle the call [04:52] we can test that by calling it directly, if we care [04:52] It doesn't, but it'd be nice if it did. [04:53] A brief comment can make it clear enough, we don't have to fall down a rabbit-hole... [04:57] So I think ideally you'd be able to modify the server in the test to have no implementation for that method. [04:57] 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:58] You could modify the global request_handlers registry, though. [04:59] yeah try:finally for the win [05:00] Yeah. Or addCleanup, and hide all the mucking about in a helper. [05:02] http://paste.ubuntu.com/119961/ [05:02] well [05:02] one line != mucking aorund [05:04] I count six, but sure. The test is readable enough. [05:06] spiv: in the finally block, but yeah I see what you mean. Next time, refactor++ [05:07] * spiv nods [05:26] 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] Is there any tool available that will import a single RCS style ,v file? I think it contains everything that is needed. [05:34] spiv: test_smart vs test_smart_request [05:34] spiv: the former has everything in it I'd expect to be in the latter [05:34] 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:35] stub: then use any CVS history importer (such as cvs-fastexport or cscvs or cvsps-import) [05:36] 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] spiv: so I'm going to add to test_smart [05:36] spiv: because that has the test for FindRepository [05:37] spiv: also, exception handling [05:37] * spiv nods [05:37] you've been improving that, how should I handle the main failures (no bzr dir present, repository already present) [05:38] or is it still just return an error with a custom string? [05:38] 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:40] stub: yes, seems like a version skew issue [05:46] spiv: so errors? [05:53] lifeless: errors? [05:56] 16:33 < lifeless> spiv: also, exception handling [05:56] 16:33 * spiv nods [05:56] 16:34 < lifeless> you've been improving that, how should I handle the main failures (no bzr dir present, repository already present) [05:56] 16:34 < lifeless> or is it still just return an error with a custom string? [06:00] Oh, I totally failed to read a couple of lines of IRC. [06:01] lifeless: the currently defined errors can all be seen in the function at the bottom of bzrlib/remote.py [06:02] lifeless: no bzr dir present should be 'nobranch' on the wire IIRC, which mirrors the confusing NotBranchError that bzrlib gives. [06:05] lifeless: I don't think there's an appropriate error for repository already present. [06:07] I'll skip that case until it turns up then :P [06:08] :) === montywi|sleep is now known as montywi [07:04] hi all [07:07] * fullermd waves vila around a bit. [07:12] hi vila [07:17] I'm sure that will make for a good quote but I can't find the right title :-) [07:21] spiv: success [07:21] I'm really slow today :( cotton wool in the head [07:21] but its done [07:24] 19 rpc's less [07:32] so huh [07:32] is there a fast-import importer for Subversion that does support branches and tags and such trivial things :| [07:33] jfroy: Does it have to be fast-import, or would bzr-svn work? [07:34] I want to move away from svn [07:34] completely and for ever [07:34] Sounds good. [07:34] I guess I could force people to use rich roots. [07:34] (for the particular project in question) [07:34] But it felt that fast-import was a better fit than bzr-svn for the task of permanently migrating a set of branches. [07:36] Shrug. bzr-svn can do it. It doesn't stop you from moving away from svn forever. [07:37] spiv: bombs away [07:37] jfroy: svn-import is the recommended migration tool :) [07:38] 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] I don't actually know what rich roots are :p [07:38] Beyond the concern of carrying extra data for no reason. [07:38] its essential data we left out of the early formats [07:38] going to extra effort not to have it would be... counterproductive [07:40] "--standalone Create standalone branches." <-- huh [07:40] 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:41] jfroy: Because converting is slightly inconvenient, so it hasn't been forced on users yet. [07:43] 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:44] "data discrepancies"? [07:44] I see [07:44] Peng_: parent mismatches mainly [07:44] You mean it exposes standard "bzr check/reconcile" stuff, or *causes* problems? [07:44] Peng_: exposes [07:44] Okay. [07:45] Peng_: unchecked branches don't always convert completely 100%, even though they should [07:45] we're regenerating all the inventories after all [07:45] That sounds ominious. === thekorn_ is now known as thekorn [08:03] spiv: if you're still doing stuff, network_name could use a review, as could BzrDir.create_repository RPC verb [08:06] bug 331416 sucks a bit [08:06] 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:10] 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:11] i did a push that timed out, now I'm getting that error [08:11] spiv: also I can't see the patch you said you sent in [08:11] mae^: right, do what it says :) [08:13] what target directory? I'm trying to push to launchpad. === serg_ is now known as serg [08:13] got to launchpad, there is a 'delete branch' button on your branch [08:15] hmm.. what if someone else has made changes to the branch that I dont have locally? tough luck? [08:16] If it has no branch or repository, what changes could it be storing? [08:17] oh, I found it .. the branch location changed when I changed the branch ownership [08:20] thx [08:31] poolie, what do you think about adding a space next to the semicolon on the progress bars? [08:31] "Build phase: Adding file contents" instead of "Build phase:Adding file contents" [08:33] beuno: patches :) [08:34] lifeless, of course. Just wanted to get extra agreement nods :) === montywi is now known as monty|meeting [08:36] hi all [08:36] does anyone see the problem with this code: http://bazaar.launchpad.net/~asabil/%2Bjunk/bzr-filter-branch/annotate/head%3A/__init__.py ? [08:36] I get the following traceback: http://pastebin.ca/1341535 [08:37] only when using the plugin inside a rich-root repository [08:56] jelmer: using bzr-svn can I just import it to bzr and then "forget" that it was part of svn? [08:57] Mez: Yes. [08:57] how ? [08:57] rm -r $svn_repo :-) [08:58] Lo-lan-do: but surely bzr will still think "oh, I'm parented to $SVN_REPO" [08:58] Depends on how you did the import. [08:58] Mez: "bzr pull --remember", then? [08:58] branched svn, so I can keep the history [08:59] If you ran "bzr checkout svn+ssh://...", then "bzr unbind" will unbind. [08:59] If you ran "bzr branch svn+ssh://...", then you're not bound. [08:59] bzr remembers the SVN URL as the parent location for subsequent pulls and merges, but that's about it. [09:00] You can remove the parent_location from .bzr/branch/branch.conf if you don't like to see it in "bzr info". === timchen1` is now known as nasloc__ [09:11] statik, has your cron for updating bzr nightly gone to sleep and not woken up again? === thunderstruck is now known as gnomefreak [11:46] vila, why is bug 331288 incomplete? [11:46] Launchpad bug 331288 in bzr "Push should have an option to not stack" [Undecided,Incomplete] https://launchpad.net/bugs/331288 [11:46] Because I didn't have time to test that it already works and I thought the bug reporter may do that :-) [11:47] 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:48] vila, so maybe add a comment? I'm sure jml will cry if he sees that you think he is incomplete [11:48] by marking it incomplete, I know either jml will come back after testing or *I* will get more time to test it properly [11:49] beuno: huh ? I added a comment saying it should work by using '--no-stacked' instead of '--not-stacked' [11:49] I sure remember having used --no-stacked [11:49] vila, ah, I did not see that [11:49] ignore me [11:50] 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:51] beuno: comment added again [11:52] vila, that will be fixed soon-ish [11:52] in an ajax-y kind of way [11:52] beuno: good :) [11:52] beuno: so you know about the problem already ? [11:56] vila, yes, it's happened to me a few times as well [12:03] anyone ? === 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 [13:29] hi! how to make 'bzr log' faster? it takes >24 hours on quite powerful machine [13:30] * Lo-lan-do suddenly feels *his* performance problems are not that bad after all [13:31] uhm [13:31] domas: wow, it shouldn't be *that* slow [13:31] 24 hours seems a bit much [13:31] domas, what version of bzr is that using? [13:31] domas: are you running log on a particular file, with -v, or just 'bzr log' ? [13:31] it's aliased to log -v, I bet [13:31] beuno: any, 1.12 [13:31] lifeless: 'bzr log -v' on whole tree [13:31] it allocates ~800MB of memory [13:32] and oprofile says it is walking dictionaries all the time [13:32] 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] lifeless: I'd be happy to betatest :) [13:32] any kind of caching, etc :) [13:32] domas: there is an alpha quality branch at the moment, lp:~bzr/bzr/brisbane-core, where we are assembling the fix [13:33] lifeless: interesting, thanks! [13:33] domas: we need better disk data structures though; so there is a [somewhat costly] conversion to do to test [13:33] would that take 24 hours? :) [13:33] domas: there's also discussion on the list, and on the Roadmap page [13:34] 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] we're only starting to optimise the conversion logic [13:35] I was tempted to start hacking bzr too [13:35] domas: I guess i'm saying - please do track this. We're planning a beta quality release for this in March [13:35] it was spending way more time in walking than calculating [13:36] lifeless: thanks, subscribed ;-) [13:36] cool [13:36] night everyone [13:36] lifeless: I'm playing with opengrok [13:36] it is awesome :) [13:36] it has bzr integration, but thats too slow on big trees [13:37] opengrok? [13:37] http://dammit.lt:8180/source/xref/mysql-5.1.31/sql/ [13:37] it is source repository browser with indexing [13:38] think, lxr on steroids [13:38] hmm [13:38] that reminds me how far i will have to go with anyvc if i want to make it neat === ja1 is now known as jam [14:30] jam: ping [14:30] morning vila [14:31] morning :) [14:31] I'm trying to fix test_autopack_rpc_is_used_when_using_hpss failing for dev5 formats [14:31] It turns out we don't use hpss because InterPackToRemotePack rules out the specific autopack [14:32] Fixing that reveals that we don't have the right Packer [14:33] Which in turn can't be easily fixed because of our design [14:33] jelmer: sup? whats missing in dulwich to give status info about the index/the workdir? [14:34] jam: because Packer is the root of two class hierarchies: one for the format one for some features (like reconcile) [14:35] vila: are you talking about for GC repos, or for chk repos? [14:35] AIUI chk repos use the same Packer [14:36] I need CHKReconcilePacker._process_inventory_lines ... somwehere it can't be accessed [14:37] jelmer: btw, any chance to move dulwich to a bsd style license? [14:39] 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:40] 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] I don't quite understand why to get autopack working, you need _process_inventory_lines ? [14:41] jam: let's rollback [14:41] As for stuff like "Packer", it would be reasonable to define class attributes [14:41] ronny: hi [14:41] So PackRepository._packer_class = Packer [14:41] CHKPackRepository._packer_class = CHKPacker [14:41] etc [14:41] ronny: We'll be merging some stuff from pyrite soon, that should include an index parser [14:41] or possible a registry [14:42] jelmer: an api that compares to bzr's WorkingTree.iter_changes would be nice [14:42] InterPackToRemotePack rules out using InterPackToRemotePack if any of the repo supports_chks [14:42] InterPackToRemotePack rules out using InterPackToRemotePack if any of the repo *doesn't* supports_chks [14:43] jam: see InterPackToRemotePack.is_compatible in repository.py [14:43] 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:44] 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] jelmer: at least lgpl? [14:44] jam: but ReconcilePacker._process_inventory_lines adresses precisely that [14:44] jam: is that clearer ? [14:45] jam: and do you agree about InterPackToRemotePack.is_compatible ? [14:45] 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:46] ronny: dulwich is GPLv2+ at the moment [14:46] vila: think you were right in your first statement. InterPackToRemotePack rules out if any repo *does* support chks [14:47] Second, I don't really think we want to switch to using Packer based fetch [14:47] I'm pretty sure we are trying to get away from that [14:47] into the insert_record_stream(get_record_stream()) based APIs [14:48] So IMO, the real fix is to help insert_record_stream() && commit_write_group() trigger a remote autopack() [14:48] rather than trying to get it to use InterPackRepo code. [14:48] vila: does that make sense? [14:49] 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:50] time to shelf debug statements :) [14:50] jam: hmm, not yet, I should first understand where the insert_record_stream route will start [14:50] s/will start/should start/ [14:51] 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:53] hmk [14:53] vila: also note that Robert and Andrew are working on a new fetch command [14:54] which also should be preferred to Packer based work [14:54] and deals with Remote calls [14:54] as there is some overlap here, I agree that we should wait [14:54] if you *want* turn those into KnownFailure [14:54] with a comment like [14:54] jam: reason enough to wait ? Or can you point [14:54] "Remote autopack calls is being postponed for improved fetching" [14:54] lol, s/RETURN/DELETE/ :) [14:55] jam: deal, I'll do that [15:02] statik, has your cron for updating bzr nightly gone to sleep and not woken up again? [15:02] beuno: oh my i hope not. [15:02] * statik looks [15:04] beuno: they are confused with this error: bzr: ERROR: Unknown repository format: 'Bazaar RepositoryFormatKnitPack6 (bzr 1.9)\n' [15:05] * statik upgrades bzr on the build machine [15:05] statik, ah! the build machine doesn't install it's own versions? :) [15:20] beuno: all fixed, and new packages are churning in the PPA now. thanks for letting me know it was stalled! [15:21] statik, awesome, thanks for keeping this rolling, it's very useful to dogfood this stuff [15:21] np, i'm happy to be able to help the project in a small way [15:41] 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:43] no [15:43] we should use the workingtree.XXX ones [15:44] ok, will fix it in bzr.dev then [15:56] jam: already fixed there by.... you :) [15:56]