[00:07] * thumper out for lunch [00:07] damn [00:07] wrong channel [00:09] jelmer: is there still a gtk applet for bzr? [00:10] nvm [00:19] lifeless: With the new remap code (for map and unmap) I'm now able to get farther in converting revisions from bzr.dev to chk inventory [00:19] Last time it failed around 12.1k revs, I'm now at 14.8k [00:20] at ~1200s [00:20] so it will take maybe an hour to finish [00:25] This is the info for a quick conversion of bzrtools: [00:25] http://paste.ubuntu.com/79555/ [00:31] jam: cool [00:32] lifeless: hello [00:33] lifeless: you pinged me yesterday [00:33] yes, about testresources foo I think [00:34] lifeless: want to talk about it now? [00:34] nope [00:34] got to leave real sooon [00:34] lifeless: np [00:56] lifeless: so it took a total of 39m51s to convert all of bzr.dev into development4 [00:56] I'm doing the repo-details analysis now [00:57] jam: thats pretty good [00:57] Also, my first attempt at a quick hack to get knit delta compression failed. I'm not 100% sure why, but I was setting a parent, and it *wasn't* doing a delta. [00:57] I'll also note that I get a *lot* of collisions with different details [00:57] I don't quite understand that [00:58] do people here regularly use multi-pull? [00:59] I tried using -v (for verbose) and the output seems just as terse [01:03] lifeless, jam: I am allowed to change the inventory returned by Repository.get_inventory(), right? [01:03] Legal? probably, recommended? [01:04] jelmer: no, and split-inventory will not let you [01:04] I believe in the chk code we are adding an Inventory.create_by_apply_delta() function, which would be the recommended way to do it [01:04] jelmer: why do you want to? [01:05] just curious, it would be a cheap optimization right now [01:05] jelmer: things could behave badly with aliasing [01:06] lifeless, bzr.dev doesnt' have a Repository.add_inventory_delta() yet, btw [01:06] ah [01:06] its been reviewed, mayhave a name change and so on [01:07] gotta go, ciao [01:08] ciao [01:08] Will installing Pyrex make 1.10 run much faster? [01:09] awmcclain: are you running from an installed bzr, or from source? [01:09] jam: easy_install -U bzr [01:10] hmm... I don't know for sure what that gets as a package. [01:10] I think it gets the released tarball [01:10] which means you should only need gcc [01:10] and not Pyrex [01:10] "The python package 'Pyrex' is not available. If the .c files are available, [01:10] they will be built, but modifying the .pyx files will not rebuild them." [01:10] that warning seems fine [01:10] doesn't bzr --version list the optimisers? [01:10] * lifeless goes [01:10] you are watching out for the "could not build XXX using the slower python versions instead" [01:10] Right, since I'm not modifying the source. [01:11] lifeless: you may be interested in: http://paste.ubuntu.com/79569/ [01:11] if you haven't gone yet [01:11] it is the repo details for chk w/ bzr.dev === kiko is now known as kiko-zzz [01:43] lifeless: Cool. Is it possible to upgrade the indexes or do you have to "rm -rf"/"bzr index"? [01:48] jelmer, still around? [01:49] rockstar, yep [01:49] jelmer, getting a test failure in a fresh subvertpy branch [01:50] if there's a single test failure, that's a known issue [01:50] jelmer, http://pastebin.ubuntu.com/79582/ [01:50] the failure is known, the error isn't [01:50] That's running nosetest on the build [01:52] I did `python setup.py build && cd build/build-* && nosetests` [01:52] make check fails in the same way. [01:52] I moved some things around but forgot to run the tests [01:53] I'm pushing a fix [01:53] thanks for letting me know :-) [01:53] jelmer, sure. [01:53] the other issue is known, and is caused by the fact that subvertpy can't rely on bzrlib.urlutils [01:53] jelmer, why's that? [01:54] it's otherwise independent of bzr, and it would make adoption by e.g. the basie folks harder [01:54] jelmer, basically, I'm back evaluating using subvertpy in cscvs, and, in effect, the launchpad import system [01:54] ah, cool [01:55] jelmer, do you think it could be used in production? [01:55] subvertpy? Yeah, I think so. The bzr-svn tests exercise it pretty well and I haven't seen any other problems either [01:56] the server stuff is still incomplete and unstable, but you won't be using that anyway I presume [01:56] jelmer, nope. [01:57] We want to be able to roundtrip commits as well. [01:57] if you want to roundtrip commits, it's probably more worthwile to look into bzr-svn [01:59] jelmer, did you push the fix to trunk [02:00] rockstar, yep [02:02] I'm on rev 1971, and it's telling me there are no revisions to pull [02:02] :/ [02:02] it's a mirrorred branch, in case you're pulling from lp [02:02] jelmer, ah, that makes sense. [02:21] lifeless: looks like by using inventory deltas I can actually avoid that Inventory copy [02:22] lifeless, that would save another 33 % \o/ [02:28] lifeless, still there? [02:28] abentley1, ? [02:29] or somebody else familiar with inventory deltas? [02:29] jelmer: hi. [02:30] abentley1, hi! [02:30] abentley1, Is it possible to recursively delete entries using a single inventory delta entry, or do I need to delete all ancestors separately? [02:31] jelmer: You're supposed to list all the deletions. [02:31] abentley1: Thanks. [02:31] jelmer: I think deleting the parent works with current implementations, but it's not guaranteed. [02:32] abentley1: Also, is it valid to have two changes for a single ie? [02:33] file_id I mean [02:33] jelmer: No, the ie describes the target state. [02:33] So if you had two, and they differed, one would be wrong. === abentley1 is now known as abentley [02:34] right, that makes sense. Thanks again. [02:34] jelmer: np [02:35] * jelmer regrets not trying out inventory deltas earlier. I thought they would be complex to deal with in bzr-svn for some reason, but it's actually improving the code in various places [02:49] It's always a treat when you discover {that,} someone else's code {,that} can make your life better. [02:54] abentley, is it valid to remove a file_id first and then re-add it again at a different path? [02:56] jelmer: No, a file id should occur at most once in a given delta. [02:56] jelmer: Removing the file_id is not needed if you're moving the file. [02:58] jelmer: There is no "before" or "after" in a delta. It's ambiguous to perform two operations (deletion or moving) in the same delta. [02:59] abentley: Ah, ok. [03:00] I don't know beforehand which files are only removed but not added again (a rename), but I can obviously keep a set of files that are deleted and remove the ones that are also copied from that and just process the renames at the end === jamesh__ is now known as jamesh [04:29] Any idea what "bzr: ERROR: The branch lp:poetry has no revision None." means? I've used this launchpad branch plenty in the past. All of a sudden it is being weird. === lamont` is now known as lamont [05:08] Do u feel like your life is stuck in a rut, just going around in circles. Do u feel Spirituality left out then all u have to do is !!!!TAKE BACK REALITY!!!! www.ellis69.webs.com [05:09] Take back reality from who? [05:10] Is there something up with the mailing list? I've seen replies to several messages I haven't received. [05:11] In the svn-import performance thread, I see four messages. Gmane only has two. [05:12] The mailing list archive says there are five messages. So I guess I am missing something for some reason. [05:12] Peng_: I see 5 also. [05:13] So it's just me? Damn. [05:13] :P [05:13] Peng_: #5 is ~ 16 minutes old. [05:15] abentley: I'm missing the first reply from jam, not the most recent message. [05:16] Sorry for a stupid question: if using bzr-svn, does the Bazaar revno == the Subversion revision number? [05:17] (fresh branch, etc) [05:17] AfC: Not in the general case. [05:19] AfC: No, because svn revnos are repo-wide while bzr revnos are branch-wide. "bzr log" will show the svn revnos on revisions created with svn. [05:21] ah [05:22] Peng_: didn't know about that. Nice feature. Thanks. [05:22] There's also an svn revspec, so you can do e.g. "bzr cat -r svn:123 foo". [05:22] Peng_: Taking reality back is easy. The question is, does reality want YOU back? [05:29] Gmane seems to have all of hte messages. [05:29] Hm. [06:07] Peng_: you have a blog or homepage? [06:08] AfC: I own a domain name, but whether you can call an almost-blank index.html a "homepage"... [06:09] Peng_: It could hardly be worse than http://audacious-media-player.org/ [06:10] AfC: By "almost-blank", I seriously meant "almost-blank". It's only one page, with no CSS or images or anything. :) [06:11] Fine. I won't link to you. [06:11] {shrug} just trying to be polite and attribute when due. [06:13] AfC: Thank you. :) I'd really rather not be linked. I just imagine the disappointment someone feels when they click a link, expecting to find something interesting, and...don't. :P [06:13] Maybe you should endeavour to be interesting, then? :) [06:14] [Tricky] [06:15] [/me notices in passing that is virtually impossible to make this conversation not make it appear condescending. Oh well] [06:15] Heh. I didn't take it that way. [07:16] I tried being interesting once, but it was way too much work. I went with irreverant and misanthropic instead; it's surprisingly close to the same thing, but SO much easier. === toytoy_ is now known as toytoy [07:43] hi all [07:45] * vila had to reset its switch (first time in years, took him a while to even think about it as an explanation for losing internet connectivity :-) [08:21] hey all... I was going to upgrade my launchpad branches to 1.6 but now 1.9 exists... should I just go all the way to 1.9 now? or should I hold off and just do 1.6? [08:23] I thought I heard that LP doesn't support 1.9 yet. [08:26] fullermd: well then - that would be a great reason to not use it yet! [08:34] It makes it harder anyway ;p [09:12] hi, I've got a question about bzr rebase: did I get it right, this plugin can be used to create a new branch containing only the last ten revisions of another branch [09:15] is there some workflow related documentation to rebase somewhere? [09:41] ok, maybe I'm wrong with bzr rebase [09:43] so more general question: is it possible to create a new branch of the last ten revisions of an existing branch? [09:45] thekorn: you can probably branch the original branch with -r0, then merge everything from revision 0 to -9, `bzr revert --forget-merges`, `bzr commit`, `bzr replay` the rest [09:47] luks, hmm, thanks, this looks like magic, let me try [09:48] thekorn: basically the problematic part to squash everything from the start of the branch to some point into a single revision [10:16] luks, does not seem to work, maybe I'm doing something wrong, thanks for your help anyway [10:35] jelmer, yt? [10:36] fwiw, he last talked 7 hours ago, so likely not === cprov is now known as cprov-away === bac_lunch is now known as bac [13:47] can someone explain the difference between merge, and pull to me? I'm not getting something. [13:48] perhaps it would be better if you ask specifically what you don't understand === kiko_ is now known as kiko [14:49] has anyone here ever seen pack files get corrupted after a push [14:49] ? [14:52] yacc, hi [14:52] did anyone file a feature request to make `bzr status -S` not show conflicts in an inconsistent way? [15:04] After a push, when I try to do anything, I get "Unrecognised container format: 'B363'". A couple of the pack files don't have their header ("Bazaar pack format 1 (introduced in 0.18)"). [15:05] "anything" such as bzr update [15:06] bzr: ERROR: These branches have diverged. Use the merge command to reconcile them. [15:06] but when I use the merge command I get 'Nothing to do' [15:10] knighthawk: could you provide a bit more context on when this happens, what bzr status/missing say? [15:11] enobrev: I've seen something like that before, don't recall off the top of my head what the situation was. [15:11] Peng, the mailing list is not sending me everything right away either === abadger19991 is now known as abadger1999 === beaumonta is now known as abeaumont [15:28] LarstiQ: you were the one to help me with it last time. I ended up killing the repo and re-pulling because adding the header manually didn't work [15:29] hey peeps [15:29] enobrev: ah [15:29] bzr branch bzr+ssh://myrepo [15:29] bzr: ERROR: Generic bzr smart protocol error: [15:30] doesn't give me much to go on.. [15:30] Bazaar (bzr) 1.7.1 [15:30] -Dhpss doesn't change the output at all, which strikes me as odd [15:32] LarstiQ, at least that's what I did last time. But just ran into the problem again this morning. I'm waiting for the developer who made the last push to log on so I can debug with him, but just wondering if anyone's seen that happen around here [15:32] enobrev: this time, go the launchpad answers/bugs route [15:32] LarstiQ, good call [15:32] * LarstiQ nods [15:32] enobrev: succes with that [15:32] * LarstiQ heads downtown [15:33] LarstiQ: thx [15:38] branching localy I got bzr: ERROR: exceptions.MemoryError: [15:44] wow - `bzr branches localrepodir` => 750MB memory usage [15:46] swap was disabled on the machine, fixed that, it works now [15:51] jelmer, hi ;) [15:51] yacc, hi [15:52] jelmer, OT, technically, today #samba-technical is more appropiate ;) [16:02] LarstiQ, bzr status says nothing. bzr missing says I'm missing 2 revisions. === kiko is now known as kiko-fud [16:10] abentley: ping about bug #304841 [16:10] Launchpad bug 304841 in bzr "bzr push raises RevisionNotPresent" [Critical,Triaged] https://launchpad.net/bugs/304841 [16:11] When you say "as of revno 3873" is that because that is the bzr.dev you used to test it with [16:11] or that is the actual revision that shows the bug versus not showing it? [16:11] jam: No, that's the version of 1.10 I tested it with. [16:11] And are you talking the 1.10 branch or the bzr.dev branch [16:11] ug [16:11] the new "loom" command hijacked "bzr up" to mean something other than "bzr update" [16:12] jam: 1.10 rc does not exhibit the bug, because it gives the ShortReadv [16:12] k, did you try bzr.dev ? [16:12] jam: bzr.dev also gives the ShortReadv [16:12] I don't expect anything different but just something to compare against [16:12] hm... k [16:12] I guess Martin didn't get the revert into bzr.dev yet [16:13] jam: Right. [16:22] jam: It's possible that the waste you're seeing in packs was introduced by Martin's stacking fix in 1.10. That creates a fulltext if the basis text isn't available. [16:23] jam: (but the basis text may arrive later in the stream). [16:24] abentley: I don't think it would "go away" during autopack [16:24] Also, this is only in the brisbane-core branch which doesn't have bzr.dev merged in yet [16:25] I'm pretty sure it is Robert's chk work, which adds things to the repository, then determines the sha1, and if it collides, just omits one of them from the index. [16:33] abentley: do you get the same failure if you don't use "--use-existing" ? [16:33] jam: No, then I get the standard error you get if you push to an existing directory. [16:34] sure, I'm just wondering if there is something already wrong with the target, that is causing confusion. [16:34] Do you get the failure if you push do a different branch? [16:35] Certainly this is the "convert back to fulltext" code, since it is going through "get_bytes()". [16:35] I can't actually see the branches, though, so I'm a bit limited in what I can poke at. [16:36] jam: I would expect so, but I'll verify. [16:39] jam: Unfortunately, these are LP branches, so providing a mirror would take significant time. You may be able to reproduce with lp:~abentley/launchpad/web-diffs [16:39] abentley: I'm not on the private team that has access to lp branches [16:39] so I can't reproduce at *all* [16:41] jam: That seems dumb. I've gotta run. Be back in ~ 2 hours [16:41] I won't disagree... [16:41] see you later [16:44] It would also seem that the CombinedGraphIndex it is using doesn't have any actual indices, so there isn't any way for it to have *any* content. [16:44] Seems like something is confused as to where the real content is. [16:51] abentley: I can reproduce it here trying to push a stacked branch of bzr with bzr-1.10 onto launchpad. [16:51] I get the same: KnitVersionedFiles(_KnitGraphIndex(CombinedGraphIndex()) failure [16:52] oddly it takes almost 7m before it gets there... === kiko-fud is now known as kiko [17:19] Can someone explain what type of smart server would be the best for the following uses... [17:20] I want controlled user access to my repos, and maybe certain users have access to certain repos. This is on a server which I manage (VPS) [17:20] I would need the connection to the server to be encrypted [17:21] and possibly not want to create SSH or machine-level user accounts for people accessing the repos [17:21] ...I've been reading up on the different smart server configs and not sure which matches with what I want to do the best, any suggestions? [17:33] eferraiuolo: my recommendation would be to use bzr+ssh with a single account [17:33] and use different ssh keys for each user [17:33] you can see some sample info in contrib/bzr_access [17:34] abentley: it also seems that I can reproduce it locally, without having to connect to LP at all [17:34] okay, so you're suggesting a single user account on my machine that each user would login thru? === Mario_ is now known as pygi [18:02] can running bzr upgrade after installing bzr 1.9 have some bad consequences? [18:03] I tried it and now bzr says there's no repository present when I try to pull/info/status, etc. [18:04] LaserJock, the default format is the same as 0.92 [18:04] so there should be no consecuences [18:05] what exactly is the error? [18:05] bzr: ERROR: No repository present: [18:05] that's very odd [18:06] are you using a shared repo? [18:06] no [18:06] can you check that there's a .bzr dir in there? [18:06] yeah, it's there :-) [18:06] LaserJock: check .bzr/repository [18:06] I checked that first [18:06] there's a bug where it renames .bzr/repository to repository.moved or something [18:07] james_w: there's a repository.backup [18:07] *then* checks [18:07] then doesn't move it back if it fails [18:07] james_w, really??? [18:07] LaserJock: yeah, move that to .bzr/repository [18:07] also, why is it upgrading? [18:07] it only should upgrade if LaserJock was on knits [18:07] heah, there we co [18:07] *go [18:07] ok, it works now [18:07] it happens when rich-root support is not the same [18:07] aaah [18:08] rich root is evil [18:08] I've had a bunch of "you should upgrade" messages [18:08] but I never do it [18:08] ok, so you where on knits [18:08] but I decided to try it on a throw-away branch as it didn't matter if it screwed it up [18:08] Tak: That's something with bzr-svn. [18:08] and you should probably do: bzr upgrade --rich-root-pack [18:08] Tak: Augh, I was scrolled really far up. Sorry. [18:09] that's ok - good to know [18:09] bug 145812 [18:09] Launchpad bug 145812 in bzr "Upgrade can leave a broken repository (with backup)" [Low,Triaged] https://launchpad.net/bugs/145812 [18:09] I think almost all my branches are rich-root-pack [18:10] that's one of my "issues" with bzr is it seems like I'm always worrying about formats, and I don't understand them and can't keep them straight [18:12] is pack-0.92 the default? [18:12] yes [18:13] ok, I've got a couple of those [18:15] now if I upgrade my local branch does that slow down pulls if the branch I'm pulling from has an old format? [18:16] it does [18:16] you should upgrade the remote one as well [18:16] well, I never have access to the remote one [18:16] so i'll just leave them alone [18:17] I just wondered what would happen === bac is now known as bac_lunch [18:24] jam: hi! [18:24] jam: You mentioned a patch to a bug I was seeing in brisbane-core [18:24] jam: Which patch is that? [18:30] jam: glad to hear it. [18:43] Hi. Any cure for old (0.8.2) error: Error -3 while decompressing: invalid distance too far back? [18:45] 0.8.2? That release is older than I am. Does anyone even remember the error codes from back then? [18:48] The error continues, mentioning specifically the same line referred to in a launchpad bug report about memory issues: [18:48] usr/lib/python2.4/site-packages/bzrlib/tuned_gzip.py line 103 [18:49] (It's a very short message resulting from "bzr check" only two or three lines of error, before returning to the prompt. No long stack. [19:00] After using bzr, svn makes me :( :( [19:01] ... especially with this 11 GiB checkout full of dead branches. === bac_lunch is now known as bac === doko__ is now known as doko === kiko_ is now known as kiko [19:40] jelmer, how are the duck branches going? [19:41] has anyone any suggestions for end of line translation? [19:41] crisb, I think there's a plugin somewhere, not sure what the status of it is [19:42] pygi, Well, they're there [19:42] pygi, I guess it may be a good idea to put up a wiki page about them.. [19:42] jelmer: i've seen that one, but is there any plans for anything more in bzr itself? the plugin doesnt really do anything automated (but is still useful in some regards) [19:42] jelmer, I mean have you done any work to support them in core? :) [19:44] it would be nice to get some info about how other projects manage it. my current idea is to use just LF's in the repository except on files which need CRLFs (ini's etc) - is that how other people do it? [19:44] crisb, yeah, I think most just pick one line ending mechanism [19:44] but I can see that without at least the EOL plugin, repositories could become a mishmash of different line endings [19:45] crisb, afaik the plugin did most things automated, but perhaps it's a good topic to bring up on the mailing list again [19:45] crisb, I know we're at least planning on supporting line ending conversions like svn does [19:47] jelmer, ah thats good to know. we're converting from PVCS which (supposedly!) has some sort of conversion between line endings and although I dont see it as a real problem, some people are quite precious about it! [19:48] jelmer: the patch is in the email "CHKMap._check_remap()" [19:48] abentley: I'm pretty sure I understand the cause and have an idea of a reasonable solution [19:48] it was one Martin considered originally, but didn't go with [19:49] namely, requesting topological ordering [19:49] if we have a fallback vfs [19:49] jam: What was the cause? [19:49] jam, Thanks, I'll give it a try [19:49] If you go back to the bug I mentioned it theree. But basically, Assume you have a delta chani A-B-C-D [19:49] and only A is present in the fallback [19:49] if we get the delta "C" [19:50] we can't extract it to a fulltext [19:50] because we haven't seen B yet [19:50] abentley: sound reasonable to you? [19:51] The actual case I looked at was a bit more confusing than that, because it seemed like I was inserting D, and C was present, but not B. [19:51] And I didn't understand how *that* could happen. [19:51] But I'm going to start from there. [19:51] I should have a patch shortly that you can try. [19:52] jam: I thought we were checking for the case where B wasn't present. [19:52] I'm not sure what you mean by "checking for" [19:53] The idea is that the stream is "unordered" [19:53] so it can send "C, B, D" [19:53] jam: Only trying to get a fulltext when B was present. [19:53] abentley: that might actually be why I saw the confusion [19:53] Imagine we are fetching and we see C, D, B [19:53] at the point we get to D, C is present [19:54] but if we want to insert a fulltext, B is not [19:54] (we only look at the direct parent, and not the whole chain) [19:54] anyway, I'm not 100% sure [19:54] But that is the best I could put together [19:54] jam: I'm pretty sure we're checking whether C is present in the fallback. [19:54] (so far) [19:54] hmm, next issue [19:54] CHKInventory doesn't have a apply_delta() function anymore [19:54] jelmer: you aren't allowed to mutate a CHKInventory [19:54] you need to use "create_by_apply_delta()" [19:55] which we should be adding to regular Inventory if we haven't [19:55] jelmer: But more likely, you want to use Tree.apply_delta. [19:55] jam: Thanks, I'll look at that [19:55] abentley, A tree would be overkill in this situation I think. I'm only constructing the inventory for internal use by bzr-svn [19:56] abentley: also, Tree doesn't have apply_delta, right? You have to at least have a MutableTree (I would assume) [19:56] jelmer: Oh, I thought you were using it for commit. [19:57] jam: Interesting question. Not sure. [19:57] You can't really do RevisionTree.apply_delta, IMO [20:00] jam: Well, it would probably be a bad idea, anyhow. [20:01] jam: So I'm looking at the test in knit.py near 1336. [20:02] This one, right: [20:02] elif ((record.storage_kind in knit_types) [20:02] and (not parents [20:02] or not self._fallback_vfs [20:02] or not self._index.missing_keys(parents) [20:02] or self.missing_keys(parents))): [20:02] And the "self.missing_keys(parents)" is supposed to determine that the fallback doesn't have the parent either [20:02] jam: "or self.missing_keys(parents)" should mean that we don't attempt to construct fulltexts unless the parent is present. [20:02] Right, so imagine a long change A-B-C-D-E [20:03] We first get C [20:03] and we see that only A is in the fallback [20:03] so we go ahead and insert it as a delta. [20:03] then we get D [20:03] I guess that should be telling us it is okay to insert as a delta as well, because C is present... [20:04] jam: No, that would fail the missing_keys(parents) and the not _index.missing_keys(parents) [20:05] jam: Okay, I'm inclined to agree that forcing a topo sort makes sense here. [20:05] As it's much simpler. [20:05] well, I can say that in my test case, forcing topological order made it "just work" [20:06] but I'd like to make sure I know the problem first :) [20:06] So if we have C, we're allowed to make D a fulltext. [20:06] abentley: supposedly, but we don't have B to *actually* create D as a fulltext [20:07] but the problem is that I don't understand why we *want* to make D a fultext [20:07] anyway, here is the "just make it work" patch: [20:07] http://paste.ubuntu.com/79974/ [20:07] jam: Oh, I was trying to explain it to you because of your last comment. [20:07] A whole 1 line insertion [20:08] abentley: figured it out [20:08] it is a merge revision [20:08] and we check "self.missing_keys(parents)" [20:09] not "self.missing_keys([compression_parent])" [20:09] so it *does* have the direct parent [20:09] but not the merged parent [20:09] (I'm double checking that) [20:10] ok, a bit weird, but "self._index.missing_keys(parents)" returns 1 entry and "self.missing_keys(parents)" returns None... [20:10] so that means that the stacked branch has *merged* the base branch [20:12] jam: I'm testing out your patch. [20:12] I'll also try a different one that isn't so heavy handed. [20:13] jam: I can confirm your patch works for me. === jfroy|work is now known as jfroy === jfroy is now known as jfroy|work [20:20] abentley: I'm almost done with a patch that just fixes parents => compression_parent [20:20] give me a sec [20:21] jam, Yeah, "plain" Inventory doesn't have create_by_apply_delta() yet [20:21] jam, Other than that, things at least work now - thanks [20:22] abentley: try this: http://paste.ubuntu.com/79983/ [20:22] jelmer: It is trivial to add create_by_apply_delta to plain inventory [20:22]