[00:00] sorry I dont have time [00:03] I'll bypass it and let the user log one if they feel the need [00:04] might I suggest that you dont use tcp/80 if you're not doing http and if you are use expires [00:13] dub: we're doing HTTP [00:14] dub: and expires is orthogonal to the issue @ hand; VCS data doesn't have a strict semantic value for expires [00:14] expires wouldn't help us at all [00:15] expires is the only way to reliably prevent caching [00:15] in my limited experience anyway [00:17] dub: no-cache does it fine [00:18] we don't care if caches cache, we cache bust. We have to because there are folk that run caches that don't conform to the rfc's [00:18] if you say so. yet you seem to have an application that causes caching issues [00:18] no [00:18] failing to process specific http messages != caching issue [00:18] we cache several gbps and I dont know of other problem apps [00:18] expires fixes all stale data type problems [00:18] sure, but this is a proxy issue, not a caching issue [00:19] I repeat, its not a stale data issue, not if it looks like rbistolfi's issue. [00:19] regardless, i've spent enough time on this, thanks for your assistnace [00:19] anytme [00:19] please do encourage your user to file a bug [00:21] will do [00:43] morning [00:44] hi lifeless [00:44] hi igc [01:10] igc, lifeless: hi! [01:11] igc: OS X 10.4 DMG's uploaded. hopefully I'll get Leopard DMG for tomorrow (actually as soon I reboot my "work laptop" into OS X :/ ) [01:11] verterok: well done and thank you [01:13] igc: np [01:17] lifeless: ref upgrading the bzr pqm chroot to hardy; any probs at your end if we stop pqm while the upgrade is done? or would you prefer a less intrusive cutover? I image it'd take an hour or two max. [01:22] spm: stop it [01:22] lifeless: ta [01:22] spm: I presume you'll take a backup in case we have to roll back? [01:23] lifeless: heh. 1st thing pjdc did - how big is the chroot vs how much space do we have :-) [01:32] igc: http://developer.apple.com/mac/library/DOCUMENTATION/Carbon/Conceptual/ProvidingUserAssitAppleHelp/authoring_help/authoring_help_book.html#//apple_ref/doc/uid/TP30000903-CH206-CIHEAADH [01:33] igc: ^ there is a description of the layout/format required by the Mac Help viewer [02:02] dash: thanks! I'll bet uncommit is how I got multiple heads. [02:04] lifeless: the upgrade is done. Can you fire in a trivial request so we can verify how much we've broken? [02:11] Can anyone tell me what is wrong with the branch lp:~ubuntu-desktop/gdm/ubuntu. When I try and push it says the branches are diverged and when I look at https://code.edge.launchpad.net/~ubuntu-desktop/gdm/ubuntu it says LP is processing changes for this branch [02:13] someone else seems to have pushed up new revisions [02:14] you probably need to "merge" [02:14] robert_ancell: ahhh. that'd possibly be related to an issue we're having atm. see #launchpad. [02:15] spm, ok, thanks [02:21] spm: do we have python-subunit installed now? [02:22] lifeless: indeed we do! [02:25] ok, I'll do something shortly [02:26] lunch is begging first [02:26] Ooh, what a good idea. [02:31] http://paste.ubuntu.com/280891/ [02:31] I need someone to audit that [02:31] I think its robust and clear; I'd like it to be moreso [02:33] lifeless: the layout and invariants section are inconsistent about saying MD5HASH vs. HASH [02:33] lifeless: the meaning of "There is always 1 and only one match for: [02:33] " and the following bullet list isn't obvious to me. [02:34] I'll clean it up. the intent is that only one of the following statements is true [02:34] I hope you have the spare cycles to also logic check it ;) [02:34] "- current" isn't a statement, though? [02:34] its a file [02:34] as per layout [02:35] so 'there is a file called current' [02:35] bbs [02:35] So just say that ;) [02:37] e.g. "There is always: - a file called 'current'; - exactly 1 file matching '*.check'; - exactly 1 file matching HASH.{current,delete}" [02:39] It might be worth saying upfront in the Invariants section if the intent is that this recovery will be performed automatically, or if it will need human intervention. I'm guessing you intend automatic (I hope so :) [02:42] In the insert operations, it's not clear what "check if the insert should complete", and jumping ahead to the commentary still doesn't make it clear exactly what the check is, or what the check is for. [02:45] In read sequence, what about the (small) race between listing *.check and opening the result vs. another process renaming foo.check? [02:45] I assume the answer there is the same as in the next bullet; loop. [02:45] s/;/:/ [02:46] What does "Closing a dirstate" mean? [02:47] What about multiple concurrent processes attempting recovery of the same dirstate? [02:48] Your markup is a bit inconsistent about using \n or \\n [02:48] Typo: "remaned" [02:49] spiv: I intend to make automatic recovery possible, I don't intend to do so in the initial spike [02:50] spiv: well, any policy that someone might implement, such as stat cache updates, policy checks, what have you [02:50] What happens in during insert if "mv current foo.check" fails (due to concurrent insert)? [02:50] this is good - thanks [02:50] lifeless: so "don't write new file if stat cache has barely changed? [02:51] more 'dont trash someone elses changes' [02:51] its a critical section, the only time you can be sure noone else inserts (unless they invoke recovery concurrently, and that would be a mess [02:52] so, listing *.check and the .check rename happening, - loop [02:52] * lifeless pages up and starts implementing improvements [02:53] "errors can be removed" probably should be "errors can be ignored"? [02:57] I'm not sure how "dont trash someone elses changes" fits with "check if the insert should complete". If you got as far as the "rename current statefilename.check" succeeding, then as you say you're in the critical section, so how can there be other changes that could be inadvertently trashed? [02:57] Ok, read it all now. [02:59] In my ideal world, I think maybe there'd be some sort of formal proof, or at least exhaustive state diagram, to demonstrate that all states are unambiguous in the face of concurrency. That would be a lot of work, though. [03:00] But it is just complex enough that I can't feel 100% sure that it's robust on a single read-through, although it seems plausible that it is. (With some assumptions about what the FS guarantees, of course...) [03:01] (And I don't see any obvious simplifications you could make to the design.) [03:02] So, I worry a little about bugs in edge-cases. I guess they are likely to have easy-to-repair consequences if they do happen. [03:03] so stat cache updates [03:03] say you have two writers A and B [03:03] they both concurrently prepare an update [03:03] A is doing a stat cache update [03:03] we don't know what B is doing [03:04] B wins the race on 'mv current HASH.check' [03:04] and thus completes its insert first [03:04] now, A has a new state file it wants to write [03:05] so once A is in the critical section [03:05] it can reliably see that the pointer has changed [03:05] Oh, so it's a check that the renamed current has the same pointer we think it has? [03:05] if we care, yes [03:05] a stat cache update cares that its unchanged [03:05] We need to care, I think, or else we risk losing semantic changes from B. [03:05] a 'merge' or 'add' or whathaveyou doesn't care if the pointer changed. [03:06] spiv: so there is a lockdir lock surrounding the WT still [03:06] spiv: only one semantic writer is permitted. [03:06] Ah, ok. That's worth mentioning briefly then :) [03:07] So a stat cache update cares that it's unchanged because otherwise there may be a semantic change from another process? [03:08] right [03:08] I'm writing prose about this at the top of the docstring [03:08] But an 'add' or whatever doesn't mind, because it will have first read the pointer inside the semantic lockdir write lock? [03:08] no [03:08] an add doesn't care because it is happy to trash stat cache updates [03:09] and it knows noone else is allowed to be an 'add' concurrently. [03:09] That's what I meant! [03:09] ok, but its not what you said :) [03:09] [the old pointer value /doesn't matter/ to logicalwriters [03:09] It's inferring from its ownership of the semantic write lock that the only possible concurrent changes were stat cache only. [03:09] yes [03:10] thank you very much [03:10] I'm sure it will need more polishing, but I feel its clearer now. [03:10] and I'm glad you didn't find conceptual holes [03:11] That's ok, I know how hard it is to write precise and clear text about complex state machines :) [03:11] Not yet ;) [03:11] with that, I'm going back to full screen editing; [03:11] oh [03:11] do you have anything that needs to land? [03:11] spm needs a guinea pig [03:12] lifeless: Actually, I'm a little uncertain about how automatic recovery would interact with concurrent inserts. [03:13] spiv: so, automatic recovery would want to be a logical writer - and thus hold the external lock [03:13] There Can Be Only One [03:13] lifeless: i.e. how can a process tell "I need to do a recovery" apart from "another process is mid-insert"? Via the semantic write-lock? [03:13] Ok. [03:13] spiv: I think it boils down to time [03:13] lifeless: is no rush; is more if we do it sooner vs later; but worst case we have a backup that can be failed to. [03:13] the critical section should be _very fast_ [03:13] so waiting a second (say) and then offering would be appropriate. [03:14] "should" :) [03:14] Yeah, I think prompting the user is necessary. [03:14] anyhow, as I say, I'm designing to permit, not to implement automatic recovery. [03:14] like break-lock [03:14] I'm thinking someone will try this on sshfs over a crappy, slow link at some point :) [03:14] the idea is to fail rarely, and only when the machine crashed [03:14] or that FTP server we had the other week [03:14] Yep. [03:14] the one that took up to 10 minutes to delete files [03:15] There's a limit to which I'll design for that. Obviously-broken is not ok :) [03:15] I think this will work well on windows. [03:15] and Unix [03:19] spiv: so, do you have any to-land branches? [03:20] lifeless: no, but apparently you do: https://code.edge.launchpad.net/~lifeless/bzr/bug-423818/+merge/11279 [03:21] blah :P [03:21] no I don't [03:21] thats landed [03:22] lifeless: you gave me a "needs fixing" on https://code.edge.launchpad.net/~abentley/bzr/fix_get_mtime/+merge/10544 but I replied that the requested fix wasn't suitable. Could you please comment? [03:22] lifeless: if you review https://code.edge.launchpad.net/~spiv/bzr/paramiko-keyboard-interactive/+merge/12559 I will... [03:22] lifeless: (it's short) [03:22] abentley: will do [03:23] lifeless: I can easily enough make an uncontroversial branch that removes some unused import lines if you like [03:23] beuno: / abentley: https://code.edge.launchpad.net/~lifeless/bzr/bug-423818/+merge/11279 - why is the 'change status' edit link at the far right [03:23] when on e.g. +me the edit thing is beside fields [03:23] lifeless: it's just a matter of pointing mwhudson's pyflakes branch at practically any file in bzrlib :) [03:23] lifeless: rockstar misunderstood an aspect of the 3.0 migration. [03:23] ok [03:24] is there a bug for that form, or would you like me to file one? [03:24] * spiv mumbles "affects me too" [03:25] lifeless: I'm not sure, but rockstar is aware that it needs to be changed. [03:25] ok, no need to for pointless bit-setting then ;) [03:25] spiv: doit [03:26] lifeless: on the trivial imports, or the paramiko (or both?) [03:26] (I'm doing the trivial atm :) [03:26] paramiko [03:26] lifeless: cool, thanks [03:29] spiv: hello! [03:29] barry: good afternoon :) [03:29] abentley: I've commented; you may need to escalate to Martin - I think its worth writing the code to do the path calculations [03:30] spiv: good evening :) [03:30] :) [03:30] spiv: can i play dumb user and maybe we can walk through the upgrade instructions? [03:30] barry: I have a message from the future for you: Tuesday is a good day :) [03:30] abentley: but my only data is years old now when I got close to inventory-free commits at 0.92 time [03:30] :) [03:30] beuno: have you read the upgrade guide? [03:30] bah [03:30] barry: ^ [03:30] barry: sounds good. [03:31] lifeless: sort of, but there are some holes missing that i think we should fill to make life easier for the next person [03:31] let me bring up the instructions on this box [03:32] spiv: let's start here: http://doc.bazaar-vcs.org/latest/en/upgrade-guide/index.html#migrating-branches-on-launchpad === e-jat is now known as ejat [03:32] #1. i nominate myself ) [03:32] er, :) [03:32] #2. "unset the current trunk from being the development focus" [03:33] oh right, today is tuesday [03:33] lifeless: is not! [03:33] it's still monday [03:33] spiv: i think we need a lot more detail there. unfortunately it is not obvious how to do this on launchpad [03:33] spiv: and, while i think i know how to do it, even then it's not 100% clear [03:34] spiv: so, let's try to do it and then let's document it so it's really easy for the next person [03:34] spiv: i start by going here: https://edge.launchpad.net/mailman [03:34] spiv: i click on 'Change detals' [03:35] spiv: i scroll down to Development focus [03:35] spiv: i click on the pull down menu [03:35] spiv: uh oh, i've hit my first snag. i cannot "unset" this, i can only assign it to a different series, none of which are correct [03:35] * spiv tries to play along on another project on staging [03:36] * barry waits [03:37] barry: You used to be able to set the branch associated with the dev focus via the registry pages. You could set it to blank there. I think this has been removed in 3.0 [03:37] barry: yeah, I see that too. [03:38] abentley: is that hiding somewhere behind a url hack perhaps? [03:38] abentley: iow, maybe the functionality is still there but the link to the page to do that got lost [03:38] barry: You would know about the secret URLs of registry pages better than me. [03:38] * barry has seen that in a couple of instances [03:38] abentley: heh [03:40] spiv: okay, so we've hit our first snag. i'm updating my copy of the code to see if there's a hidden page somewhere for this. if not, i will file a bug [03:41] barry: https://edge.launchpad.net/mailman/3.0/+edit and blank the branch, maybe? (try on staging perhaps) [03:41] spiv: good idea! [03:41] barry: I hope you're keeping notes :) [03:41] spiv: i log all my irc sessions :) [03:42] Close enough! [03:42] lifeless, the fix for moving change status is about to hit PQM (it's in ec2test now) [03:42] spiv: yep, i think that's it. https://code.staging.launchpad.net/mailman [03:42] "A development focus branch hasn't been specified" [03:44] spiv: iirc, i will have to push my migrated branch under a name other than "3.0" because the latter is pack-0.92 and shouldn't be changed due to any stacking going on [03:44] spiv: so moving forward my dev focus branch will have to be something else unfortunately. right? [03:46] rockstar: cool [03:46] barry: you can upgrade in-place too, which the guide doesn't documented [03:46] * lifeless thinks in-place is nicer [03:46] barry: Hmm, I'm not sure. Launchpad might be smart enough there, but I'm not certain. mwhudson, abentley, do you guys know? [03:47] but its a problem if contributors don't upgrade their stacked branches [03:47] spiv: lp doesn't rewrite the stack-on [03:47] spiv: so no, its not smart enough [03:47] Drat. [03:47] mwhudson, abentley: turns out lifeless knows everything :) [03:47] lifeless: yes, in-place would be nicer. in this particular case, there is only one unmerged branch potentially stacked on it, and i can't merge it into my 0.92 branch anyway [03:48] barry: So, sadly, yes. Unless you upgrade in-place, as lifeless says. [03:48] It might be good to mention that as an option in the upgrade guide, but at the same time overwhelming people with options isn't so good either. [03:48] spiv: okay. let's try this. let's finish the instructions as written, and then try an in-place upgrade. then someone can document both [03:49] spiv: so actually, now i need to grab a copy of the trunk and do the migration. talk to you tomorrow :) [03:49] * barry is guessing it will take a while [03:50] lifeless: btw: http://pqm.bazaar-vcs.org/ [03:50] barry: winking isn't gonig to help :P [03:50] spiv: looks hopeful [03:50] spiv: next patch, turn on --subunit ;) [03:51] lifeless: i'll be happy to document the steps. is doc.bazaar-vcs.org a wiki? [03:51] no [03:51] the upgrade guide is a branch somewhere [03:51] I suspect it may even be a separate project, and if thats so I have no idea where it is [03:51] Isn't it part of the docs in bzr's source? [03:51] I need some help "decoding" an error. http://pastebin.ubuntu.com/280929/ [03:52] doc/en/upgrade-guide ? [03:52] I'm unsure of where to start looking. I'm thinking by the 17000 number there it's looking for an older SVN revsion than I have? [03:52] tedg: on what command? [03:52] spiv: bzr gannotate configure.ac [03:53] tedg: it would ;-) [03:53] Normal annotate gives approximately the same error. [03:53] that, too, is expected [03:53] I mean, that you would get the same error [03:53] not that you would get an error ... [03:53] Oh, good. I was confused :) [03:53] tedg: yes, it appears that revision of that file is not present in your repo [03:54] spiv: So how do I decode that revision number into something useful? [03:54] Possibly due to a bug in the bzr-svn conversion? /me checks if that is on Launchpad [03:54] tedg: not sure what you mean by "useful" in this context? [03:54] Well, it's not a conversion yet. But hopefully will be soon... so I'm trying to get bugs out first. [03:54] whatever it is it sounds like a bug! [03:54] spiv: i.e., it's a missing SVN version. [03:55] spiv: Or, it was because I used bzr-svn to merge in a branch that somehow it figured out about. [03:55] tedg: how can you have a missing svn version ? [03:55] spiv: Or, it's just foobar :) [03:55] also that's spelled fubar [03:56] lifeless: i will at least email the public mailing list when i figure it out. can you explain "migrate in-place" though? [03:56] SamB_XP_: So the history of the repo is that it was converted from CVS. But the way that SF did it is that they lumped everything into one repo, which was split out -- so there is a discontinuity around revision 20K which I believe that bzr-svn just sees as "the beginning of time" [03:56] there's also a mythic button on LP that says 'doit' [03:57] Which honestly, is kinda fine. As long as it's really "the beginning of time." [03:58] tedg: that sounds kinda crazy ... [03:58] SamB_XP_: People who know me, will not disagree with you on that one. :) [03:58] what happens if you try to checkout the previous revision with SVN itself? [03:59] Well, yes. You kinda have to know the previous layout, which wasn't a "standard SVN layout" as it was in CVS. [03:59] tedg: so there's a missing record in bzr's database. It's for the configure.ac file introduced in SVN 17075, and it's modification you made to it in revision ted@canonical.com-20081121044907-chfl7r1x8s1kcp5n. [04:00] tedg: I'm not sure why it's absent, but it's almost certainly due a bug somewhere along the line :( [04:03] Ah, I see now. It looks like the first SVK cherry-pick is the issue: http://inkscape.svn.sourceforge.net/viewvc/inkscape/inkscape/trunk/configure.ac?view=log [04:03] Which means there are most definitely other files with this problem. [04:03] Oh, if you're trying to round-trip via the SVN repo, that might explain it I guess. [04:04] * barry -> sleep [04:04] That would presumably make all the foreign revisions be ghosts. [04:04] spiv, lifeless, abentley thanks. we'll pick this up again tomorrow. the future awaits [04:04] spiv: No, not round trip in that regard. The problem is that SVK (not SVN) did some very funny things with how it merged in. [04:05] night barry [04:05] spiv: It records complex merges as odd copies with changes. Borders on evil :) [04:05] barry: g'night [04:06] So if I could find all these "oddities" by hand. Could I fix them with something like the rebase plugin? [04:06] If I assumed that I'd never go back to SVN again. [04:10] For those who are curious here's the rev where the repo was converted from CVS to SVN and rearranged: http://inkscape.svn.sourceforge.net/viewvc/inkscape?view=rev&revision=10643 [04:15] * igc lunch [04:19] tedg: so, that particular data appears to still exist in lp:~ted/inkscape/devbuild [04:19] (and some of your other Launchpad branches) [04:20] tedg: so if you rebranch that into your local repo that might be enough to fix it (i.e. to copy the data that is missing locally) [04:25] 50% there [04:25] .oO [04:25] interface tests passing [04:29] lifeless: I've replied. The gist is that you're asking for complicated code that will only be used in a corner case and usually won't prevent a path<->id map being generated. [04:45] spiv: Sorry, I walked away... I'll give that a try! [04:46] spiv: Just to be curious, how did you find that out? [04:46] does anyone here have a windows machine? [04:46] Peng_, lifeless: Sorry I got an emergency and I was afk [04:46] re: http://pastie.org/633561 [04:46] I am not behind a proxy and I dont know if it is a privete branch, I just found it in launchpad [04:47] rbistolfi: its not [04:47] I branched it, so I guess it's not a private branch. [04:47] Eh, there we go. [04:47] rbistolfi: the error you have looks like a interecepting proxy to us [04:47] lifeless: I have a windows machine. [04:47] abentley: I need to know what exception dirstate raises [04:47] Or, something just went Horribly Wrong with the connection. [04:47] could you do a small test for me? [04:48] lifeless: Okay. [04:48] given a bzrlib wt4 tree at path foo [04:48] state1 = bzrlib.dirstate.DirState.on_file('foo/.bzr/checkout/dirstate') [04:48] state1.lock_read() [04:48] state2 = bzrlib.dirstate.DirState.on_file('foo/.bzr/checkout/dirstate') [04:49] state2.lock_write() [04:49] tedg: http://paste.ubuntu.com/280963/ [04:49] the last line should raise something from bzrlib.errors [04:49] lifeless, Peng_: thanks, I will try to branch from a server I admin connected to another isp, maybe I am being intercepted after all [04:49] you'll want to state1.unlock(), and you're done. [04:49] spiv: Didn't go well: bug 438509 [04:49] Launchpad bug 438509 in bzr "Crash when branching into repo" [Undecided,New] https://launchpad.net/bugs/438509 [04:50] I should say, wt4 or newer, anything dirstate based [04:50] tedg: oh wow, I haven't seen that assert triggered before [04:51] I assume I get some kind of award? ;) [04:51] tedg: I wonder if that's a symptom of the same problem, I suppose it could be... [04:51] lifeless: I have 1.2.0dev0 on my Windows box, and it seems to be broken, too. [04:51] abentley: bzrlib is broken, or the python I gave you is broken? [04:52] lifeless: bzrlib is broken. "bzr init foo" fails. [04:52] oh, eep [04:52] abentley: is the tree you have there dirstate based? if so you don't need to init... [04:53] lifeless: It is a lightweight checkout from an ext3 partition which has since been reformatted. [04:53] works for me [04:53] as long as it has a dirstate file the results should be useful [04:54] windows OS locks will mutually exclude the two locks [04:54] I just need to catch the error so my test for dirstate2 doesn't blowup on windows [04:56] tedg: I wonder if making a new shared repository ("bzr init-repo --1.9-rich-root") and branching lp:~ted/inkscape/devbuild into that and then your other local branches would work better? [04:56] lifeless: I get errors.LockContention [04:56] thank you very much [04:56] lifeless: You're welcome. [04:57] tedg: FWIW, bzr 2.0.0 should be much more aggressive about preventing incomplete data to be committed in the first place. [04:57] spiv: No, similar error. Are the details useful? [04:58] Obviously that doesn't help your existing situation (unless you have a time machine), but I thought I should reassure you a little bit :) [04:58] spiv: I am running 2.0 now... should I reimport the repo? [04:58] tedg: Did it fail on the first branch? [04:59] spiv: I had a copy of devbuild locally in a shared repo, I then branch the branch in the new shared repo over. [04:59] tedg: please use the copy from Launchpad [05:00] Because we know that that copy has that missing record in its repo. [05:00] "bzr check" on your local repos might be interesting, probably it will report the same issue. [05:01] I just successfully branched lp:~ted/inkscape/devbuild from Launchpad, so it appears that that copy isn't missing anything that it is supposed to have. [05:02] ok, dirstate2 works [05:02] time to put a tree on it and user-level test it === JaredWigmore is now known as JaredW [05:02] lifeless: nice [05:03] I just wish we'd not been scraping performance issues right up to 2.0.0 [05:03] this would have been so nice to have in there [05:04] lifeless: yeah. [05:04] I've had this in my head for about a year [05:04] as a 'TUIT' problem [05:06] lifeless, Peng_: well if I tunnel my conection through Miami I can branch it just find, I think that fits well with the proxy theory. I have pretty much the same setup in both machines. [05:06] s/find/fine/ [05:07] You can avoid the issue, and get a speed boost, if you get a LP account and use bzr+ssh. [05:07] I will do, tyvm [05:20] spiv: Okay, so branching that way makes the error MUCH larger: http://pastebin.ubuntu.com/280979/ [05:20] spiv: Still running the check. [05:21] tedg: hmm, looks like text versions from the original SVN import are missing somehow! [05:21] Very odd. [05:22] Oh, that's interesting; one way the missing text revisions were svn-v4:..., the other they are svn-v3-trunk:... [05:23] So could it be a disagreement between versions of the SVN plugin? [05:23] I wonder if a "bzr svn-upgrade" somewhere along the line is part of the cause... [05:24] I don't think there is a svn-upgrade. [05:26] Hmm, I'm sure there used to be a command that would rebase revisions from an older version of a plugin to use the new mapping. [05:26] s/a plugin/the svn plugin/ [05:27] Yes, there was definitely a "bzr svn-upgrade" in the past, I wonder why it's gone now. [05:27] Ah, it's now "bzr foreign-mapping-upgrade" [05:33] spiv: I don't seem to have that command, is it in a plugin? [05:33] The bzr check is still running... is there a point I should give up? [05:34] spiv: your patch landed? [05:39] spiv: It seems to be in rebase. But I can't get it to work. [05:40] It basically says the SVN repository isn't a repository. [05:40] bbiab [05:40] lifeless: yes [05:41] tedg: I'm not very familiar with it, I was just speculating that it may have been involved in the history of this branch. [05:41] I think I'm going to try a new import tonight with the new and shiny 2.0 and see if that helps... start fresh tomorrow. [05:42] spiv, thanks for your help! [05:42] tedg: you're welcome, sorry I couldn't be more helpful [05:55] \o/ [05:55] WTFormat7 passes interface tests [05:56] Does that mean it works right, or that the tests have insufficient coverage? :p [05:57] fullermd: bit of both [05:58] fullermd: I suspect that its possible to make it delete the HASH file for the current pointer with a sufficiently clever flip-flop state change at the moment [05:58] fullermd: so I want to add a random seed to the state files [05:58] fullermd: or tweak that more, before folk are doing more than play with it as a shiny shiny [06:00] fullermd: however, you can do a diff while a commit editor is open [06:02] lifeless: oh yeah, that reminds me [06:02] lifeless: I was also going to ask about two concurrent stat cache updates to the same state [06:02] Which may be why you want some random bits in the filenames? [06:02] spiv: same issue ;) [06:03] * spiv nods [06:03] yes [06:03] in practice, doing 'bzr add foo' 'bzr rm foo' with no other changes can flip flop [06:04] doing 'bzr diff' and keeping the process alive in a GUI in between could cause something that sees the old state around [06:04] but I'm /not sure/ you can force destructive behaviour without being able to run stat fingerprints backwards [06:05] I think simply putting the 'lazy delete' inside the 'I own the current file' "mutex" may be sufficient. [06:05] though if we start doing that I may simply start using regular lockdirs to do the locking, though they will be a lot slower. [06:15] its fun to close 6 bugs with one push :) [06:21] heh, I lied, 7 [06:31] poolie: are you here, or is it just a bot? [06:34]