jammorning poolie00:01
jamso much for showing up extra early :)00:01
pooliehi jam00:56
poolieheh, well, before 9 :)00:56
pooliei'll try to push that back to a bit eariler00:56
pooliei guess lifeless is away travelling?01:04
poolieso jam how are things for you?01:04
jampoolie: things are going fine. I dug into one of the bugs a bit. Basically reconcile on stacked branches is just broken01:08
pooliemm i saw your mail01:08
pooliethat sounds good to fix01:08
poolieis that already pointing at 2.2.0? if not you could target it01:09
jamyes it is pointing at 2.2.0 (hence why I found it)01:09
jamI'm actually targeting the 2.0 series for the fix01:09
jamI think it is reasonable to do there, and reasonable to consider it worthy of a backport01:11
jampoolie: 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.401:12
jambut we will be able to have newer ones have a bit more freedom01:12
pooliethat could work01:13
poolieso we'd skip 2.5 entirely?01:13
jamI wasn't sure about going to 2.5 vs 2.601:13
jam2.6 would make it easier to support 3.001:13
jamat a cost of having our code more wildly diverge01:13
pooliei'd care a bit more about using 2.6 features than 3.0 at the moment01:13
jampoolie: any specific features?01:16
jamContext objects would be nice, but I think that is 2.501:16
pooliethat's the only one that comes to mind01:17
poolie'except Foo as e' is a bit less error prone01:17
jamthough we've already gotten it right for now :)01:19
spivI 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
lifelesspoolie: hai02:19
lifelessI has 3g gsm goodness02:19
lifelessor something02:19
pooliehi there02:19
poolieand is it good?02:19
pooliewant some lunch?02:19
lifelesspoolie: sorry02:21
lifelesskey doesn't work to the room, locksmith showed up02:21
lifelessuhm yes, lunch could be good02:22
mkanatjam: If you're around, I can debug the loggerjam^H^H^Hhead stuff with you.03:19
lifelesspoolie: hi06:48
lifelesspoolie: I'd like to treat production relation issues as high/critical06:48
lifelesshttps://bugs.edge.launchpad.net/bzr/+bug/585126 prompts me to mention this; I want to move it out of 'new'06:48
poolieuh ok06:48
ubot5Launchpad bug 585126 in Launchpad Bazaar Integration "sendbranchmail is eating memory (affected: 1, heat: 9)" [High,Triaged]06:48
lifelessit seems like 'incomplete' for bzr, for now06:49
lifelessbut thats the status, not the importance field.06:49
lifelessWhat do you think?06:49
pooliei think i set it to incomplete before the additional data was attached06:50
poolieif this is causing persistent pain to LOSAs and there's enough data to progress it, let's do something06:50
lifelessits bzr task status hadn't been set.06:50
poolieare you asking how to triage it, or that you're actually planning to work on it?06:50
lifelessI've just made it incomplete; I was proposing to set the importance too, to something other than medium.06:50
lifelessthe former06:50
lifelessI think we would allocate engineer resources promptly to it, if it were actionable06:51
lifelessand that high or critical is reflective of that.06:51
lifelessI think I'm asking for high, not critical, on reflection.06:51
lifelessits not severe enough to block a bzr release, whatever it is.06:51
pooliei don't think it's critical unless a losa is actively complaining about it06:51
lifelessI'd really like a 'user error' rather than 'invalid' bug status07:08
lifelessbecause it might be very interesting to do data searches on em07:08
lifelessand it might feel kinder07:08
lifelessmmm, could be argued to be ui issues anyhow, I guess.07:08
vilahi all07:09
lifelesshi vila07:10
spivlifeless: you could add a tag, I guess.07:21
lifelessyes; little unsatisfactory07:21
lifeless\o/ 1 bug to go07:22
lifelessor is there... I might be done on this pass07:22
lifelessspiv: is there a webnumbr for 'new' bzr bugs ?07:24
lifelesscause its 007:24
pooliehi vila07:24
vilalifeless: yeah !07:25
poolielifeless:  there's an lpstats graph07:25
vilahey poolie07:25
lifelesspoolie: yeah, but thats all like 80's UI and so on07:25
pooliethose are some epic test suite patches07:25
vilapoolie: nice catch for the 2004 copyright07:25
pooliespiv, still here?07:28
pooliespiv, do you have any qualms about me merging the hpss flush() patch?07:28
spivpoolie: No qualms07:30
vilapoolie: 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
spivlifeless: not yet, feel free to make one.07:30
poolievila are we there yet?07:30
vilawhere ?07:31
vilathe proposed patches are a definitive step^W staircase to make the tests pass on windows07:31
vilathe proposed patches are a definitive step^W staircase to make the tests pass on windows07:31
pooliei guess that would be nice07:31
poolieit would be nice to lock it in07:31
vilathe missing bits can come later or during review07:32
poolieit's not really a high priority goal for us atm though07:32
vilaI 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 windows07:33
vila(python-2.4, plugins, installers, etc)07:33
poolieif it's not totally green it will slip back07:35
pooliethus my wondering how much more we'd have to do07:35
vilayup, and the leaks were a total blocker07:35
vilawith my patch we're down to 4/5 failures07:36
pooliei've seen them trying to run under tribunal too07:36
poolieon linux07:36
pooliei'm not sure why, but i suspect it causes different concurrency patterns between threads07:36
poolieif the main thread often blocks07:36
poolielifeless: after that thread about python3 i think we should reject your merge <https://code.edge.launchpad.net/~lifeless/bzr/py3/+merge/28237>07:36
vilaI've fixed so many different possible hangs that I can't even guess which one you're encountering :)07:36
poolieon the grounds that getting to a single codebase from 2.4 through to 3.1 probably won't work07:37
poolieis that ok with you?07:37
lifelesspoolie: 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
lifelessI disagree about 'probably' and 'won't'07:37
poolieyou think we certainly can get a single tree that works on 2.4 and 3.1?07:38
lifeless'would be fugly'07:38
lifelesspoolie: I'm quite certain its doable, I'm not certain its desirable.07:38
poolie'single non-gross codebase'07:38
vilapoolie: :)07:38
poolieso i wasn't exactly proposing wait and see07:38
pooliebut rather, get 'python -3' clean, and then try using 2to307:39
lifelesspoolie: 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
poolieas a though experiment07:39
pooliethere is no syntax for octal ints that works on both07:39
lifelesspoolie: yes, thats the wait and see approach I referenced, and because of that I'm happy to reject that patch.07:39
pooliewe can either rewrite them all to decimal07:39
poolieor, we can keep them in 0666 syntax and use 2to3 with only the octal syntax rewriter turned on07:39
lifelesspoolie: we need 2 octal ints I think; consolidate to osutils.USER_RWX and USER_RX, or something.07:40
poolieobviously this is a pretty tiny example07:40
pooliebut my point is that the second seems at least possibly as good07:40
lifelesspoolie: or even use the constants in the os module, or wherever they are07:40
poolieit's just an example07:40
lifelesspoolie: right07:40
lifelesspoolie: we lack data07:40
lifelesspoolie: all concerns aside, we have a plan to get more data. So lets do that.07:41
lifelesspoolie: We have different opinions about what the data is likely to tell us.07:41
lifelesspoolie: which is fine :)07:41
spivint('666', 8) works in both 2.4 and 3.107:45
lifelessspiv: \o/07:45
spivI wouldn't want to put that in an inner loop :)07:46
lifelessbut when we're that much into tuning we get into function params etc anyhow07:46
lifelessso we could do it there07:46
vilabut perfectly fine as osutils.o66607:46
pooliesheesh _example_07:47
lifelessthough I'd name it better07:47
vila_bike shedding_ !07:47
poolieperhaps 'except Foo as e' is a better example07:47
lifelesspoolie: we're a fun company of non pedantic individuals07:47
poolieit's a purely mechanical transform07:47
lifelessI suspect you could write a07:48
lifelessexcept:\ncatch(Foo, 'e')07:48
lifelessthat would work on all python versions.07:48
lifelessand make folk cry if they ever read its internals.07:48
lifeless(not suggesting it!)07:48
pooliemight be a bit messy if you needed multiple catch branches07:49
vilaso 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.x07:49
lifelessvila: I think that this is too early to talk about07:49
lifelesswe don't know if 2to3 will work well yet; we're going to gather data07:49
vilasure, my bet is that we'll end up carrying our own 2to3 if only to take our idiosyncrasies into account07:50
vilabut I'll shut up now ;)07:50
lifelessvila: 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
vilajust wanted to mention I've done my share of automated conversions from os1 to os2, langugae1 to language2, db1 to db2, and so on07:51
vilayup, the workload is always split across: fix the translator, fix the input07:53
vilawe have a big advantage here with our test suite...07:53
vilamake that BIG07:53
lifelesspoolie: oslocks07:58
lifelesspoolie: and dirstate07:58
vilaob: must die07:58
lifelessI'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_changes07:59
lifelessthat 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
mgzmorning all07:59
lifelesspoolie: 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
lifelessvila: well yes, but its more nuanced than that ;)08:00
lifelessit has a cost, we need to know what we're buying :)08:01
pooliei think i agree with that08:06
poolienot sure what you mean by "at most" though08:06
poolielifeless, vila, https://code.edge.launchpad.net/~mbp/bzr/deprecation/+merge/27582 is updated per your comments about using overrideAttr08:13
lifelesspoolie: 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 requirements08:15
pooliei don't think just splitting it out would be worth a format bump08:15
pooliei'm sending the hpss flush patch to pqm08:18
lifelessI'm 'waiting for bugs.edge.launchpad.net'08:21
lifelessoh, foo, parthm is gone again08:30
lifelesspoolie: rereviewed08:34
lifelessspiv: ping08:35
lifelessspiv: I know its EOD, but hpss effort tests + foreign formats, could use some airtime08:36
vilapoolie: approved, oh lifeless reviewed it too08:37
vilaso, yeah, see https://bugs.edge.launchpad.net/bzr/+bug/597791/comments/108:38
ubot5Launchpad bug 597791 in Bazaar "test_http load_tests is overly complex and hard to understand (affected: 1, heat: 6)" [Wishlist,Confirmed]08:38
vilathe tests pass, I've just checked, TestActivityMixin.setUp() calls TestCase.setUp() so the code is right but ugly08:39
lifelesslosa ping; what version of testtools is installed in the balleny bzr pqm chroot please08:39
lifelessI want to know what features are available :)08:40
mthaddonlifeless: 0.9.2-1~0.CAT.8.0408:40
lifelessthanks heaps08:40
vilapoolie: 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 mine08:41
spivlifeless: like the loom issue?08:41
lifelessprecisely and08:41
lifelessI can solve that one easily08:41
lifelessits rather specific08:41
lifelessjust convert to a matcher and provide an Or test in there08:41
spivPerhaps related, it would be good to start thinking about extending the smart protocol in the loom plugin08:42
lifelessspiv: I have been :)08:42
spive.g. maybe add a verb for set_loom_state?08:42
spivOh, great! :)08:42
lifelessspiv: ignoring questions about what level to operate at, it raises questions about how to add the client side08:42
lifelessthe server is nicely extensible08:42
lifelessthe client side proxy rather less so08:42
lifelessand I'm thinking perhaps the _real_format could add methods08:43
lifelessmake RemoteBranch more of a composite08:43
lifelessanyhow, neither of those things would make the test better, because plugins will want to call different verbs08:43
lifelessand we trace verbs08:43
lifelessspiv: for loom it happens to be easy, but what about e.g. bzr-svn08:44
lifelessspiv: if you have an svn repo08:44
lifelessand access it via bzr push bzr+ssh://host/svn/repo/branch08:45
spivYes, what indeed.08:45
lifelessI don't have answers08:45
spivI suppose one answer would be to allow the plugin to set its own call-count requirements.08:45
lifelessthe test isn't structured quite that way, but we could rephrase it.08:45
lifelessAnother would be to say that this test is format specific08:45
lifelessbut that adds a burden if/when we rev formats08:46
spivOr 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
lifelessyeah that too08:47
spivYou could have extreme corner cases with e.g. inter-branch tests from one plugin format to another plugin's format.08:47
spivI 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
lifelessI'm inclined to lowbrow it right now08:48
lifelessand hard code in 'get is ok'08:48
lifeless[a single get]08:48
spivThat'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
lifelessspiv: what do you think:09:02
vila...or merge loom into bzr-core09:02
lifelessvila: that wouldn't help09:02
lifelessvila: because the loom format would still behave differently.09:03
spivlifeless: looking now09:04
spivlifeless: I worry about the risk that the core could regress with that patch09:05
vilalifeless: 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 goal09:05
spivother than that, it looks reasonable.09:06
vilaI think it's one more case where we want the parametrization to be more pluggable for plugins09:06
lifelessvila: I really don't see it being easier09:07
lifelessvila: different maybe.09:07
lifelessspiv: anything I can do to mitigate your concern ?09:07
lifelessspiv: scratch that. Anything *you want me to do to get +1* on the patch :P09:07
vilacore mentioning loom (an external plugin) is wrong, if it was in core it would be right09:08
spivlifeless: perhaps some sort of "if purely_core_scenaro" guard?  Not sure.09:08
spivlifeless: 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
lifelessits very low.09:09
lifelessvila: if it was in core, in a per_interbranch parameterised test, its still wrong.09:10
lifelessvila: abstraction leak; we're being pragmatic about time and goals here is all :P09:10
lifelessspiv: concretely09:11
lifelessspiv: the test claims that it tests for get_parent_map missing09:11
lifelessspiv: so its overly sensitive in using an exact list09:11
vilathe test is about: "he client has no reason to query the remote graph any further" does loom cares here ?09:11
vilahehe, we agree :)09:11
lifelessspiv: this test change does not open the door for get_parent_map09:11
lifelessvila: loom in general - yes. In specific , no.09:12
lifelessin general yes because it does push-per-thread09:12
vilayup, may be the test is too high-level09:12
=== oubiwann is now known as oubiwann-away
=== oubiwann-away is now known as oubiwann
lifelessspiv: I'm going to propose it as a merge; vila may +1 it :>09:26
vilalifeless: as long as it includes a comment explaining the constraints here, sure ;-)09:27
lifelessvila: well, its the patch I put up.09:30
lifelessvila: you wanted a passing test suite; its up to you :)09:31
vilawhich patch ? The one you pasted ?09:32
vilaweird, it didn't appear in the active review page until you mentioned it here :)09:35
vilalifeless: approved, please land09:35
lifelessvila: can you toggle the merge bit too in future, please09:36
vilaAm I the only one who keep forgetting that merge bit ?09:39
lifelessI want a cron job09:39
lifelessthat assesses the votes and sets it09:39
vilaha cool09:40
vilaoh, and thanks for that fix, I will get rid of my workaround as soon as it lands09:40
lifelesspoolie: another thing I find annoying about gmail - the use of first names only09:58
lifelessI know many Martins, and many Johns.09:58
lifelessvila: btw09:58
lifelessvila: threads in paramiko: teach paramiko to accept a thread factory replacement parameter.09:59
vilalifeless: 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
vilabut overall since the paramiko daemonic threads appear to die naturally I punted :->10:03
lifelessvila: for sftp it makes its own ones, I think10:03
vilait makes its own ones as soon as it needs a wrapper for ssh10:04
vilaat least they are the only ones I left10:04
vilaand 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 dependency10:06
vilahuge effort, small reward :-/10:06
lifelessvila: timeouts are fairly good for defensive programming10:36
lifelessvila: I wouldn't want to get rid of them10:36
lifelessmgz: you'll be glad to know we broke subunit trunk with our patch10:50
lifelessmgz: 58 errors :)10:50
lifelessmgz: some of which are testtools bugs10:52
jmlhow do I stop getting bzr bug mail10:54
lifelessI think you have two choices10:54
lifelessyou can either leave the relevant control team10:54
lifelessor you may be able to individually explicitly subscribe to all the bugs in the same place the team is subscribed10:54
lifelesswith a subscription of 'I'm not subscribed'10:55
lifelessits the same conflation of 'power/access/interest' pattern we have in LP10:55
lifelessjml: oh, and I'm sorry if I tripped your 'zomg' threshold with bug spam today.10:55
jmllifeless, not at all. it's been bugging me for a while.10:56
jmllifeless, I like bzr a lot, but I never ever read the bug or MP mail any more10:56
gustavonareaHello. 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
lifelessgustavonarea: can't you just install bzr-hg ?10:56
gustavonarealifeless: it hangs the computer and then gets killed by the OS10:58
lifelessoh, thats a little undesirable10:58
gustavonareaAnd that happens on a high spec server; I wouldn't try it on my laptop10:59
gustavonareaany idea how to do it with fast-import/export?11:00
lifelessnot personally sorry; maybe the bzr list, or the bugtracker, will know more.11:00
gustavonareathanks lifeless! I'll stay around just in case :)11:02
lifelessmgz: I've pushed a one-character fix; so small I'm not even going to ask jml for a review.11:03
jmllifeless, don't you care about quality?!?!!!!1!!??!?11:05
lifelessjml: no, not at all.11:05
lifelessmgz: jml: anyhow, trunk of both play nice together once more.11:07
vilalifeless: 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
lifelessvila: agreed11:10
vilalifeless: 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
vilas/threads/merge proposal/11:15
lifelessvila: you appear to have done the following:11:16
lifeless - rearranged some code11:16
lifeless - added a new, strange, public method which users would not expect to have to call11:17
lifelessI am neutral on the first and against the second11:17
lifelessvila: I don't understand why the second is needed11:17
lifelessif I understood why, I would stop being against it :)11:17
lifelessI would like to see internal behaviours kept internal11:18
vilabecause I want to reuse most of the code there but *not* creating the server socket as part of building the object11:18
lifelessI may have it wrong; it may still be internal and the diff is confusing me11:18
lifelessvila: I don't mind if the creation is separate to building the object, thats orthogonal to my concerns11:18
vilawell, the actual code does too much in __init__ for my needs so the socket creation has to be done outside of it11:19
vilaI can create a base class to address that but that sounded too bug a hammer11:19
lifelessI repeat, I'm fine with the separate method.11:19
lifelessI'm not fine with who has to call it11:20
vilanow, I don't think users *have* to call it as it's now called by the smart server factory,11:20
lifelessif it was called start() I would be fine11:20
vilaha, ok, so public and a better name ?11:20
lifelessvila: the smart server factory is a user of the class the method is on11:20
lifelessthe connection between the two should be clear, or the factory shouldn't exist.11:20
lifelessby which I mean, if we have two components, we should have *two* components, not one-and-a-half11:21
vilahmm, there is already start_background_thread/stop_background_thread but no start/stop >-/11:22
lifelesswhy isn't it part of one of those methods, for instance?11:23
vilacause I'm lazy ? :)11:23
lifelessI'm lazy too11:24
lifelessI think I'd have tried to find a way where i didn't change callers.11:24
vilakidding, because I was unclear about how this class was used and wanted to just pick the good bits11:24
vilamy 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 patch11:25
vilanot a good reason to make it worse though11:25
lifelessI fully agree with that11:26
vilahmm, 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 think11:27
vilahmm, and start_background_thread/stop_background_thread is, in fact, used by TestSmartTCPServer for a single test and overlap with TestingTCPServerInAThread too >-/11:30
gustavonareaHow 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 anything12:10
lifelessbzr-bookmarks plugin12:10
lifelessI think12:10
gustavonareaI'd like to something like "bzr branch foo:trunk" where "foo:trunk" gets translated to "bzr+ssh://example.org/path/to/trunk"12:11
gustavonareaah ok, thanks lifeless12:11
maxbgustavonarea: 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 own12:12
gustavonareacool, thanks maxb12:13
gustavonareamaxb: any pointers on how to write a plugin like that?12:15
vilathe bookmarks plugin :)12:15
gustavonareaok, thanks vile12:16
gustavonarea* vila12:16
maxbOr the built in launchpad plugin12:16
vilayup, as maxb said, but the lp plugin do more than that so may be harder to grasp12:16
maxbThe bzr feature that you need to interact with is called directories12:17
gustavonareathanks maxb!12:30
=== khmarbaise_ is now known as khmarbaise
=== verterok_ is now known as verterok
rbriggsatuiowawhen 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
fullermdI normally go by a gut feeling of "are there going to be non-trivial conflicts to resolve?"16:28
fullermdIf it'll land easy, JFDI.  If not, do the merge in the branch and deal with the fallout, then land it.16:29
fullermdAnd then kick yourself for not pre-emptively merging trunk into feature on a regular ongoing basis in the first place   :p16:29
rbriggsatuiowafullermd: cool - thanks (or yell at the people working on the feature for not pulling in :)16:29
rubbsfullermd: 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
lifelessgood morning19:26
mgz<lifeless> mgz: you'll be glad to know we broke subunit trunk with our patch19:39
lifelessmgz: for starters pull testtools trunk19:40
lifelessand diff -c -119:40
mgzsubunit hits a path not in the testtools testsuite at all?19:40
lifelessthen slap self on forehead (I did this) and mutter 'coverage dagnammit'19:40
mgzright, done that19:40
mgzbut for dammit-ness19:40
mgz-    return ''.join(chars)19:40
mgz+    return u''.join(chars)19:40
lifelessas I said, 1-character fix.19:40
mgzPython 3 SyntaxError19:40
mgzneed a _ and a ( and a )19:41
lifeless4 character fix coming up19:41
lifelessI'll uncommit that one19:41
mgzI'm a little perpelexed that this isn't tested but testtools itself though19:41
lifelessI was tirrrred last night19:41
lifelessso am I19:41
lifelessit has done a sneaky I think19:42
mgzI take it the issue is with details objects with no textual components19:42
lifelessTestResult isn't getting exercise19:42
mgzwhich then means we get a str object on Python 2, which we're now throwing a TypeError over19:42
lifelessmgz: thats probably it19:42
lifelessyes to the str object19:42
lifelessprobably to the proximate cause19:43
lifelesssubunit had a bunch of literals I 'u'ified19:43
lifelessas its not py3 ready anyway its no great loss19:43
lifelessneed to migrate them to _u()19:43
lifelessor py2to3, though like bzr, subunit supports much older pythons19:43
mgzalternative spelling, str().join19:46
lifelessmgz: for what?19:47
lifelesshow does that work on 2.x?19:47
jamlifeless: you mentioned the idea of "refreshing the pack index" to try and get things to behave correctly. Is that Repository._refresh_data() ?21:12
lifelessjam: sounds like21:12
* lifeless noses around21:12
jamlifeless: k, that doesn't work :)21:12
lifelessoh! thats very interesting.21:13
lifelessand yes, thats what it is21:13
lifelessthe base class docstring says it all.21:13
jamI'll also note that I got weird behavior wrt stacking fetch based on ordering21:14
jamif I created the stacked repo before I populated the base21:14
jamthen the base revision would always get fetched21:14
jamI think spiv mentioned something like that21:14
lifelessspiv just fixed a bug there21:15
jam(now there, _refresh_data *might* do something, though)21:15
lifelesspull his patch21:15
jamwell, I'm working in 2.0, and I can workaround it in the test by create_base() fetch_base(), create_stacked()21:15
lifelesshe says his patch is a candidate for 2.x+21:15
lifelessand I agree21:15
jamsame here21:16
jambut it was just an observation, not something blocking me21:16
jelmerlifeless: do you know what the time planning is for 2.2 ?21:32
lifelessit should happen21:33
jamlifeless: repo.bzrdir.open_repository() doesn't set fallback repositories?21:33
lifelessjam: thats right21:34
jamlifeless: Bazaar/Calendar/2010 says b4 on July1st, and 2.2.0 on July 29th21:34
lifelessjam: branches define the fallbacks21:34
jamlifeless: that seems to be why one succeeds and one fails21:34
lifelesspolicy in branch, implementation in repo21:34
lifelessjam: ah!21:34
jamRepoReconciler calls repo.all_revision_ids()21:34
jamand gets different results when a repo is stacked21:34
lifelessyeah, reconcile is meant to work with a no-fallbacks repo21:34
lifelessyou might like to add an assertion-like-check to the reconciler objects21:35
jamlifeless: there isn't a "remove_fallback_repo" command, is there?21:35
lifelessthey'll misbehave terribly otherwise21:35
lifelessjam: not offhand; it would need to flush all cached graph objects and so on that had been opened from it21:36
lifelessjam: so it would be pretty awfully complex21:36
lifeless / prone to misused21:36
jamso Reconciler does take a bzrdir and directly opens the repo21:37
jambut repo.reconcile() just uses self21:37
lifelessjam: https://code.edge.launchpad.net/~jameinel/bzr/2.0.5-switch-unicode-317778/+merge/1912121:38
lifelessis that abandonware :) ?21:38
jamlifeless: well, not *my* code at least21:39
jammostly proposing the patch that was in the bug21:39
jelmerjam, 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
jamjelmer: I'm pretty sure we decided to API freeze for 2.2b421:40
jamto give plugins time to stabilize21:40
lifelessjelmer: no last minute stuff21:40
lifelessjelmer: you have layer inversions still, last Isaw21:40
lifelessjelmer: I really think we should say colocated is still unsupported, and work on it in 2.321:40
lifelessmake it as clean as possible, its going to be the underpinnings for apis for years21:41
jamlifeless: so for the mp, I would reject the code as-is, and I don't think philyoon is going to work on it21:42
jamIt sort of depends how high we want to prioritize it for us21:42
jam*I* don't need it21:42
lifelessI'm reviewing bugs-with-patches21:42
jambialix and others may21:42
lifelessfound quite a few closed21:42
jamlifeless: ValueError reasonable for "_fallback_repository is not empty" ?21:47
jamor just a generic BzrError?21:47
lifelesseither is fine for me21:47
lifelesswe expect API users only to encounter it.21:47
jamlifeless: so Pack format repos fail reconcile because the target pack already exists.21:54
=== oubiwann is now known as oubiwann-away
jamdo you think it is reasonable to catch FileExists in _reconcile_pack21:54
jamor should I catch and skip in the test.21:54
lifelessmy dream21:54
=== oubiwann-away is now known as oubiann
jamToday it is a bit annoying that 'bzr reconcile' fails on pristine repos.21:54
lifelessimplement catch, byte-compare21:55
jamI know we'd like to have the consistency check21:55
jambut that is a bit out-of-scope21:55
lifelessoffhand I think catching it in reconcile is ok21:55
lifelessafter all reconcile isn't adding data to the repo21:55
lifelessits like pack()21:55
jamlifeless: the alternative is to have NewPack.finish() do something special to indicate it shouldn't be used after all21:56
jamwe've already done "self._use_pack(new_pack)" which checked to see if data was inserted21:56
jamuntil we call finish_content() we don't know the final name of the pack file, to know if it will collide21:58
jamlifeless: and that is called from NewPack.finish()21:58
lifelessI'm ok with catching it; no real opinion :_21:59
jamthe only other problem is that we can get a collision on disk and the file *isn't* in pack-names22:00
jam(if someone ^C's during autopack, and then runs it again, I think)22:00
jamnote also that this doesn't really affect Linux users, since transport.rename() will overwrite the existing file (I believe)22:00
jamit affects sftp, though22:01
lifelessdid you see the question on lp about a case of that?22:01
jamhttps://code.launchpad.net/~geoff.bache/bzr/trunk/+merge/28463 has a serious issue about NEWS22:02
jamlifeless: I saw a question about a file being in pack-names but having been renamed to obsolete_packs, which is a different thing22:02
lifelessjam: thats the one I was thinking of22:02
lifelessI was wondering how we could gather more data on that22:03
lifelessin an acceptably safe manner22:03
lifelessthere is also some redundancy with other work in that patch22:04
jelmerlifeless: for when is 2.3 planned?22:12
jamjelmer: approx 6months from the release of 2.222:12
jelmerjam: ah, thanks22:12
jamby the 'standard' calendar22:12
=== oubiann is now known as oubiwann
=== oubiwann is now known as oubiann
spivjam, lifeless: thinking of SFTP rename, I see that OpenSSH has an extension to the SFTP protocol for a POSIX rename.23:32
jamspiv: is that sort of like having sftp v7 implemented?23:32
spivIt's described in http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/PROTOCOL?rev=HEAD23:32
lifelessI'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/whatever23:41
lifeless - use that around everything that replaces single files23:41
lifelessbecause 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!