| jam | morning poolie | 00:01 |
|---|---|---|
| jam | so much for showing up extra early :) | 00:01 |
| poolie | hi jam | 00:56 |
| poolie | heh, well, before 9 :) | 00:56 |
| poolie | i'll try to push that back to a bit eariler | 00:56 |
| poolie | i guess lifeless is away travelling? | 01:04 |
| poolie | so jam how are things for you? | 01:04 |
| jam | poolie: things are going fine. I dug into one of the bugs a bit. Basically reconcile on stacked branches is just broken | 01:08 |
| poolie | mm i saw your mail | 01:08 |
| poolie | that sounds good to fix | 01:08 |
| poolie | is that already pointing at 2.2.0? if not you could target it | 01:09 |
| jam | yes it is pointing at 2.2.0 (hence why I found it) | 01:09 |
| jam | I'm actually targeting the 2.0 series for the fix | 01:09 |
| jam | I think it is reasonable to do there, and reasonable to consider it worthy of a backport | 01:11 |
| jam | poolie: I had an idea about python compatibility. What if we made 2.0-2.2 be compat back to py2.4, but then expected bzr2.3+ to have a higher cutoff. RHEL 6 is in beta now, so it is likely to come out soon and support python 2.6. Then the bzr versions that are available for RHEL5 will still be compat with py2.4 | 01:12 |
| jam | but we will be able to have newer ones have a bit more freedom | 01:12 |
| poolie | that could work | 01:13 |
| poolie | so we'd skip 2.5 entirely? | 01:13 |
| jam | maybe | 01:13 |
| jam | I wasn't sure about going to 2.5 vs 2.6 | 01:13 |
| jam | 2.6 would make it easier to support 3.0 | 01:13 |
| poolie | mm | 01:13 |
| jam | at a cost of having our code more wildly diverge | 01:13 |
| poolie | i'd care a bit more about using 2.6 features than 3.0 at the moment | 01:13 |
| jam | poolie: any specific features? | 01:16 |
| jam | Context objects would be nice, but I think that is 2.5 | 01:16 |
| poolie | that's the only one that comes to mind | 01:17 |
| poolie | 'except Foo as e' is a bit less error prone | 01:17 |
| jam | true | 01:19 |
| jam | though we've already gotten it right for now :) | 01:19 |
| spiv | I nearly got that wrong just the other day, but I caught myself :) | 01:21 |
| === nlisgo_ is now known as nlisgo | ||
| === r0bby_ is now known as robbyoconnor | ||
| === nlisgo_ is now known as nlisgo | ||
| lifeless | poolie: hai | 02:19 |
| lifeless | I has 3g gsm goodness | 02:19 |
| lifeless | or something | 02:19 |
| poolie | hi there | 02:19 |
| poolie | and is it good? | 02:19 |
| poolie | want some lunch? | 02:19 |
| lifeless | poolie: sorry | 02:21 |
| lifeless | key doesn't work to the room, locksmith showed up | 02:21 |
| lifeless | uhm yes, lunch could be good | 02:22 |
| mkanat | jam: If you're around, I can debug the loggerjam^H^H^Hhead stuff with you. | 03:19 |
| lifeless | poolie: hi | 06:48 |
| lifeless | poolie: I'd like to treat production relation issues as high/critical | 06:48 |
| lifeless | https://bugs.edge.launchpad.net/bzr/+bug/585126 prompts me to mention this; I want to move it out of 'new' | 06:48 |
| poolie | uh ok | 06:48 |
| ubot5 | Launchpad bug 585126 in Launchpad Bazaar Integration "sendbranchmail is eating memory (affected: 1, heat: 9)" [High,Triaged] | 06:48 |
| lifeless | it seems like 'incomplete' for bzr, for now | 06:49 |
| lifeless | but thats the status, not the importance field. | 06:49 |
| lifeless | What do you think? | 06:49 |
| poolie | i think i set it to incomplete before the additional data was attached | 06:50 |
| poolie | if this is causing persistent pain to LOSAs and there's enough data to progress it, let's do something | 06:50 |
| lifeless | its bzr task status hadn't been set. | 06:50 |
| poolie | are you asking how to triage it, or that you're actually planning to work on it? | 06:50 |
| lifeless | I've just made it incomplete; I was proposing to set the importance too, to something other than medium. | 06:50 |
| lifeless | the former | 06:50 |
| lifeless | I think we would allocate engineer resources promptly to it, if it were actionable | 06:51 |
| lifeless | and that high or critical is reflective of that. | 06:51 |
| lifeless | I think I'm asking for high, not critical, on reflection. | 06:51 |
| poolie | ok | 06:51 |
| lifeless | its not severe enough to block a bzr release, whatever it is. | 06:51 |
| poolie | i don't think it's critical unless a losa is actively complaining about it | 06:51 |
| lifeless | I'd really like a 'user error' rather than 'invalid' bug status | 07:08 |
| lifeless | because it might be very interesting to do data searches on em | 07:08 |
| lifeless | and it might feel kinder | 07:08 |
| lifeless | mmm, could be argued to be ui issues anyhow, I guess. | 07:08 |
| vila | hi all | 07:09 |
| lifeless | hi vila | 07:10 |
| spiv | lifeless: you could add a tag, I guess. | 07:21 |
| lifeless | yes; little unsatisfactory | 07:21 |
| lifeless | \o/ 1 bug to go | 07:22 |
| lifeless | or is there... I might be done on this pass | 07:22 |
| lifeless | spiv: is there a webnumbr for 'new' bzr bugs ? | 07:24 |
| lifeless | cause its 0 | 07:24 |
| lifeless | :> | 07:24 |
| poolie | hi vila | 07:24 |
| vila | lifeless: yeah ! | 07:25 |
| poolie | lifeless: there's an lpstats graph | 07:25 |
| vila | hey poolie | 07:25 |
| poolie | hey | 07:25 |
| lifeless | poolie: yeah, but thats all like 80's UI and so on | 07:25 |
| poolie | those are some epic test suite patches | 07:25 |
| vila | poolie: nice catch for the 2004 copyright | 07:25 |
| poolie | spiv, still here? | 07:28 |
| poolie | spiv, do you have any qualms about me merging the hpss flush() patch? | 07:28 |
| spiv | poolie: No qualms | 07:30 |
| vila | poolie: hehe, yeah, epic ;) And I didn't even take some suggestions from spiv and lifeless into account yet (and I realized in the middle of the night that some minor changes haven't committed for windows (hackish workflow involving a babune slave)) | 07:30 |
| spiv | lifeless: not yet, feel free to make one. | 07:30 |
| poolie | vila are we there yet? | 07:30 |
| vila | where ? | 07:31 |
| vila | the proposed patches are a definitive step^W staircase to make the tests pass on windows | 07:31 |
| poolie | k | 07:31 |
| vila | the proposed patches are a definitive step^W staircase to make the tests pass on windows | 07:31 |
| poolie | i guess that would be nice | 07:31 |
| vila | grr | 07:31 |
| poolie | it would be nice to lock it in | 07:31 |
| vila | the missing bits can come later or during review | 07:32 |
| poolie | it's not really a high priority goal for us atm though | 07:32 |
| vila | I realized that, but on the other hand there are several demands for more features on babune which are not reasonable to implement if the test suite does not pass for windows | 07:33 |
| vila | (python-2.4, plugins, installers, etc) | 07:33 |
| poolie | true | 07:35 |
| poolie | if it's not totally green it will slip back | 07:35 |
| poolie | thus my wondering how much more we'd have to do | 07:35 |
| vila | yup, and the leaks were a total blocker | 07:35 |
| poolie | mm | 07:35 |
| vila | with my patch we're down to 4/5 failures | 07:36 |
| poolie | i've seen them trying to run under tribunal too | 07:36 |
| poolie | on linux | 07:36 |
| poolie | i'm not sure why, but i suspect it causes different concurrency patterns between threads | 07:36 |
| poolie | if the main thread often blocks | 07:36 |
| poolie | lifeless: after that thread about python3 i think we should reject your merge <https://code.edge.launchpad.net/~lifeless/bzr/py3/+merge/28237> | 07:36 |
| vila | I've fixed so many different possible hangs that I can't even guess which one you're encountering :) | 07:36 |
| poolie | on the grounds that getting to a single codebase from 2.4 through to 3.1 probably won't work | 07:37 |
| poolie | is that ok with you? | 07:37 |
| poolie | :) | 07:37 |
| lifeless | poolie: I'm ok with it being rejected given the wait and see approach that we seem to have settled on in the thread. | 07:37 |
| poolie | well | 07:37 |
| lifeless | I disagree about 'probably' and 'won't' | 07:37 |
| lifeless | :) | 07:37 |
| poolie | you think we certainly can get a single tree that works on 2.4 and 3.1? | 07:38 |
| lifeless | 'would be fugly' | 07:38 |
| lifeless | poolie: I'm quite certain its doable, I'm not certain its desirable. | 07:38 |
| poolie | 'single non-gross codebase' | 07:38 |
| vila | poolie: :) | 07:38 |
| poolie | so i wasn't exactly proposing wait and see | 07:38 |
| poolie | but rather, get 'python -3' clean, and then try using 2to3 | 07:39 |
| lifeless | poolie: It may be the lesser of two evils, all things considered, but I don't have enough info or practical experiments run with 2to3 to make an assertion about that. | 07:39 |
| poolie | as a though experiment | 07:39 |
| poolie | there is no syntax for octal ints that works on both | 07:39 |
| lifeless | poolie: yes, thats the wait and see approach I referenced, and because of that I'm happy to reject that patch. | 07:39 |
| poolie | we can either rewrite them all to decimal | 07:39 |
| poolie | or, we can keep them in 0666 syntax and use 2to3 with only the octal syntax rewriter turned on | 07:39 |
| lifeless | poolie: we need 2 octal ints I think; consolidate to osutils.USER_RWX and USER_RX, or something. | 07:40 |
| poolie | obviously this is a pretty tiny example | 07:40 |
| poolie | but my point is that the second seems at least possibly as good | 07:40 |
| lifeless | poolie: or even use the constants in the os module, or wherever they are | 07:40 |
| poolie | sure | 07:40 |
| poolie | it's just an example | 07:40 |
| lifeless | poolie: right | 07:40 |
| lifeless | poolie: we lack data | 07:40 |
| lifeless | poolie: all concerns aside, we have a plan to get more data. So lets do that. | 07:41 |
| poolie | great | 07:41 |
| lifeless | poolie: We have different opinions about what the data is likely to tell us. | 07:41 |
| lifeless | poolie: which is fine :) | 07:41 |
| spiv | int('666', 8) works in both 2.4 and 3.1 | 07:45 |
| vila | evil... | 07:45 |
| poolie | heh | 07:45 |
| lifeless | spiv: \o/ | 07:45 |
| spiv | I wouldn't want to put that in an inner loop :) | 07:46 |
| lifeless | no | 07:46 |
| lifeless | but when we're that much into tuning we get into function params etc anyhow | 07:46 |
| lifeless | so we could do it there | 07:46 |
| vila | but perfectly fine as osutils.o666 | 07:46 |
| lifeless | sure | 07:47 |
| poolie | sheesh _example_ | 07:47 |
| lifeless | though I'd name it better | 07:47 |
| vila | _bike shedding_ ! | 07:47 |
| poolie | perhaps 'except Foo as e' is a better example | 07:47 |
| lifeless | poolie: we're a fun company of non pedantic individuals | 07:47 |
| poolie | it's a purely mechanical transform | 07:47 |
| lifeless | Hmm | 07:47 |
| lifeless | I suspect you could write a | 07:48 |
| lifeless | except:\ncatch(Foo, 'e') | 07:48 |
| lifeless | that would work on all python versions. | 07:48 |
| lifeless | and make folk cry if they ever read its internals. | 07:48 |
| poolie | probably | 07:48 |
| lifeless | (not suggesting it!) | 07:48 |
| poolie | might be a bit messy if you needed multiple catch branches | 07:49 |
| vila | so as far as automating code translation, my vote would be to target 2to3 while we support 2.4 and target 3to2 when we switch to support mainly 3.x | 07:49 |
| lifeless | vila: I think that this is too early to talk about | 07:49 |
| lifeless | we don't know if 2to3 will work well yet; we're going to gather data | 07:49 |
| vila | sure, my bet is that we'll end up carrying our own 2to3 if only to take our idiosyncrasies into account | 07:50 |
| vila | but I'll shut up now ;) | 07:50 |
| lifeless | vila: I mean *even doing that* - pretty much every has to add fixers, its part of the design of 2to3 (to be an 80% solution, local knowledge fixes local gaps) | 07:51 |
| vila | just wanted to mention I've done my share of automated conversions from os1 to os2, langugae1 to language2, db1 to db2, and so on | 07:51 |
| vila | yup, the workload is always split across: fix the translator, fix the input | 07:53 |
| vila | we have a big advantage here with our test suite... | 07:53 |
| vila | make that BIG | 07:53 |
| lifeless | poolie: oslocks | 07:58 |
| lifeless | poolie: and dirstate | 07:58 |
| vila | ob: must die | 07:58 |
| lifeless | I've just been doing bug stuff :) - but I was reminded that while we *could* fix the concurrent use of st and diff with commit by moving to a separate stat cache - so we don't write to the dirstate when we run iter_changes | 07:59 |
| lifeless | that wouldn't remove the os locks and the locks themselves are a cause of bugs with corrupt dirstates not being written to disk, bad out of space behaviour, and AFS/NFS issues. | 07:59 |
| mgz | morning all | 07:59 |
| lifeless | poolie: so its rather solidified my opinion that we really do want the complexit of a pack-like structure for the dirstate, and the separate stat cache *at most* reduces the writer concurrency requirements on that structure. | 08:00 |
| lifeless | vila: well yes, but its more nuanced than that ;) | 08:00 |
| vila | hehe | 08:01 |
| lifeless | it has a cost, we need to know what we're buying :) | 08:01 |
| poolie | i think i agree with that | 08:06 |
| poolie | not sure what you mean by "at most" though | 08:06 |
| poolie | lifeless, vila, https://code.edge.launchpad.net/~mbp/bzr/deprecation/+merge/27582 is updated per your comments about using overrideAttr | 08:13 |
| lifeless | thanks | 08:14 |
| lifeless | looking | 08:14 |
| lifeless | poolie: I mean that if split out the stat cache again, it doesn't fix the os locks or make the pack-like structure on disk for dirstate much simpler; it only removes one of 3 or so requirements | 08:15 |
| poolie | right | 08:15 |
| poolie | i don't think just splitting it out would be worth a format bump | 08:15 |
| poolie | i'm sending the hpss flush patch to pqm | 08:18 |
| lifeless | kk | 08:20 |
| lifeless | I'm 'waiting for bugs.edge.launchpad.net' | 08:21 |
| lifeless | oh, foo, parthm is gone again | 08:30 |
| lifeless | poolie: rereviewed | 08:34 |
| lifeless | spiv: ping | 08:35 |
| lifeless | spiv: I know its EOD, but hpss effort tests + foreign formats, could use some airtime | 08:36 |
| vila | poolie: approved, oh lifeless reviewed it too | 08:37 |
| vila | so, yeah, see https://bugs.edge.launchpad.net/bzr/+bug/597791/comments/1 | 08:38 |
| ubot5 | Launchpad bug 597791 in Bazaar "test_http load_tests is overly complex and hard to understand (affected: 1, heat: 6)" [Wishlist,Confirmed] | 08:38 |
| vila | the tests pass, I've just checked, TestActivityMixin.setUp() calls TestCase.setUp() so the code is right but ugly | 08:39 |
| lifeless | losa ping; what version of testtools is installed in the balleny bzr pqm chroot please | 08:39 |
| lifeless | I want to know what features are available :) | 08:40 |
| mthaddon | lifeless: 0.9.2-1~0.CAT.8.04 | 08:40 |
| lifeless | thanks heaps | 08:40 |
| vila | poolie: this patch will certainly conflict with my cleanup patch so it will be simpler for both of us if you land yours first and I'll address the conflicts with mine | 08:41 |
| spiv | lifeless: like the loom issue? | 08:41 |
| lifeless | precisely and | 08:41 |
| lifeless | I can solve that one easily | 08:41 |
| lifeless | its rather specific | 08:41 |
| lifeless | just convert to a matcher and provide an Or test in there | 08:41 |
| spiv | Perhaps related, it would be good to start thinking about extending the smart protocol in the loom plugin | 08:42 |
| lifeless | spiv: I have been :) | 08:42 |
| spiv | e.g. maybe add a verb for set_loom_state? | 08:42 |
| spiv | Oh, great! :) | 08:42 |
| lifeless | spiv: ignoring questions about what level to operate at, it raises questions about how to add the client side | 08:42 |
| lifeless | the server is nicely extensible | 08:42 |
| lifeless | the client side proxy rather less so | 08:42 |
| spiv | Right. | 08:42 |
| lifeless | and I'm thinking perhaps the _real_format could add methods | 08:43 |
| lifeless | make RemoteBranch more of a composite | 08:43 |
| lifeless | anyhow, neither of those things would make the test better, because plugins will want to call different verbs | 08:43 |
| lifeless | and we trace verbs | 08:43 |
| lifeless | spiv: for loom it happens to be easy, but what about e.g. bzr-svn | 08:44 |
| lifeless | spiv: if you have an svn repo | 08:44 |
| lifeless | and access it via bzr push bzr+ssh://host/svn/repo/branch | 08:45 |
| lifeless | > | 08:45 |
| spiv | Yes, what indeed. | 08:45 |
| lifeless | I don't have answers | 08:45 |
| spiv | I suppose one answer would be to allow the plugin to set its own call-count requirements. | 08:45 |
| lifeless | the test isn't structured quite that way, but we could rephrase it. | 08:45 |
| lifeless | Another would be to say that this test is format specific | 08:45 |
| lifeless | but that adds a burden if/when we rev formats | 08:46 |
| spiv | Or something like "here's the call trace core bzr expects, and core bzr will match that specific trace. Plugins can override that trace and/or matcher." | 08:46 |
| lifeless | yeah that too | 08:47 |
| spiv | You could have extreme corner cases with e.g. inter-branch tests from one plugin format to another plugin's format. | 08:47 |
| lifeless | definitely | 08:48 |
| lifeless | so | 08:48 |
| spiv | I don't have any great ideas. I'd be very happy to start with whatever is needed for looms tests to pass without feeling too ugly. | 08:48 |
| lifeless | I'm inclined to lowbrow it right now | 08:48 |
| spiv | +1 | 08:48 |
| lifeless | and hard code in 'get is ok' | 08:48 |
| lifeless | [a single get] | 08:48 |
| spiv | That's ok with me. For now the main concern is "confident the core is not regressing", followed by "loom can pass tests", I think. I think you can hard code and meet those goals. | 08:50 |
| lifeless | spiv: what do you think: | 09:02 |
| lifeless | http://pastebin.com/4XLwfMdJ | 09:02 |
| vila | ...or merge loom into bzr-core | 09:02 |
| lifeless | vila: that wouldn't help | 09:02 |
| lifeless | vila: because the loom format would still behave differently. | 09:03 |
| spiv | lifeless: looking now | 09:04 |
| spiv | lifeless: I worry about the risk that the core could regress with that patch | 09:05 |
| vila | lifeless: sure, but the issues will be easier to address, anyway, I don't think it's the right time for this, just mentioning it as middle term goal | 09:05 |
| spiv | other than that, it looks reasonable. | 09:06 |
| vila | I think it's one more case where we want the parametrization to be more pluggable for plugins | 09:06 |
| lifeless | vila: I really don't see it being easier | 09:07 |
| lifeless | vila: different maybe. | 09:07 |
| lifeless | spiv: anything I can do to mitigate your concern ? | 09:07 |
| lifeless | spiv: scratch that. Anything *you want me to do to get +1* on the patch :P | 09:07 |
| vila | core mentioning loom (an external plugin) is wrong, if it was in core it would be right | 09:08 |
| spiv | lifeless: perhaps some sort of "if purely_core_scenaro" guard? Not sure. | 09:08 |
| spiv | lifeless: for this specific case I'd probably accept an convincing argument that the practical risk of the core regressing in exactly that way is low :) | 09:09 |
| lifeless | its very low. | 09:09 |
| lifeless | vila: if it was in core, in a per_interbranch parameterised test, its still wrong. | 09:10 |
| lifeless | vila: abstraction leak; we're being pragmatic about time and goals here is all :P | 09:10 |
| lifeless | spiv: concretely | 09:11 |
| lifeless | spiv: the test claims that it tests for get_parent_map missing | 09:11 |
| lifeless | spiv: so its overly sensitive in using an exact list | 09:11 |
| vila | the test is about: "he client has no reason to query the remote graph any further" does loom cares here ? | 09:11 |
| vila | hehe, we agree :) | 09:11 |
| lifeless | spiv: this test change does not open the door for get_parent_map | 09:11 |
| lifeless | vila: loom in general - yes. In specific , no. | 09:12 |
| lifeless | in general yes because it does push-per-thread | 09:12 |
| vila | yup, may be the test is too high-level | 09:12 |
| === oubiwann is now known as oubiwann-away | ||
| === oubiwann-away is now known as oubiwann | ||
| lifeless | spiv: I'm going to propose it as a merge; vila may +1 it :> | 09:26 |
| vila | lifeless: as long as it includes a comment explaining the constraints here, sure ;-) | 09:27 |
| lifeless | vila: well, its the patch I put up. | 09:30 |
| lifeless | vila: you wanted a passing test suite; its up to you :) | 09:31 |
| vila | which patch ? The one you pasted ? | 09:32 |
| lifeless | https://code.edge.launchpad.net/~lifeless/bzr/loomsupport/+merge/28375 | 09:32 |
| lifeless | yes | 09:32 |
| vila | weird, it didn't appear in the active review page until you mentioned it here :) | 09:35 |
| vila | lifeless: approved, please land | 09:35 |
| lifeless | vila: can you toggle the merge bit too in future, please | 09:36 |
| vila | grrrr | 09:36 |
| vila | sorry | 09:36 |
| vila | done | 09:36 |
| vila | Am I the only one who keep forgetting that merge bit ? | 09:39 |
| lifeless | no | 09:39 |
| lifeless | I want a cron job | 09:39 |
| lifeless | that assesses the votes and sets it | 09:39 |
| vila | ha cool | 09:40 |
| vila | oh, and thanks for that fix, I will get rid of my workaround as soon as it lands | 09:40 |
| lifeless | poolie: another thing I find annoying about gmail - the use of first names only | 09:58 |
| lifeless | I know many Martins, and many Johns. | 09:58 |
| lifeless | vila: btw | 09:58 |
| lifeless | vila: threads in paramiko: teach paramiko to accept a thread factory replacement parameter. | 09:59 |
| vila | lifeless: yes, that's probably the way to go but I felt too weak to go there and there may be a different way to run the paramiko code into the threads we already have (the way the test server implementation without ssh support works is an hint) | 10:02 |
| vila | but overall since the paramiko daemonic threads appear to die naturally I punted :-> | 10:03 |
| lifeless | vila: for sftp it makes its own ones, I think | 10:03 |
| vila | it makes its own ones as soon as it needs a wrapper for ssh | 10:04 |
| vila | at least they are the only ones I left | 10:04 |
| vila | and it uses timeouts there which... re-open the same can of worms I was getting away from, so, as long as it works... I prefer to left it as is as I know it will be a nightmare to debug and probably hardly fixable without fixing paramiko which in turn will make it harder to keep it as an external dependency | 10:06 |
| vila | huge effort, small reward :-/ | 10:06 |
| lifeless | vila: timeouts are fairly good for defensive programming | 10:36 |
| lifeless | vila: I wouldn't want to get rid of them | 10:36 |
| lifeless | mgz: you'll be glad to know we broke subunit trunk with our patch | 10:50 |
| lifeless | mgz: 58 errors :) | 10:50 |
| lifeless | mgz: some of which are testtools bugs | 10:52 |
| jml | how do I stop getting bzr bug mail | 10:54 |
| lifeless | I think you have two choices | 10:54 |
| lifeless | you can either leave the relevant control team | 10:54 |
| lifeless | or you may be able to individually explicitly subscribe to all the bugs in the same place the team is subscribed | 10:54 |
| lifeless | with a subscription of 'I'm not subscribed' | 10:55 |
| lifeless | its the same conflation of 'power/access/interest' pattern we have in LP | 10:55 |
| lifeless | jml: oh, and I'm sorry if I tripped your 'zomg' threshold with bug spam today. | 10:55 |
| jml | lifeless, not at all. it's been bugging me for a while. | 10:56 |
| jml | lifeless, I like bzr a lot, but I never ever read the bug or MP mail any more | 10:56 |
| gustavonarea | Hello. Does anyone know how to migrate multiple related Mercurial branches to Bazaar? I know I have to use --marks/--import-marks/--export-marks, but it doesn't seem obvious to me how to do it and I cannot find anything in docs or the Web. All I find is documents explaining how to migrate from bazaar to git using marks. | 10:56 |
| lifeless | gustavonarea: can't you just install bzr-hg ? | 10:56 |
| gustavonarea | lifeless: it hangs the computer and then gets killed by the OS | 10:58 |
| lifeless | oh, thats a little undesirable | 10:58 |
| gustavonarea | And that happens on a high spec server; I wouldn't try it on my laptop | 10:59 |
| gustavonarea | any idea how to do it with fast-import/export? | 11:00 |
| lifeless | not personally sorry; maybe the bzr list, or the bugtracker, will know more. | 11:00 |
| gustavonarea | thanks lifeless! I'll stay around just in case :) | 11:02 |
| lifeless | mgz: I've pushed a one-character fix; so small I'm not even going to ask jml for a review. | 11:03 |
| jml | lifeless, don't you care about quality?!?!!!!1!!??!? | 11:05 |
| lifeless | jml: no, not at all. | 11:05 |
| lifeless | mgz: jml: anyhow, trunk of both play nice together once more. | 11:07 |
| jml | \o/ | 11:09 |
| vila | lifeless: timeouts lead to hard to track bugs with threads and sockets in our case, they *are* good for defensive programming but they shouldn't be used to work around synchronisations issues (which was the case here) | 11:09 |
| lifeless | vila: agreed | 11:10 |
| vila | lifeless: I think I don't understand what you're after in the smart-server-leaks threads, I just posted a comment but discussing it here may be more effective (if you're still available) | 11:15 |
| vila | s/threads/merge proposal/ | 11:15 |
| lifeless | vila: you appear to have done the following: | 11:16 |
| lifeless | - rearranged some code | 11:16 |
| lifeless | - added a new, strange, public method which users would not expect to have to call | 11:17 |
| lifeless | I am neutral on the first and against the second | 11:17 |
| lifeless | vila: I don't understand why the second is needed | 11:17 |
| lifeless | if I understood why, I would stop being against it :) | 11:17 |
| lifeless | I would like to see internal behaviours kept internal | 11:18 |
| vila | because I want to reuse most of the code there but *not* creating the server socket as part of building the object | 11:18 |
| lifeless | I may have it wrong; it may still be internal and the diff is confusing me | 11:18 |
| lifeless | vila: I don't mind if the creation is separate to building the object, thats orthogonal to my concerns | 11:18 |
| vila | well, the actual code does too much in __init__ for my needs so the socket creation has to be done outside of it | 11:19 |
| lifeless | sure | 11:19 |
| vila | I can create a base class to address that but that sounded too bug a hammer | 11:19 |
| vila | big | 11:19 |
| lifeless | I repeat, I'm fine with the separate method. | 11:19 |
| lifeless | I'm not fine with who has to call it | 11:20 |
| vila | now, I don't think users *have* to call it as it's now called by the smart server factory, | 11:20 |
| lifeless | if it was called start() I would be fine | 11:20 |
| vila | ha, ok, so public and a better name ? | 11:20 |
| lifeless | vila: the smart server factory is a user of the class the method is on | 11:20 |
| lifeless | the connection between the two should be clear, or the factory shouldn't exist. | 11:20 |
| lifeless | by which I mean, if we have two components, we should have *two* components, not one-and-a-half | 11:21 |
| vila | hmm, there is already start_background_thread/stop_background_thread but no start/stop >-/ | 11:22 |
| lifeless | why isn't it part of one of those methods, for instance? | 11:23 |
| vila | cause I'm lazy ? :) | 11:23 |
| lifeless | heh | 11:24 |
| lifeless | I'm lazy too | 11:24 |
| lifeless | I think I'd have tried to find a way where i didn't change callers. | 11:24 |
| vila | kidding, because I was unclear about how this class was used and wanted to just pick the good bits | 11:24 |
| vila | my overall feeling (backed by some discussion with spiv) is that the actual design is *good enough* and I think we may want to improve it but I didn't want to do that as part of my patch | 11:25 |
| vila | not a good reason to make it worse though | 11:25 |
| lifeless | right | 11:26 |
| lifeless | I fully agree with that | 11:26 |
| vila | hmm, the server factory has a set_up/tear_down but don't use start_background_thread/stop_background_thread... that's part of the friction I think | 11:27 |
| vila | hmm, and start_background_thread/stop_background_thread is, in fact, used by TestSmartTCPServer for a single test and overlap with TestingTCPServerInAThread too >-/ | 11:30 |
| gustavonarea | How can I add an alias to my branches, like "lp" for launchpad.net? I've check the docs and searched for this on the Web but I didn't find anything | 12:10 |
| lifeless | bzr-bookmarks plugin | 12:10 |
| lifeless | I think | 12:10 |
| gustavonarea | I'd like to something like "bzr branch foo:trunk" where "foo:trunk" gets translated to "bzr+ssh://example.org/path/to/trunk" | 12:11 |
| gustavonarea | ah ok, thanks lifeless | 12:11 |
| maxb | gustavonarea: See http://doc.bazaar.canonical.com/plugins/en/bookmarks-plugin.html, I think for the style of prefix you want, you might need to write a tiny plugin of your own | 12:12 |
| gustavonarea | cool, thanks maxb | 12:13 |
| gustavonarea | maxb: any pointers on how to write a plugin like that? | 12:15 |
| vila | the bookmarks plugin :) | 12:15 |
| gustavonarea | ok, thanks vile | 12:16 |
| gustavonarea | * vila | 12:16 |
| maxb | Or the built in launchpad plugin | 12:16 |
| vila | yup, as maxb said, but the lp plugin do more than that so may be harder to grasp | 12:16 |
| maxb | The bzr feature that you need to interact with is called directories | 12:17 |
| gustavonarea | thanks maxb! | 12:30 |
| === khmarbaise_ is now known as khmarbaise | ||
| === verterok_ is now known as verterok | ||
| rbriggsatuiowa | when working with feature branches and a trunk - if I am merging feature branches into trunk - which is a better workflow? merging trunk into feature, then feature into trunk or just try and merge feature into trunk (ran into a case where it wasn't pulling all the changes from a feature until I merged trunk into due to weirdness with reverse and forward merges) | 16:25 |
| rbriggsatuiowa | (my problem is resolved - I was just wondering for future reference what the preferred workflow is) | 16:25 |
| fullermd | I normally go by a gut feeling of "are there going to be non-trivial conflicts to resolve?" | 16:28 |
| fullermd | If it'll land easy, JFDI. If not, do the merge in the branch and deal with the fallout, then land it. | 16:29 |
| fullermd | And then kick yourself for not pre-emptively merging trunk into feature on a regular ongoing basis in the first place :p | 16:29 |
| rbriggsatuiowa | fullermd: cool - thanks (or yell at the people working on the feature for not pulling in :) | 16:29 |
| rubbs | fullermd: fwiw, that's the way I do it too. | 16:50 |
| === beuno is now known as beuno-lunch | ||
| === cody-somerville_ is now known as cody-somerville | ||
| === radoe__ is now known as radoe | ||
| === deryck is now known as deryck[lunch] | ||
| === beuno-lunch is now known as beuno | ||
| === oubiwann is now known as oubiwann-away | ||
| === oubiwann-away is now known as oubiwann | ||
| === deryck[lunch] is now known as deryck | ||
| lifeless | good morning | 19:26 |
| jelmer | hello | 19:27 |
| mgz | <lifeless> mgz: you'll be glad to know we broke subunit trunk with our patch | 19:39 |
| mgz | urk? | 19:40 |
| lifeless | mgz: for starters pull testtools trunk | 19:40 |
| lifeless | and diff -c -1 | 19:40 |
| mgz | subunit hits a path not in the testtools testsuite at all? | 19:40 |
| lifeless | then slap self on forehead (I did this) and mutter 'coverage dagnammit' | 19:40 |
| mgz | right, done that | 19:40 |
| mgz | but for dammit-ness | 19:40 |
| mgz | - return ''.join(chars) | 19:40 |
| mgz | + return u''.join(chars) | 19:40 |
| lifeless | yes | 19:40 |
| lifeless | as I said, 1-character fix. | 19:40 |
| mgz | Python 3 SyntaxError | 19:40 |
| lifeless | hahaha | 19:41 |
| mgz | need a _ and a ( and a ) | 19:41 |
| lifeless | 4 character fix coming up | 19:41 |
| lifeless | I'll uncommit that one | 19:41 |
| mgz | I'm a little perpelexed that this isn't tested but testtools itself though | 19:41 |
| lifeless | I was tirrrred last night | 19:41 |
| lifeless | so am I | 19:41 |
| lifeless | it has done a sneaky I think | 19:42 |
| mgz | I take it the issue is with details objects with no textual components | 19:42 |
| lifeless | TestResult isn't getting exercise | 19:42 |
| mgz | which then means we get a str object on Python 2, which we're now throwing a TypeError over | 19:42 |
| lifeless | mgz: thats probably it | 19:42 |
| lifeless | yes to the str object | 19:42 |
| lifeless | probably to the proximate cause | 19:43 |
| lifeless | subunit had a bunch of literals I 'u'ified | 19:43 |
| lifeless | as its not py3 ready anyway its no great loss | 19:43 |
| lifeless | need to migrate them to _u() | 19:43 |
| lifeless | or py2to3, though like bzr, subunit supports much older pythons | 19:43 |
| mgz | alternative spelling, str().join | 19:46 |
| lifeless | mgz: for what? | 19:47 |
| mgz | u"".join | 19:47 |
| lifeless | how does that work on 2.x? | 19:47 |
| mgz | doh. | 19:47 |
| lifeless | lol | 19:48 |
| jam | lifeless: you mentioned the idea of "refreshing the pack index" to try and get things to behave correctly. Is that Repository._refresh_data() ? | 21:12 |
| lifeless | jam: sounds like | 21:12 |
| * lifeless noses around | 21:12 | |
| jam | lifeless: k, that doesn't work :) | 21:12 |
| lifeless | oh! thats very interesting. | 21:13 |
| lifeless | and yes, thats what it is | 21:13 |
| lifeless | the base class docstring says it all. | 21:13 |
| jam | I'll also note that I got weird behavior wrt stacking fetch based on ordering | 21:14 |
| jam | if I created the stacked repo before I populated the base | 21:14 |
| jam | then the base revision would always get fetched | 21:14 |
| jam | I think spiv mentioned something like that | 21:14 |
| lifeless | spiv just fixed a bug there | 21:15 |
| jam | (now there, _refresh_data *might* do something, though) | 21:15 |
| lifeless | pull his patch | 21:15 |
| jam | well, I'm working in 2.0, and I can workaround it in the test by create_base() fetch_base(), create_stacked() | 21:15 |
| lifeless | he says his patch is a candidate for 2.x+ | 21:15 |
| lifeless | and I agree | 21:15 |
| jam | same here | 21:16 |
| jam | but it was just an observation, not something blocking me | 21:16 |
| lifeless | ok | 21:17 |
| jelmer | lifeless: do you know what the time planning is for 2.2 ? | 21:32 |
| lifeless | no | 21:33 |
| lifeless | it should happen | 21:33 |
| jam | lifeless: repo.bzrdir.open_repository() doesn't set fallback repositories? | 21:33 |
| lifeless | jam: thats right | 21:34 |
| jam | lifeless: Bazaar/Calendar/2010 says b4 on July1st, and 2.2.0 on July 29th | 21:34 |
| lifeless | jam: branches define the fallbacks | 21:34 |
| jam | lifeless: that seems to be why one succeeds and one fails | 21:34 |
| lifeless | policy in branch, implementation in repo | 21:34 |
| lifeless | jam: ah! | 21:34 |
| jam | RepoReconciler calls repo.all_revision_ids() | 21:34 |
| jam | and gets different results when a repo is stacked | 21:34 |
| lifeless | yeah, reconcile is meant to work with a no-fallbacks repo | 21:34 |
| lifeless | you might like to add an assertion-like-check to the reconciler objects | 21:35 |
| jam | lifeless: there isn't a "remove_fallback_repo" command, is there? | 21:35 |
| lifeless | they'll misbehave terribly otherwise | 21:35 |
| lifeless | jam: not offhand; it would need to flush all cached graph objects and so on that had been opened from it | 21:36 |
| lifeless | jam: so it would be pretty awfully complex | 21:36 |
| lifeless | / prone to misused | 21:36 |
| jam | so Reconciler does take a bzrdir and directly opens the repo | 21:37 |
| jam | but repo.reconcile() just uses self | 21:37 |
| lifeless | jam: https://code.edge.launchpad.net/~jameinel/bzr/2.0.5-switch-unicode-317778/+merge/19121 | 21:38 |
| lifeless | is that abandonware :) ? | 21:38 |
| jam | lifeless: well, not *my* code at least | 21:39 |
| jam | mostly proposing the patch that was in the bug | 21:39 |
| jelmer | jam, lifeless: Ah, so I guess I have less than a wek left to get the final API changes for colocated branches in place? | 21:40 |
| jam | jelmer: I'm pretty sure we decided to API freeze for 2.2b4 | 21:40 |
| jam | to give plugins time to stabilize | 21:40 |
| lifeless | jelmer: no last minute stuff | 21:40 |
| lifeless | jelmer: you have layer inversions still, last Isaw | 21:40 |
| lifeless | jelmer: I really think we should say colocated is still unsupported, and work on it in 2.3 | 21:40 |
| lifeless | make it as clean as possible, its going to be the underpinnings for apis for years | 21:41 |
| jam | lifeless: so for the mp, I would reject the code as-is, and I don't think philyoon is going to work on it | 21:42 |
| jam | It sort of depends how high we want to prioritize it for us | 21:42 |
| jam | *I* don't need it | 21:42 |
| lifeless | well | 21:42 |
| lifeless | I'm reviewing bugs-with-patches | 21:42 |
| jam | bialix and others may | 21:42 |
| lifeless | found quite a few closed | 21:42 |
| jam | lifeless: ValueError reasonable for "_fallback_repository is not empty" ? | 21:47 |
| jam | or just a generic BzrError? | 21:47 |
| lifeless | either is fine for me | 21:47 |
| lifeless | we expect API users only to encounter it. | 21:47 |
| jam | right | 21:51 |
| jam | lifeless: so Pack format repos fail reconcile because the target pack already exists. | 21:54 |
| === oubiwann is now known as oubiwann-away | ||
| jam | do you think it is reasonable to catch FileExists in _reconcile_pack | 21:54 |
| jam | or should I catch and skip in the test. | 21:54 |
| lifeless | sure | 21:54 |
| lifeless | uhm | 21:54 |
| lifeless | my dream | 21:54 |
| === oubiwann-away is now known as oubiann | ||
| jam | Today it is a bit annoying that 'bzr reconcile' fails on pristine repos. | 21:54 |
| lifeless | implement catch, byte-compare | 21:55 |
| jam | I know we'd like to have the consistency check | 21:55 |
| jam | but that is a bit out-of-scope | 21:55 |
| lifeless | offhand I think catching it in reconcile is ok | 21:55 |
| lifeless | after all reconcile isn't adding data to the repo | 21:55 |
| lifeless | its like pack() | 21:55 |
| jam | lifeless: the alternative is to have NewPack.finish() do something special to indicate it shouldn't be used after all | 21:56 |
| jam | we've already done "self._use_pack(new_pack)" which checked to see if data was inserted | 21:56 |
| jam | until we call finish_content() we don't know the final name of the pack file, to know if it will collide | 21:58 |
| jam | lifeless: and that is called from NewPack.finish() | 21:58 |
| lifeless | sure | 21:59 |
| lifeless | I'm ok with catching it; no real opinion :_ | 21:59 |
| lifeless | :) | 21:59 |
| jam | the only other problem is that we can get a collision on disk and the file *isn't* in pack-names | 22:00 |
| jam | (if someone ^C's during autopack, and then runs it again, I think) | 22:00 |
| jam | note also that this doesn't really affect Linux users, since transport.rename() will overwrite the existing file (I believe) | 22:00 |
| jam | it affects sftp, though | 22:01 |
| lifeless | did you see the question on lp about a case of that? | 22:01 |
| jam | https://code.launchpad.net/~geoff.bache/bzr/trunk/+merge/28463 has a serious issue about NEWS | 22:02 |
| lifeless | yeah | 22:02 |
| jam | lifeless: I saw a question about a file being in pack-names but having been renamed to obsolete_packs, which is a different thing | 22:02 |
| lifeless | jam: thats the one I was thinking of | 22:02 |
| lifeless | I was wondering how we could gather more data on that | 22:03 |
| lifeless | in an acceptably safe manner | 22:03 |
| lifeless | there is also some redundancy with other work in that patch | 22:04 |
| jelmer | lifeless: for when is 2.3 planned? | 22:12 |
| jam | jelmer: approx 6months from the release of 2.2 | 22:12 |
| jelmer | jam: ah, thanks | 22:12 |
| jam | by the 'standard' calendar | 22:12 |
| === oubiann is now known as oubiwann | ||
| === oubiwann is now known as oubiann | ||
| spiv | jam, lifeless: thinking of SFTP rename, I see that OpenSSH has an extension to the SFTP protocol for a POSIX rename. | 23:32 |
| jam | spiv: is that sort of like having sftp v7 implemented? | 23:32 |
| spiv | It's described in http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/PROTOCOL?rev=HEAD | 23:32 |
| lifeless | I'd like to: | 23:40 |
| lifeless | - define a standard protocol for moving files with a known/predictable temp name; that will catch that file existing first and error so that calling code can rollback partial things/whatever | 23:41 |
| lifeless | - use that around everything that replaces single files | 23:41 |
| lifeless | because we can never be sure that someone isn't sitting on the local disk on windows. | 23:41 |
| === oubiann is now known as oubiwann | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!