| blizzkid | no I'll just have to find out how to push it to lp | 00:00 |
|---|---|---|
| blizzkid | s/no/now | 00:01 |
| poolie | blizzkid: see http://help.launchpad.net/ | 00:05 |
| poolie | lifeless: thanks for fixing the selftest tests, they annoy me every time i see them | 00:11 |
| poolie | for some reason tests that just check a parameter is passed through a layer annoy me though | 00:12 |
| blizzkid | hmmz.... why do my branches have /+junk in it? | 00:12 |
| poolie | i guess partly they often require a big hammer (monkeypatching) to write but they don't test very strongly | 00:12 |
| poolie | blizzkid: if they're not associated with a project they're called junk | 00:12 |
| poolie | maybe you want to register a project? | 00:12 |
| blizzkid | poolie: not exactly... let me explain: I made a change to a gwibber branch | 00:13 |
| blizzkid | but I can't upload to that branch | 00:13 |
| poolie | is it your branch? | 00:16 |
| blizzkid | no | 00:17 |
| poolie | so you want to fix a bug or something and give that back to them? | 00:17 |
| blizzkid | right | 00:18 |
| poolie | i see you're already in the gwibber team? | 00:18 |
| poolie | what's the branch about? what name do you want to push it to? | 00:18 |
| === kfogel is now known as johnlodder | ||
| blizzkid | poolie: in short I'd like ~blizzkid/gwibber/cwibber instead of ~blizzkid/+junk/gwibber/cwibber | 00:20 |
| poolie | ok and what happens if you try to push to the first of them? | 00:20 |
| poolie | igc, what are we going to do about bug 415508? | 00:21 |
| ubottu | Launchpad bug 415508 in bzr "Content filtering breaks commit w/ merge parents" [Critical,Triaged] https://launchpad.net/bugs/415508 | 00:21 |
| blizzkid | poolie: testing atm | 00:22 |
| igc | poolie: I think we're going to deprecate the code path using path_content_summary() | 00:22 |
| igc | poolie: iiuic, it's not broken in 2a, "just" 1.14 | 00:22 |
| lifeless | poolie: so, testing that a layer does whats meant to is never pointless IMO | 00:23 |
| igc | poolie: so maybe it's high and not critical? | 00:23 |
| lifeless | path_content_summary is broken in 2a as welel | 00:23 |
| lifeless | *well* | 00:23 |
| lifeless | if you e.g. do 'bzr commit --excludes' (or at the moment 'bzr commit foo') | 00:23 |
| blizzkid | poolie: it worked | 00:24 |
| poolie | yay | 00:24 |
| poolie | lifeless: if you do that then what? | 00:25 |
| poolie | (impatient) | 00:28 |
| poolie | blizzkid: all good now? | 00:28 |
| blizzkid | poolie: yeah, now let's hope they accept the merge proposal :) | 00:30 |
| lifeless | poolie: then the corruption occurs because the non iter_changes commit code path is executed | 00:30 |
| poolie | ok so if we set up content filtering, in 2a, then used commit --excludes there would be corruption | 00:31 |
| poolie | of what type? | 00:31 |
| poolie | btw our bug-handling doc says we don't use status Triaged, only Confirmed | 00:31 |
| lifeless | poolie: of the sort in that bug | 00:32 |
| lifeless | poolie: john's done all the digging | 00:32 |
| lifeless | poolie: (why are you impatient, its a fine monday morning) | 00:32 |
| poolie | it's a lovely day | 00:32 |
| poolie | i just want to get a 2.0 out | 00:32 |
| poolie | it's constructive impatience :) | 00:32 |
| poolie | so i'm just asking because it looks like it's not actually corruption, just that we redundantly store a new text | 00:33 |
| poolie | which would be bad, admittedly | 00:33 |
| poolie | if we store all the texts on every commit it would be awful | 00:33 |
| lifeless | it also means that log <FILE> does very much the wrong thing | 00:34 |
| lifeless | and the merge graph, when merges are involved, goes haywire without converging | 00:34 |
| poolie | ok | 00:34 |
| lifeless | if we can get a small fix I'm incliined to say say we should backport it to the karmic version and get it out there. | 00:35 |
| lifeless | its _bad_ | 00:35 |
| lifeless | its not eat your history and spit it out | 00:38 |
| lifeless | but if you recall the bug we discovered it via, its a tremendous performance hit | 00:38 |
| poolie | i do | 00:38 |
| poolie | just trying to understand it | 00:39 |
| poolie | i might start on this today | 00:39 |
| poolie | and would you agree with ian's thing to "deprecate the code path using path_content_summary()" | 00:40 |
| lifeless | that requires adding exclude support to iter_changes (via internals or decoration) and checking it creates consistent deltas. | 00:41 |
| poolie | which sounds a bit large | 00:41 |
| lifeless | I think changing the record_entry code path to stop using path_content_summary, and delete the path_content_summary method is fine. | 00:41 |
| poolie | i thought that's what ian was suggesting | 00:42 |
| lifeless | alternatively, have path_content_summary work when there are filters | 00:42 |
| poolie | did you just set that bug to triaged, or is this launchpad being weird? | 00:42 |
| lifeless | poolie: well, the code path that /uses it/ can't be deprecated without the exclude changes I mention above. But you can /change the code path to not use path_content_summary'. | 00:43 |
| poolie | right, and deprecate path_content_summary | 00:43 |
| poolie | at least weakly | 00:43 |
| poolie | ok, i'll pull on that string | 00:43 |
| lifeless | I'm against deprecating the method. If its irredeemably broken, delete it. | 00:43 |
| poolie | i love the ajax bug stuff but it does seem to trip over itself a lot :/ | 00:43 |
| lifeless | if its not so broken, fix it. | 00:43 |
| igc | +1 from me wrt deleting the method instead of deprecating it | 00:44 |
| lifeless | deprecation is good for non-ideal things, or things we've improved. its a poor way to indicate 'bad things are happening' | 00:44 |
| poolie | mm | 00:45 |
| poolie | as i see it, it's a way to give plugin or similar authors a clue that 'no you're not going crazy, we changed this' and to possibly give users something that still works until the plugin is updated | 00:45 |
| poolie | it's good at the first, only mediocre at the second because those users don't actually want to see the technical mesasges | 00:46 |
| lifeless | sure; but this doesn't meet the contract it claims too | 00:46 |
| lifeless | s/to/ | 00:46 |
| poolie | so wrt the first one, we could say it's better to raise an error if you still try to call it | 00:46 |
| lifeless | sure. Or put it in NEWS. | 00:47 |
| poolie | yeah, there is that | 00:47 |
| poolie | igc, iirc you were going to check if any plugins care about it | 00:47 |
| lifeless | poolie: I wasn't touching that bug | 00:47 |
| poolie | ok | 00:48 |
| lifeless | poolie: re confirmed/triaged; LP changed its meaning around when it added triaged. I think we should ignore confirmed and just use triaged everywhere that we've set an importance. | 00:48 |
| poolie | something strange happened between the various status controls i think | 00:49 |
| lifeless | because thats what lp's workflow and reports want. | 00:49 |
| poolie | like what? | 00:49 |
| lifeless | like 'what bugs has a core dev not seen' | 00:49 |
| poolie | what i mean is, where does lp make a distinction between them? | 00:49 |
| lifeless | I don't recall offhand | 00:50 |
| lifeless | I've encountered glitchy things | 00:50 |
| poolie | mm, they may have | 00:52 |
| poolie | this thing i just saw might have been such a glitch | 00:52 |
| igc | poolie: quick grep over my plugins.popular directory (used to build the plugins guide) shows ... | 00:52 |
| igc | poolie: svn/commit.py, git/commit.py, cvsps_import/importer.py | 00:53 |
| lifeless | poolie: anyhow, unless you have a reason /not/ to use triaged, we should be using it. | 00:53 |
| poolie | i think 'triaged' is kind of a stupid name that means the same as 'has an importance' | 00:53 |
| poolie | but that's not a very strong reason :) | 00:53 |
| lifeless | poolie: I agree. Thats a different discussion though. | 00:53 |
| poolie | i just don't want more labels than there are logical states | 00:53 |
| lifeless | [as in, its a discussion with #lauchpad-dev] | 00:53 |
| poolie | yeah | 00:53 |
| igc | make that cvsps_import/cvsps/importer.py | 00:53 |
| poolie | i don't think we distinguish between two confirmed-type states, but the bugs are spread across them | 00:53 |
| poolie | igc, well there are 77 uses just in the tree so that's enough to get on with | 00:54 |
| poolie | so what would be a good overall test for this? | 00:54 |
| igc | Triaged just means "I'll look at this and assigned an importance" to me | 00:54 |
| poolie | at the blackbox level i could set up a tree with filtering, commit, and then see if the per-file graph changed | 00:54 |
| lifeless | igc: *looked* ? | 00:54 |
| poolie | or not quite blackbox | 00:54 |
| lifeless | poolie: what particular thing do you want to test | 00:55 |
| igc | lifeless: yes, sorry - Monday morning typo | 00:55 |
| poolie | that this bug is fixed :-) | 00:55 |
| poolie | i'm trying to work out what that means | 00:55 |
| lifeless | poolie: I wouldn't write such a test; the bug is a lack of test coverage in filtering trees. | 00:55 |
| lifeless | filtering trees in per_workingtree should be testing all the stock tests with filters, that would have caught this. | 00:56 |
| poolie | caught it how? | 00:57 |
| lifeless | the path_content_summary bug would have been exposed | 00:58 |
| poolie | by exercising content_summary returns the summary of the canonical form? | 00:58 |
| poolie | s/exercising/checking | 00:58 |
| lifeless | so we know its not a repository bug, exercising repository code to show the bug is fixed is waste | 00:59 |
| poolie | hm | 00:59 |
| poolie | yes, though if we added canonical_content_summary and convenient_content_summary | 00:59 |
| poolie | we ought to have something that tests that commit uses the right one | 00:59 |
| poolie | well | 01:00 |
| poolie | adding the test_content_filters test would be an easy place to start | 01:01 |
| spiv | Good morning. | 01:01 |
| lifeless | poolie: we have lots of tests of commit builder | 01:02 |
| poolie | hi spiv | 01:02 |
| lifeless | poolie: but roughly yes. | 01:02 |
| poolie | ok so i might start by changing *content_something to an interface with a more explicit name | 01:03 |
| lifeless | FWIW, I think john had a patch. | 01:03 |
| lifeless | If I were working on this, I'd look at how to make sure that that stops using path_content_summary; then work towards that. | 01:04 |
| lifeless | poolie: re triaged/confirmed, can we at least not twiddle them - its just noise. I have no objection to a change when something else is being altered on the bug, but arbitrarily altering that field doesn't seem beneficial. | 01:10 |
| poolie | yes, i agree on both | 01:13 |
| poolie | i thought you were twiddling them, that's why i asked | 01:13 |
| poolie | but apparently it was lp | 01:13 |
| poolie | or something | 01:13 |
| lifeless | no, I'll set to triaged if its < than that when I am altering the bug; but I won't just change that field alone ;0 | 01:14 |
| poolie | less than that? | 01:14 |
| lifeless | triaged. If its new or incomplete or confirmed, and I'm changing other status fields | 01:15 |
| poolie | look, the doc says "don't use triaged" | 01:15 |
| poolie | so please don't | 01:15 |
| poolie | if you want to change the policy, because lp has changed or for other reasons, please do that first | 01:16 |
| poolie | having them set randomly depending on who last touched it is not helpful | 01:16 |
| spiv | igc, lifeless: if either of you feel like doing a review, there's https://code.edge.launchpad.net/~spiv/bzr/ids-only-necessary-texts/+merge/10444 :) | 01:25 |
| GungaDin | http://pastebin.ca/1541055 | 01:39 |
| GungaDin | I just got this error from Bazaar. | 01:40 |
| GungaDin | Could this be due to not having enough memory? | 01:40 |
| spiv | GungaDin: yes. (Or alternatively, due to Bazaar not being clever enough when dealing with large files) | 01:41 |
| poolie | maybe we should give a special message for memoryerror? | 01:41 |
| GungaDin | hmmmm... | 01:41 |
| GungaDin | ok | 01:41 |
| GungaDin | The problem shouldn't be large files... it's just a big repo | 01:42 |
| GungaDin | none of the files inside is that big. | 01:42 |
| spiv | poolie: not a bad idea. At least for some of the known trouble spots like that ''.join... | 01:42 |
| spiv | GungaDin: Hmm. IIRC, that error usually occurs when handling a large file version. Perhaps there used to be a very large file earlier in the history? | 01:43 |
| GungaDin | could be... | 01:44 |
| GungaDin | dunno really | 01:44 |
| AfC | So, given that you dump traces in bzr.log, couldn't you just swallow any even remotely predictable exceptions and give a human readable single line error message instead? | 01:47 |
| spiv | AfC: well, we mostly do that already :) | 01:48 |
| AfC | [me is Java programmer, knows value of thread dumps at programming & debugging time, but I also know how much they freak out innocent users who were under the mistaken impression that they have a warranty with their software :)] | 01:48 |
| poolie | yeah, we do exactly that | 01:49 |
| AfC | spiv: ... it also just came up on the mailing list | 01:49 |
| poolie | afc, the question is more precisely, | 01:49 |
| poolie | should we add MemoryError to the class of errors that are treated as environmental not a bug | 01:49 |
| AfC | poolie: ah | 01:49 |
| * AfC understands | 01:49 | |
| AfC | So, does Python's VM expand to use all available memory until the kernel OOM killer gets it? | 01:50 |
| spiv | Probably "bzr: ERROR: out of memory" is virtually always a better thing to do than a traceback, even if the MemoryError is (hypothetically) a bug in a dependency rather than bzrlib. | 01:51 |
| AfC | For reasons that defy comprehension Java's VM has to be told manually to use [lots of] available memory. Quite the pain in the ass. | 01:51 |
| poolie | afc, no, it's like java, it normally raises an exception | 01:51 |
| AfC | especially with people innocently using recursive descent parsers, etc. | 01:51 |
| AfC | poolie: right, but in Java's case if you don't manually tell it to use more than hard coded maximum 256 MB (or whatever stupid number it is) of heap, that's all it'll ask for before raising OutOfMemoryError | 01:52 |
| spiv | Well, in the case of recursion, CPython has a limit on the amount of recursion it can handle because Python function calls use C stack frames too. | 01:52 |
| spiv | But yes, CPython will happily ask the OS for as much memory as the program demands. | 01:53 |
| AfC | spiv: (yeah, I realize I was conflating stack and heap there, but the two tend to go hand in hand when tree-building) | 01:53 |
| thumper | general frustration | 02:06 |
| thumper | packaged bzr and bzrtools don't work together :( | 02:06 |
| poolie | thumper: what are you using from bzrtools? | 02:06 |
| thumper | poolie: I tried both trunk and the one from the ppa | 02:06 |
| poolie | i mean, why do you have bzrtools installed? | 02:06 |
| poolie | just for background | 02:06 |
| thumper | cbranch | 02:06 |
| poolie | ok | 02:07 |
| poolie | :/ | 02:07 |
| lifeless | so I was chatting with john yesterday | 02:07 |
| poolie | aaron insists on having them locked in sync | 02:07 |
| lifeless | he's going to package more | 02:07 |
| thumper | :( | 02:07 |
| poolie | even though in this case there were 0 changes to update to 1.18 | 02:07 |
| lifeless | to help with this | 02:07 |
| thumper | icanhazcbranchtrunk? | 02:07 |
| poolie | https://bugs.edge.launchpad.net/bzr/+bug/417922 | 02:07 |
| ubottu | Launchpad bug 417922 in bzr "treat MemoryError as a special/environmental error" [Medium,Confirmed] | 02:07 |
| lifeless | thumper: not for 2.0; something equivalent but hopefully integrated not bolted on, in 3.0 | 02:08 |
| poolie | yeah | 02:08 |
| * thumper nods | 02:08 | |
| lifeless | and by integrated I don't mean 'in core', I mean 'in UI / workflow' | 02:08 |
| thumper | using bzr.dev for bzr now | 02:08 |
| poolie | regarding john's patch http://bazaar.launchpad.net/~jameinel/bzr/1.17-content-filtering-commit/revision/4530 | 02:12 |
| poolie | it looks like it's still trusting the content_summary sha1 | 02:12 |
| poolie | i don't know if that's safe | 02:12 |
| poolie | but if we were going to take this patch, it does seem like we'd need a test of commit with content filtering | 02:13 |
| lifeless | it depends what dirstate is doing | 02:20 |
| lifeless | I suspect dirstte stores the canonical sha1 | 02:20 |
| lifeless | in which case the sha1 in a content summary is valid if its coming from a dirstate cache hit | 02:21 |
| rbriggsatuiowa_ | wt = Branch.open('/Users/rbriggs/bzr/test.bound') | 02:37 |
| rbriggsatuiowa_ | wt.update | 02:37 |
| rbriggsatuiowa_ | this is not actually updating the branch (it's a bound branch) | 02:38 |
| rbriggsatuiowa_ | what is the method that I actually want to use | 02:38 |
| lifeless | wt.update() | 02:40 |
| lifeless | but | 02:41 |
| lifeless | Branch.open returns a branch, not a tree | 02:41 |
| lifeless | you want | 02:41 |
| lifeless | wt = WorkingTree.open(...) | 02:41 |
| lifeless | wt.update() | 02:41 |
| rbriggsatuiowa_ | alright - I tried that too and it doesn't work either | 02:43 |
| lifeless | what are you expecting to happen that is not happening? | 02:44 |
| rbriggsatuiowa_ | I am expecting it to have the same result as if I ran bzr up from the command line | 02:44 |
| rbriggsatuiowa_ | the branch that wt is bound to is at version 3 - but wt keeps staying at version 2 | 02:45 |
| lifeless | thats the api that cmd_update uses | 02:48 |
| lifeless | cmd_update does more; you should look at it inside bzrlib.builtins | 02:48 |
| rbriggsatuiowa_ | cool - thanks | 02:50 |
| rbriggsatuiowa_ | btw - love this chatroom - it has always been helpful | 02:50 |
| AfC | Ok, that's weird. That rbrigg fellow managed to have his nick show up in italics in my IRC client. Hm. injection vectors. Yeay. | 03:11 |
| === davidstrauss_ is now known as davidstrauss | ||
| * igc lunch | 04:36 | |
| === abentley1 is now known as abentley | ||
| === abentley1 is now known as abentley | ||
| vila | hi all | 07:09 |
| poolie | hi vila! | 07:16 |
| lifeless | hi vila | 07:16 |
| vila | lifeless: rev4638 on trunk is weird, the message and the "code" actually committed doesn't seem to match >-/ | 07:22 |
| vila | The message says : "Improve test performance of selftest tests." but the commit is about the "Triaged" definition... | 07:23 |
| vila | lifeless: not a big deal, more a heads-up in case you missed something | 07:23 |
| lifeless | oh frell | 07:24 |
| lifeless | landed totally the wrog branch there | 07:24 |
| vila | my worst nightmare.... :D | 07:25 |
| lifeless | https://code.edge.launchpad.net/~lifeless/bzr/test-speed/+merge/10590 | 07:25 |
| lifeless | is the follow on to what I had meant to land | 07:25 |
| poolie | igc, so as far as i can make out the content_summary is meant to be about the internal form | 07:52 |
| poolie | i think we should see about a clearer distinction between those that are and those that aren't | 07:52 |
| igc | poolie: right. It's only used in bzrlib (to my knowledge) for getting what to commit | 07:53 |
| lifeless | it predates filters | 07:53 |
| poolie | sure | 07:53 |
| poolie | the question really is, what are interfaces that predate filtering meant to do | 07:53 |
| lifeless | I agree with what you're saying. | 07:54 |
| lifeless | interfaces predating are all about the canonical form, IMO | 07:54 |
| poolie | cool :) | 07:54 |
| poolie | then we all agree :) | 07:54 |
| igc | lifeless: ir predates filters landing; content filtering development started before it existed by then I got sick | 07:54 |
| igc | s/ir/it/ | 07:54 |
| igc | s/by/but/ | 07:54 |
| poolie | i mean even aside from this particular method there are going to be other things that are not filtering-aware | 07:55 |
| igc | right, because there was no convenient form | 07:55 |
| poolie | i was wondering before if perhaps we should have a separate tree object that represents the filtered form | 07:55 |
| poolie | it may be complicated to make that work properly with eg treetransforms | 07:55 |
| poolie | but it might be cleaner | 07:55 |
| poolie | hm it might be hard to make it work well with dirstate too | 07:56 |
| fullermd | Files can be different from the filtered form (and different from canonical), and still evaluate to the same canonical form... | 07:56 |
| fullermd | So at best it would probably only save you work some of the time. | 07:56 |
| igc | fullermd: right | 07:56 |
| fullermd | (of course, that may be the vast majority, so still be a win. But you'd always have to treat a miss as just a hint at any rate) | 07:57 |
| poolie | i meant easier in terms of less bugs, not faster | 07:57 |
| fullermd | I'd think the result would just be to hide them more often. | 08:01 |
| fullermd | (I guess that's "less", but probably not in a way we really want :) | 08:01 |
| poolie | why? | 08:01 |
| poolie | actually, are we even talking about the same thing? ie having a FilteredTree(filters, tree) class | 08:02 |
| fullermd | Possibly not. I never really know what I'm talking about. | 08:03 |
| poolie | :} | 08:03 |
| NEBAP|work | vila: ping | 08:15 |
| vila | pong | 08:15 |
| NEBAP|work | vila: good morning :) | 08:15 |
| vila | NEBAP|work: You too :) | 08:15 |
| NEBAP|work | vila: get the error reproduced? | 08:16 |
| vila | So, I looked at our bug and couldn't find a way to reproduce the "obj/file2' is not conflicted, only "obj.moved/file2" is not conflicted | 08:16 |
| NEBAP|work | hmmm | 08:17 |
| NEBAP|work | weird | 08:17 |
| vila | So I left it up to you to find the right sequence :) | 08:17 |
| NEBAP|work | ^^ | 08:17 |
| vila | From there, but from there only can I try to fix the problem | 08:17 |
| NEBAP|work | will play a bit with generated folder ;) | 08:17 |
| NEBAP|work | and then give you the results | 08:17 |
| vila | NEBAP|work: ok, thanks ! | 08:17 |
| vila | NEBAP|work: My best guess is that the sequence is so alien to me that I can't force myself to reproduce it, | 08:18 |
| NEBAP|work | doesn´t bazaar have a "log" where you can see the last xx commands? | 08:18 |
| vila | .bzr.log in $HOME (bzr version will tell you where) | 08:18 |
| vila | Good idea | 08:19 |
| NEBAP|work | I hope that it wasn´t my fault that caused the error.. | 08:19 |
| vila | I suspect some more non-bzr commands are involved though | 08:19 |
| NEBAP|work | so, will that help if I take the log from chris computer? | 08:19 |
| vila | NEBAP|work: Don't think about it as whose fault it was, in the end we want bzr to help you avoid such problems anyway | 08:20 |
| NEBAP|work | kk | 08:20 |
| vila | NEBAP|work: it will certainly help, if only by restricting what bzr commands we should include in the scenario | 08:20 |
| vila | there can also be a '.bzr.log.old' there too | 08:21 |
| NEBAP|work | k, I will look for those files on chris computer and then send them too, ok? | 08:21 |
| vila | if you can find the commands that have been executed in the right time frame (hopefully you can identify that :) | 08:21 |
| vila | that will help | 08:21 |
| vila | NEBAP|work: try to filter them a bit first | 08:22 |
| NEBAP|work | ok, if the commands are in the log file, I´ll find them ;) | 08:22 |
| NEBAP|work | ok | 08:22 |
| lifeless | poolie: I landed the policy change by mistake. I'll back it out tomorrow. | 08:30 |
| poolie | k | 08:30 |
| vila | lifeless: grr, I already asked you (can't remember where): where the h is boto ? | 08:31 |
| lifeless | vila: apt-get install python-boto | 08:31 |
| vila | I'm sure I tried that :-( | 08:31 |
| lifeless | may be only in karmic | 08:31 |
| lifeless | in which case | 08:31 |
| lifeless | add karmic to your sources | 08:32 |
| lifeless | then apt-build install python-boto | 08:32 |
| poolie | python2.5-boot | 08:32 |
| poolie | boto | 08:32 |
| vila | available in jaunty, may be it wasn't last time I checked... | 08:32 |
| poolie | in jaunty | 08:32 |
| vila | in universe | 08:32 |
| vila | lifeless: but did you try my patch ? The only helper class I modify is *inside* fork_for_tests... | 08:33 |
| lifeless | vila: is it? [no I hadn't; I was doing a trawl through for unreviewed things...] | 08:34 |
| NEBAP|work | vila: email is on the way, keep that one private please .. (should contain the hole session from friday) | 08:34 |
| vila | NEBAP|work: sure | 08:34 |
| vila | lifeless: I don't want to force your vote (non sense anyway) but I'd like to keep that submission simple, I *want* to limit the number of spawn process, but it requires a more extensive change (I know, I tried) | 08:35 |
| lifeless | vila: It would make me happy if you test it with ec2test. | 08:37 |
| vila | lifeless: devil :) | 08:37 |
| lifeless | I'd like to know that all the hacking you do in this space fits with ec2test, because I think its a good model for a bunch of things like - having pqm validate on windows during commit. | 08:37 |
| vila | lifeless: you know we agree on the aim, even if we disagree on the steps to get there :) | 08:38 |
| lifeless | I'm not sure we disagree on anything ;) | 08:38 |
| vila | Is that the same as: "I'm sure we agree on nothing" ? :-D | 08:39 |
| lifeless | heheh | 08:39 |
| vila | NEBAP|work: I received the file, but it looks like a lot of lines are badly truncated (as if you copied some file content in a mail...) can you resend the file itself as attachment ? | 09:09 |
| * igc dinner | 09:13 | |
| NEBAP|work | vila: sure, give me a second | 09:13 |
| Coke | Hello. I have a problem, the server admins have changed the SSH port so now my bzr branch is wrong when I try to commit files. How can I change this without losing the data I've modified? | 09:14 |
| vila | NEBAP|work: the scope sounds good though as far as I can see, the last commit/push is the one that succeeded right ? | 09:14 |
| NEBAP|work | vila: yes should be :) | 09:15 |
| vila | Coke: mention the port explicitly in the url | 09:15 |
| vila | Coke: uze 'bzr info' to check what bzr thinks your branches are, use --remember in the right command to update that | 09:16 |
| Coke | vila: ah, remember | 09:16 |
| vila | Coke: now you remember ? :-D | 09:17 |
| Coke | no, I'm trying to remember | 09:17 |
| Coke | sorry, to USE --remember | 09:17 |
| Coke | unknown command "--remember" | 09:17 |
| vila | Coke: --remember is a parameter accepted by commands like 'push', 'pull' | 09:17 |
| Raim | Coke: more like: bzr push --remember | 09:18 |
| Coke | ok. and after remember I have the new URL? | 09:18 |
| Raim | and the URL as additional parameter of course | 09:18 |
| Coke | ok. | 09:18 |
| Coke | bzr: ERROR: no such option: --remember | 09:18 |
| Raim | which bzr version do you use? | 09:18 |
| Coke | I'm trying to do a ci | 09:18 |
| vila | Coke: you use the command as usual (but mentioning a new URL) and you add --remember | 09:18 |
| Coke | 1.17 | 09:18 |
| vila | Coke: what does 'bzr info' says ? | 09:19 |
| Raim | bzr ci does not have --remember as it does not require a URL | 09:19 |
| NEBAP|work | vila: on the way | 09:19 |
| Coke | vila: about? | 09:19 |
| Coke | Raim: so how do I solve this? | 09:19 |
| vila | Coke: can you paste it somewhere ? Do you use a standalone branch or a heavyweight checkout ? | 09:20 |
| Coke | it says "checkout of branch" in info | 09:20 |
| vila | hmm | 09:20 |
| Coke | all I want to do is change the URL used when doing ci and up | 09:20 |
| Coke | it's stored somewhere in some magic file | 09:20 |
| Coke | (which the README says explicitly not to touch manually) | 09:21 |
| vila | Coke: cat .bzr/branch/branch.conf | 09:21 |
| poolie | vila: have you ever seen this: | 09:21 |
| poolie | mbp@grace% ./bzr --no-plugins selftest nested | 09:21 |
| poolie | testing: /home/mbp/bzr/bzr.1.18/bzr | 09:21 |
| poolie | /home/mbp/bzr/bzr.1.18/bzrlib (1.18 python2.6.2) | 09:21 |
| poolie | Exception RuntimeError: 'maximum recursion depth exceeded in __subclasscheck__' in <type 'exceptions.RuntimeError'> ignored | 09:21 |
| poolie | Exception RuntimeError: 'maximum recursion depth exceeded in __subclasscheck__' in <type 'exceptions.RuntimeError'> ignored | 09:21 |
| Coke | vila: should I change that manually? | 09:21 |
| poolie | 09:21 | |
| vila | poolie: yup, every day :) | 09:21 |
| poolie | really? i don't think i ever havebefore | 09:21 |
| vila | poolie: I traced it back to a test saying it was expected or something | 09:21 |
| spiv | I see it sometimes. | 09:22 |
| vila | I was about to summon you spiv :) | 09:22 |
| Coke | vila: OH! that worked nicely even though I shouldn't meddle with .bzr | 09:22 |
| spiv | It's something that only happens when .pyc files are generated, or something weird like that. | 09:22 |
| vila | Coke: huh ? Just looking at the file ? Or do you mean you edited the file ? | 09:22 |
| Coke | vila: I edited it. | 09:23 |
| vila | Coke: ok, certainly the simplest there :) | 09:23 |
| vila | There may be a way to do it from the command line, but not using heavy checkouts myself, I don't know it | 09:24 |
| Coke | How come bzr up doesn't restore deleted files? | 09:24 |
| Coke | I deleted a file in the local branch and then did bzr up to see if it would restore it, but no go | 09:25 |
| vila | Coke: a versioned file ? | 09:25 |
| vila | Coke: ho, you want 'bzr revert' | 09:25 |
| vila | bzr update will respect your local changes as much as it can | 09:26 |
| Coke | vila: ah | 09:26 |
| Coke | thanks | 09:26 |
| Coke | still getting used to the CVS -> bzr switch | 09:26 |
| vila | Coke: You're welcome | 09:27 |
| Coke | wow. bzr uploads could not possibly be any slower. :) | 09:30 |
| poolie | :/ | 09:30 |
| Coke | it's doing < 1k/s | 09:30 |
| poolie | over what protocol, and with what version? | 09:31 |
| Coke | sftp | 09:31 |
| Coke | 1.17 | 09:31 |
| poolie | to launchpad, or elsewhere? | 09:31 |
| Coke | elsewhere | 09:32 |
| Coke | for launchpad I use lp protocol | 09:32 |
| Coke | Man, does launchpad have support for showing number of checkouts and/or downloads yet? | 09:32 |
| poolie | no | 09:33 |
| poolie | would be nice | 09:33 |
| Coke | I've seen that as a requerst for ages now. | 09:34 |
| Coke | What are the launchpad devs doing? Lunch from monday to friday? | 09:34 |
| Coke | lunchpad | 09:34 |
| Coke | Does bzr work inherently with other project sites? | 09:35 |
| Coke | or, rather, can you guys recommend a project site, as bzr user? | 09:36 |
| poolie | what do you mean? | 09:36 |
| Coke | poolie: I'm looking for a place to host my free projects, launchpad is lacking too many features | 09:37 |
| Coke | I want something like sourceforge, but something that has bzr repos support | 09:38 |
| poolie | sourceforge supports bzr repos | 09:38 |
| Coke | Ohh? | 09:38 |
| poolie | i'm pretty sure | 09:38 |
| poolie | what features do you think lp needs most? | 09:38 |
| Coke | statistics on repos and files and a wiki | 09:39 |
| Coke | it can even be a linked wiki, as long as it works with the lp login | 09:39 |
| poolie | like download counts? to know if anyone cares? | 09:39 |
| Coke | poolie: indeed | 09:39 |
| vila | NEBAP|work: I'm pretty sure the problem is case related, can you check that ? (It also explains why I couldn't reproduce it since Linux is case sensitive) | 09:39 |
| poolie | it has counts for download files | 09:39 |
| vila | NEBAP|work: like 'bzr resolve "pda/<etc>"' raises 'is not conflicted' while 'bzr resolve "PDA/<etc>"' works, can you check that ? | 09:41 |
| Coke | poolie: I haven't packaged my stuff yet, so number of checkouts/branches would be cool too | 09:41 |
| Coke | poolie: the wiki (or anything that let's you put some screenshots up) would be great | 09:41 |
| Coke | poolie: I do a lot of UI things lately and in the case of UI's a picture really says more than a thousand words | 09:42 |
| vila | NEBAP|work: and thanks for the updated mail :) | 09:42 |
| NEBAP|work | vila: I´ve checked that while we had the problem, but I´ll recheck, but windows is not case sensitive even using bazaar (used it for many projects) | 09:42 |
| Coke | poolie: lp could even have a wiki with support for a bzr backend :) | 09:43 |
| vila | NEBAP|work: right, if you can confirm, we have identified the bug :) | 09:43 |
| poolie | 'cos there's a thread here | 09:44 |
| poolie | https://lists.launchpad.net/launchpad-users/msg05247.html | 09:44 |
| poolie | a wiki is very popular | 09:44 |
| Coke | poolie: it would solve all project hosting problems I've encountered with minimum effort from lp | 09:44 |
| Coke | like "can I post more screenshots?" -> do whatever you want in your project wiki | 09:45 |
| poolie | one more wish? | 09:45 |
| Coke | poolie: that's it. | 09:46 |
| Coke | poolie: checkout stats and a wiki would make lp _complete_ | 09:46 |
| Coke | I'd be able to throw away my freshmeat and sf accounts | 09:46 |
| poolie | heh | 09:47 |
| poolie | well, there are still about 5000 bugs open :) | 09:47 |
| poolie | but those two would help a lot | 09:47 |
| poolie | i'm told that now there are file download counts doing it for branches may not be that hoard | 09:47 |
| poolie | hard* | 09:47 |
| Coke | poolie: bugs are another story. so far nothing that prevents me from using lp | 09:47 |
| Coke | I think the biggest reason launchpad is moving slowly with development is the license. :) | 09:48 |
| poolie | oh? | 09:48 |
| Coke | poolie: sure. I'd help if the sources were readily available | 09:49 |
| vila | NEBAP|work: The trick is that the message is "file does not exist" or "not conflicted" depending on whether or not the file exists, but on case insensitive file system, that's wrong and that's why I couldn't reproduce it | 09:49 |
| * fullermd has to question just how many random contributions Sourceforge-the-software has ever gotten... | 09:49 | |
| poolie | then i have a treat for you | 09:49 |
| vila | NEBAP|work: looking at the code, I'm 98% sure I found the problem, can you give that 2% missing ? :-D | 09:49 |
| poolie | Coke: http://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-devel/files | 09:49 |
| NEBAP|work | vila: I will, just give me a second, can you tell me which commands I should test with the folder we created on friday? | 09:50 |
| vila | 'bzr resolve "pda/<etc>"' sould fails, 'bzr resolve "PDA/<etc>"' should succeed, | 09:51 |
| Coke | poolie: yes, that's not new though, is it? I still can't find any news on the license | 09:51 |
| vila | replace <etc> with the path leading to the conflicted file that caused problems | 09:51 |
| vila | NEBAP|work: be extra careful with the case, start with the wrong case | 09:52 |
| Coke | "gnu affero" ? | 09:52 |
| poolie | right | 09:52 |
| poolie | http://www.gnu.org/licenses/agpl.html | 09:52 |
| poolie | is that a problem? | 09:52 |
| Coke | not sure. | 09:52 |
| Coke | poolie: hm. I didn't know there was any linking donein lp at all | 09:53 |
| Coke | poolie: well, this is great news anyway | 09:54 |
| Coke | poolie: looks tidy for such a large project | 09:57 |
| Coke | poolie: are you one of the lp regular devs? | 09:59 |
| poolie | no | 09:59 |
| poolie | i just kibbitz | 09:59 |
| Coke | kibbitz? | 10:03 |
| fullermd | n'bitz n'bitz. | 10:05 |
| Coke | huh? | 10:08 |
| fullermd | Random jingle injection. Don't mind me :p | 10:11 |
| vila | fullermd: http://instantrimshot.com/ | 10:14 |
| vila | Coke: My dictionary tells me: v : make unwanted and intrusive comments [syn: kibitz] | 10:15 |
| NEBAP|work | vila: sorry, had to do some work ^^, so how can I get back the conflicts? | 10:50 |
| spiv | Ooh, this groupcompress batching fix for remote IO also improves build-tree time for Launchpad by ~5%. | 10:54 |
| spiv | I was worried the complexity might have the opposite effect, apparently not :) | 10:55 |
| Coke | vila: weird :) | 10:55 |
| vila | NEBAP|work: 'bzr conflicts' ? | 11:01 |
| vila | NEBAP|work: or restoring the backup you made friday | 11:02 |
| NEBAP|work | vila: I use the backup from friday, but it seems to be the point before the conflicts | 11:02 |
| lifeless | spiv: less IO is less IO | 11:03 |
| vila | NEBAP|work: so you should merge again, was it -r29.1.1 ? | 11:07 |
| NEBAP|work | vila: yes, should be the latest server version | 11:07 |
| NEBAP|work | vila: bzr merge server -r 29.1.1 ? | 11:08 |
| spiv | lifeless: right, that's what I was hoping. But I know better than to merely hope that a change will improve performance :) | 11:08 |
| vila | NEBAP|work: I think so | 11:08 |
| NEBAP|work | :D | 11:08 |
| spiv | lifeless: I can be hopeful and worried simultaneously ;) | 11:08 |
| vila | spiv: Yeah, I often worry about my daughters being to hopeful :-D | 11:09 |
| NEBAP|work | vila: ok, conflicts are there, also created the obj.moved folder and the xxxx.cache.BASE and xxxx.cache.OTHER files :D | 11:14 |
| NEBAP|work | vila: now what should I do to check if it´s the error you think? | 11:14 |
| vila | NEBAP|work: 'bzr resolve "pda/<etc>"' sould fails, 'bzr resolve "PDA/<etc>"' should succeed, | 11:15 |
| vila | NEBAP|work: be extra careful with the case, start with the wrong case | 11:15 |
| NEBAP|work | k | 11:16 |
| NEBAP|work | lower case (wrong) -> xxx.cache does not exist | 11:18 |
| vila | ok, try with correct case for the directory but not final part of the path | 11:18 |
| NEBAP|work | PDA/trunk/.../lower.cache (just file is wrong) -> xxx.cache does not exist | 11:19 |
| NEBAP|work | XxxxXxxx.cache (everything ok) -> file does not exist | 11:20 |
| vila | .... | 11:20 |
| NEBAP|work | because of that I renamed the file using the os functions | 11:20 |
| vila | NEBAP|work: usr bzr conflicts forst | 11:20 |
| NEBAP|work | on friday | 11:20 |
| vila | what ? | 11:21 |
| NEBAP|work | on friday I get the same error (file doesn´t exist) | 11:21 |
| NEBAP|work | because it doesn´t exist (there is just the xxx.BASE and xxx.CACHE left) I renamed on of them using normal os functions | 11:21 |
| NEBAP|work | sorry | 11:22 |
| NEBAP|work | (xxx.cache.BASE and xxx.cache.OTHER are left, no xxx.cache) | 11:22 |
| NEBAP|work | so I used "rename xxx.cache.OTHER xxx.cache" | 11:22 |
| NEBAP|work | to ensure that the file exists | 11:22 |
| vila | ok, do that first then, | 11:23 |
| vila | then retry 'bzr resolve lower', | 11:23 |
| vila | hmm, but I think 'bzr mv xxx.OTHER xxx' is mandatory here... | 11:24 |
| vila | ha, no, forget about that | 11:24 |
| NEBAP|work | maybe you can see in the logs what I´ve done (if you look on the files) | 11:24 |
| NEBAP|work | k | 11:24 |
| NEBAP|work | will rename it now | 11:24 |
| vila | NEBAP|work: you did 'bzr mv' for the one that worked and then 'bzr resolve <right case path>' | 11:26 |
| NEBAP|work | k and for the ohter bzr mv didn´t work, right? | 11:26 |
| NEBAP|work | k, renamed the file now | 11:27 |
| vila | NEBAP|work: apparently yes | 11:28 |
| NEBAP|work | lower case -> file doesn´t exist | 11:28 |
| vila | does the file exist ? | 11:28 |
| NEBAP|work | yes | 11:29 |
| NEBAP|work | file lower case -> file does not exist | 11:29 |
| NEBAP|work | but I can see bzr converts in the wrong way | 11:29 |
| vila | then you don't specify correctly or something because this message is issued after a os.path.exists(path) | 11:29 |
| NEBAP|work | the file is: Folder/folder/Folder/FileName.ext for example | 11:30 |
| NEBAP|work | the bazaar error format is like this: Folder/folder/Folder/filename.ext (he converts the folders correct, but doesn´t for the filename) | 11:30 |
| NEBAP|work | using all in the right case worked | 11:31 |
| NEBAP|work | no errors | 11:31 |
| NEBAP|work | jup worked for both files | 11:32 |
| NEBAP|work | but no "there is no conflict" | 11:32 |
| vila | NEBAP|work: so you don't reproduce the bug ? | 11:32 |
| NEBAP|work | maybe that was because of the wrong conversion of the filename | 11:32 |
| === thumper is now known as thumper-zzz | ||
| NEBAP|work | no | 11:32 |
| vila | :-/ | 11:32 |
| NEBAP|work | but let me test something more | 11:32 |
| NEBAP|work | give me a second | 11:33 |
| NEBAP|work | wird | 11:36 |
| NEBAP|work | weird | 11:36 |
| NEBAP|work | no this time it also worked with the lower case | 11:36 |
| NEBAP|work | but no way to reproduce the error .. | 11:36 |
| NEBAP|work | sorry | 11:37 |
| vila | NEBAP|work: ok, let's stop there then, I'm pretty sure there are bugs around case sensitiveness anyway, so I'll write some tests and see how to run them on some case insensitive file system | 11:38 |
| vila | NEBAP|work: Thanks for your efforts | 11:38 |
| NEBAP|work | thank you for the help ;) | 11:38 |
| === vila is now known as vila-afk | ||
| === NEBAP|work is now known as NEBAP|afk | ||
| === mrevell is now known as mrevell-luncheon | ||
| danny_ | Does anyone have a suggestions on what editor to use for developing in python. 'cause I've got some trouble understanding the code without the (static) types. | 13:30 |
| === danny_ is now known as dvheumen | ||
| jml | dvheumen, for which OS? | 13:37 |
| quicksilver | try komodo edit, perhaps | 13:37 |
| quicksilver | it ives some kind of autocompletion which might help alittle | 13:37 |
| dvheumen | quicksilver, I'll give it a try | 13:37 |
| dvheumen | I was hunting for some bug, but without any type information, it's pretty hard to even discover what kind of a thing it is that you're looking at :P | 13:38 |
| === mrevell-luncheon is now known as mrevell | ||
| quicksilver | dvheumen: agreed. python is fail :P | 13:45 |
| quicksilver | dvheumen: some people love it though :) | 13:45 |
| === NEBAP|afk is now known as NEBAP|work | ||
| dvheumen | I haven't decided yet :P I haven't done much in Python yet, but I'm kind of interested in learning. It seems like a very useful language. | 13:46 |
| dvheumen | but it's kind of difficult to do something in an existing project, since I get (almost) no context information at all | 13:47 |
| michaelforrest | is anybody working on a log plugin that does JSON output for bzr ? | 14:06 |
| dvheumen | quicksilver, it looks nice, doesn't give information for my target though :P but it looks like a nice editor ... and think I'll keep it for a while :D | 14:07 |
| beuno | james_w, hey | 14:08 |
| beuno | did you manage to upload loggerhead to karmic? | 14:08 |
| james_w | not yet | 14:08 |
| james_w | I'm not sure which bzr-svn is compatible with bzr 1.18 | 14:08 |
| james_w | I have the updated loggerhead on my hard disk though | 14:08 |
| beuno | ah, so you're upgrading a bunch of packages around bzr at the same time? | 14:09 |
| james_w | yeah, 1.18 and the needed plugins | 14:11 |
| beuno | awaesome | 14:11 |
| beuno | and awesome | 14:11 |
| james_w | it all falls apart when jelmer's not around :-) | 14:11 |
| beuno | heh, I was just thinking the exact same thing | 14:11 |
| Kamping_Kaiser | When resolving a conflict, am I /required/ to edit the .BASE .THIS and .OTHER [sic] files, or can I simply edit the file which conflicted? | 14:25 |
| Kamping_Kaiser | http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#resolving-a-conflict I'm working through this | 14:26 |
| beuno | Kamping_Kaiser, edit the conflicting file, and "bzr resolve" will take care of those files | 14:26 |
| beuno | (that's what I always do) | 14:26 |
| Kamping_Kaiser | beuno: thanks. the user-guide makes it sound like thats not an option | 14:27 |
| beuno | Kamping_Kaiser, care to email the lsit about it? | 14:27 |
| beuno | woulb be interesting to fix it | 14:27 |
| Kamping_Kaiser | beuno: does it support non-subscriber messages? if so, I'll fire off an email now | 14:28 |
| beuno | Kamping_Kaiser, it does not, but you can subscribe, and configure it so you don't get email | 14:28 |
| Kamping_Kaiser | hm. | 14:29 |
| Kamping_Kaiser | clunky :/ | 14:29 |
| fullermd | Non-subscribers get moderated. So it should get through eventually, though it may take a few days. | 14:42 |
| emmajane | beuno, good morning. :) | 14:44 |
| emmajane | Please let me konw if there's anything you need from me for the designer. | 14:45 |
| emmajane | (this is your daily harassment message ;) ) | 14:45 |
| beuno | emmajane, gooood morning | 14:45 |
| beuno | I do not, I'm waiting for him to arrive to jump in and do the changes | 14:46 |
| emmajane | beuno, ok :) | 14:46 |
| === cprov is now known as cprov-lunch | ||
| cjnodell | I was wondering if there was a "best" way to delete a branch/working tree with bzr? | 16:16 |
| james_w | "bzr remove-tree" for the latter | 16:16 |
| james_w | nothing special for the former | 16:16 |
| james_w | doing the remove-tree first will help you check there aren't uncommitted changes, "bzr missing" can help you work out if there are revisions there you forgot to push/merge whatever | 16:17 |
| cjnodell | so, if I wanted to make a one-time change to a project using bzr, I could create a new branch, make the changes commiting as needed, push or merge the changes with the original branch, run "bzr remove-tree" then delete the folder like any other. Does that sound right? | 16:21 |
| james_w | yeah | 16:22 |
| james_w | the remove-tree isn't required, but can help avoid "oops" moments | 16:22 |
| cjnodell | cool. thanks. Everything was making sense, but i found little info on removing old branches/working trees. I figured that it would be best to create a new branch for each task (bug fix/feature add) and then merge the new branch back, but I ended up with a bunch of old branches that I didnt need/use. | 16:24 |
| === deryck is now known as deryck[lunch] | ||
| igc | night | 17:08 |
| === deryck[lunch] is now known as deryck | ||
| === cprov-lunch is now known as cprov | ||
| === beuno is now known as beuno-lunch | ||
| === cody-somerville_ is now known as cody-somerville | ||
| === jfroy_ is now known as jfroy|work | ||
| === beuno-lunch is now known as beuno | ||
| lifeless | moin | 19:09 |
| === abentley1 is now known as abentley | ||
| === abentley1 is now known as abentley | ||
| === abentley1 is now known as abentley | ||
| === Pilky_ is now known as Pilky | ||
| jam | lifeless: you're up early | 20:17 |
| jam | or raiding really late :) | 20:17 |
| lifeless | up early | 20:18 |
| lifeless | gale force winds, or I miss my guess | 20:18 |
| jam | If you are around, I'd like to chat a bit about bug #402645 | 20:18 |
| lifeless | also have a virus, went to bed early... | 20:18 |
| ubottu | Launchpad bug 402645 in bzr "fetch for --2a formats seems to be fragmenting" [Critical,In progress] https://launchpad.net/bugs/402645 | 20:18 |
| lifeless | and the result is I get up 7 hours later like clockwork | 20:18 |
| lifeless | voice or IRC? | 20:18 |
| jam | IRC is fine for now | 20:18 |
| jam | So in debugging it, it seems that we are, indeed, fetching in 'groupcompress' order for stuff like inventories and file texts | 20:19 |
| jam | rather than 'unordered' | 20:19 |
| jam | conceptually it seemed nice | 20:19 |
| jam | but we *don't* auto repack on the fly | 20:19 |
| jam | so all we are getting is fragmentation, without the associated recombination in the new 'optimal' ordering | 20:19 |
| jam | (so it might be ordered better on disk now, but it is fragmented...) | 20:19 |
| jam | It probably doesn't help that we just changed the topo_sort algorithm ... :) | 20:20 |
| lifeless | so its ordered but not grouped | 20:20 |
| lifeless | is the new topo sort stable? | 20:20 |
| jam | the new topo sort is not particularly stable | 20:20 |
| lifeless | if its not, we should fix that asap | 20:20 |
| jam | it orders based on children | 20:20 |
| jam | and children is populated by walking a dict | 20:20 |
| lifeless | it will mess up pack on packed repos and things like that | 20:20 |
| lifeless | It seems to me that we _really_ need it to be stable | 20:21 |
| jam | so I could try to figure out when to repack on-the-fly, or we could just request unordered | 20:21 |
| jam | and the groupcompress sort during pack | 20:21 |
| lifeless | so | 20:22 |
| jam | lifeless: I can certainly write a groupcompress sorter that would be more stable | 20:22 |
| jam | btw, lifeless, I hope you're feeling better | 20:23 |
| lifeless | jam: doc says its a virus | 20:23 |
| lifeless | push liquids | 20:23 |
| lifeless | sleep when tired. The usual. | 20:23 |
| lifeless | if not better in a week blood test. | 20:24 |
| jam | lifeless: yeah, I had a 24-hour ish thing last week | 20:24 |
| Fagan | Hi im getting an error when I try to branch. | 20:24 |
| Fagan | Permission denied (publickey). | 20:24 |
| Fagan | bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist. | 20:24 |
| Fagan | Should I just make a new pub key? | 20:25 |
| jam | Fagan: did you do launchpad login without actually telling launchpad about your ssh key ? | 20:25 |
| lifeless | are you on windows? | 20:25 |
| Fagan | It worked about a month ago but I tried it there a minute ago and it didnt | 20:26 |
| jam | lifeless: as an aside, if we do a new gc ordering without packing on the fly... then we will opportunistically fragment everything until everyone has upgrade their versions and repacked their repositories with the new sort order | 20:26 |
| jam | Fagan: you could try checking your launchpad ssh key list and see if the keys you expect are still present | 20:26 |
| Fagan | Yep | 20:26 |
| lifeless | Fagan: if you're on windows, make sure that you can connect outside of bzr | 20:27 |
| lifeless | we use plink which just errors hard if its a new host | 20:27 |
| Fagan | Im on ubuntu | 20:27 |
| jam | lifeless: Wasn't there a special "~me" user for launchpad links? | 20:27 |
| lifeless | +me? | 20:27 |
| lifeless | jam: so a few thoughts: we want the end result to be well ordered& grouped repos. We want initial pulls to end up that way too. | 20:28 |
| jam | lifeless: launchpad.net/~me /~+me /+me all no love... :( | 20:29 |
| lifeless | jam: we don't particularly want to do massive computation on the server, OTOH full pulls should already be in near-ideal gc order anyway - and besides, if we offload it all to the client, then when the client pushes to the server the server will do all the work. | 20:29 |
| lifeless | /people/+me | 20:29 |
| lifeless | so for an ideal solution with high server scaling we need: | 20:29 |
| lifeless | client-does-the-work-on-push | 20:30 |
| jam | lifeless: well, I was hoping for "launchpad.net/+me/+sshkeys" to help out Fagan, but that doesn't seem to work | 20:30 |
| lifeless | client-does-the-work-on-pull | 20:30 |
| lifeless | jam: /people/+me/+sshkeys | 20:30 |
| jam | ah, but people/+me/+sshkeys does | 20:30 |
| jam | lifeless: you could have a hint that gets passed down when the source is RemoteRepository... | 20:31 |
| lifeless | its worse than that its dead jim | 20:31 |
| lifeless | site to site fetch [corner case] can go remote->remote | 20:31 |
| lifeless | with the 'client' in the middle | 20:31 |
| jam | as an aside, changing the ordering to 'unordered', I no longer get any "creating new compressed block on-the-fly" messages, as expected. | 20:32 |
| lifeless | so | 20:32 |
| lifeless | lets look at what that does | 20:32 |
| lifeless | we have a repo which is partially packed | 20:32 |
| lifeless | N packs. | 20:32 |
| lifeless | but we write a repo which has the same groups but 1 pack. | 20:33 |
| jam | yep | 20:33 |
| Fagan | Ah I just made a new ssh key and it worked | 20:33 |
| lifeless | I'm really inclined to say 'pull in gc-optimal order and do a 'decent' job of combining groups'. | 20:33 |
| lifeless | because otherwise the repack heuristic will never kick in on the recipient | 20:34 |
| jam | lifeless: right, the question is all about the 'decent' issue | 20:34 |
| jam | and I'm wondering if the fix *today* is to just switch back to unordered | 20:34 |
| jam | while we work out a reasonable heuristic | 20:35 |
| lifeless | but this may have really bad behaviour if for instance it ends up recompressing everything. | 20:35 |
| lifeless | and because its newest-first thats actually a plausible side effect | 20:35 |
| jam | lifeless: right, say you get the 'off-by-one' issue because there is a single new text | 20:35 |
| jam | so you try to fit 100 nodes in each group, but they all get shifted by 1 | 20:35 |
| lifeless | we should expect most repos to be mostly packed most of the time | 20:35 |
| jam | lifeless: aside from the current fragmentation issue, which causes them to be at best partially packed part of the time :) | 20:36 |
| lifeless | indeed. Bugs. | 20:36 |
| lifeless | perhaps | 20:36 |
| lifeless | gc-optimal is meant to be 'what a gc repo wants' | 20:36 |
| lifeless | One thing we could do is allow that to not fragment | 20:36 |
| jam | so here is an idea | 20:37 |
| lifeless | I'm concerned about asking for unordered because unordered can be _really_ unordered. | 20:37 |
| jam | what if we fetch in groupcompress order | 20:37 |
| Fagan | thanks guys bye | 20:37 |
| jam | and leave a compression group 'open' | 20:37 |
| lifeless | ciao Fagan | 20:37 |
| jam | such that if we want to split an existing group into a new one | 20:37 |
| jam | we put it in the 'pending' group | 20:37 |
| jam | so we leave groups alone as much as possible | 20:38 |
| lifeless | re; off-by-one. I think in that case we should just make the first group a little bigger and not touch others. | 20:38 |
| jam | but if we are doing the work of splitting, then we flag it as something that should be recombined | 20:38 |
| SamB | jam: could something like that avoid repacking repeatedly during a single fetch as well? | 20:38 |
| lifeless | SamB: no, thats a different condition entirely. | 20:38 |
| jam | SamB: repacking repeatedly only happens on cross-format-fetches | 20:38 |
| SamB | true | 20:38 |
| SamB | I guess | 20:38 |
| SamB | but the idea of a "pending" group sounds sorta like what I was thinking could be used to avoid too much of that ... | 20:39 |
| lifeless | SamB: no, it wouldn't help there. | 20:39 |
| jam | lifeless: sure, I'm just saying that a heuristic that is too simple could cause an off-by-one problem | 20:39 |
| lifeless | jam: yes, I'm acking that. | 20:39 |
| lifeless | jam: but also saying that we should ahve a goal, that adding texts to a group at fetch time, *at worst* merges them with the first group, and doesn't touch any deeper group. | 20:40 |
| lifeless | I think your pending group concept is a description about how we might implement that | 20:41 |
| jam | lifeless: so the main problem that I see is that repacking the groups is considered to be a "get_record_stream" process, while combining them would be an "insert_stream" process... | 20:42 |
| SamB | oh, also ... it seems like there is a certain size beyond which repacking is a BAD idea ... | 20:42 |
| jam | either that or the get_record_stream side would buffer... | 20:42 |
| lifeless | jam: andrew has a need for a streaming gc interface | 20:42 |
| lifeless | let me describe this briefly | 20:42 |
| lifeless | he has a lot of inventory deltass | 20:43 |
| lifeless | they will compress very well against each other | 20:43 |
| lifeless | we want to put them on the network as a series of gc groups | 20:43 |
| lifeless | so he wants to be able to do: | 20:43 |
| lifeless | def get_fulltext_stream(): make deltas and yield FullTextContentFactory(delta_text) | 20:44 |
| lifeless | network.insert_stream(gc_compress(get_fulltext_stream())) | 20:44 |
| jam | lifeless: the bzrlib.groupcompress.GroupCompressor class can do all that he needs, other than knowing when to start a new group | 20:45 |
| jam | so it would be pretty easy to have a moderately trivial logic in a helper function to do that | 20:45 |
| lifeless | yes, and in fact he may have already; it was a weekish ago that I did the design review with him | 20:45 |
| lifeless | it just seemed related to your point ;) | 20:47 |
| lifeless | so, get_record_stream repacking would be inefficient for tree building | 20:47 |
| lifeless | we'd want to only do it when serializing to the network | 20:47 |
| lifeless | insert_record_stream is a better conceptual fit. Can we reasonably confidently hook it in there | 20:48 |
| jam | lifeless: so insert_record_stream would need to be holding the pending group anyway | 20:50 |
| jam | the question is how to figure out that the block coming across the wire is unoptimal | 20:51 |
| jam | We could start with groups that have a single entry | 20:51 |
| jam | I don't know whether that is enough, but it would certainly be a start | 20:51 |
| lifeless | thats likely | 20:51 |
| lifeless | uhm | 20:51 |
| lifeless | lets start by getting a trace | 20:51 |
| lifeless | what does irs see when fetching from a fragmented 2a repo | 20:52 |
| Noldorin | hey lifeless | 20:52 |
| lifeless | hi Noldorin | 20:52 |
| lifeless | jam: that will give us data to fit an algorithm too | 20:52 |
| Noldorin | got another reply from my admin today | 20:52 |
| Noldorin | heh | 20:52 |
| lifeless | jam: as well as test data for verifying we've fixed it. | 20:52 |
| Noldorin | basically i finally got them to try it, but they are adamant there is nothing to be done | 20:52 |
| lifeless | they agree that the behaviour happens? | 20:53 |
| Noldorin | waiting for the upgrade to IIS 7/win 2008 is the solution i think :) | 20:53 |
| Noldorin | if i'm lucky, that will fixc it | 20:53 |
| jam | Noldorin: this is the "ie6 ftp server" doesn't like to actually respond to delete requests? | 20:53 |
| lifeless | jam: yes | 20:53 |
| Noldorin | but it's possibly just the fact that it's on a shared server | 20:53 |
| Noldorin | and the OS is really slow to process filesystem operations | 20:53 |
| Noldorin | jam: it does, only very slowly. | 20:53 |
| lifeless | Noldorin: do they agree that it happens? | 20:53 |
| jam | having RENAME and DELETE return before the action has completed is a bit silly anyway | 20:54 |
| jam | lifeless, vila-afk: In doing this testing, I'm seeing a lot of: "25 bytes left on the HTTP socket" in .bzr.log | 20:55 |
| jam | any idea what would be causing that? | 20:55 |
| lifeless | jam: thats odd | 20:55 |
| lifeless | I'd change the trace to print the first 50 bytes of whatever is left as well | 20:56 |
| lifeless | that will answer it quickly | 20:56 |
| === vila-afk is now known as vila | ||
| jam | It is in bzrlib.transport.http._urllib2_wrappers.Response.finish() | 20:57 |
| jam | anyway, I'll poke at it a bit | 20:57 |
| Noldorin | lifeless: well, they kind of agree. | 20:57 |
| vila | jam: still haven't found the time to look into it, but it's just a warning, it means we the http response contained more data than we can consume, which may or not indicate a more serious problem | 20:57 |
| Noldorin | not directly though | 20:57 |
| lifeless | Noldorin: they can't reproduce it? | 20:58 |
| Noldorin | took a very frank email to even get them to (what seems) like try it | 20:58 |
| lifeless | Noldorin: or they can? | 20:58 |
| vila | jam: if you poke, poke at the higher levels | 20:58 |
| Noldorin | erm | 20:58 |
| Noldorin | let me paste you the email | 20:58 |
| Noldorin | maybe you can make heads and tails of it :P | 20:58 |
| Noldorin | lifeless: http://pastebin.ca/1541941 | 20:59 |
| lifeless | ok, they acknowledge that it happens. | 21:01 |
| lifeless | RFC 959 section 4.2 | 21:01 |
| jam | vila: so interestingly, it is always 25 bytes | 21:01 |
| jam | and seems to be a content boundary: | 21:01 |
| jam | '\r\n--471e8a95308203bb4--\r\n' | 21:01 |
| lifeless | their server must send a 1xx status, not 2xx if it hasn't completed the operation. | 21:02 |
| lifeless | Its a defect. Its not RFC conformant. | 21:02 |
| jam | lifeless: of course, we might not be paying attention to 1xx... | 21:02 |
| lifeless | jam: http://launchpadlibrarian.net/30593974/trace.txt | 21:02 |
| lifeless | wireshark FTW | 21:02 |
| vila | lifeless: you're replying to jam ? | 21:03 |
| lifeless | vila: to Noldorin | 21:03 |
| jam | lifeless: yep, I see your point | 21:03 |
| lifeless | vila: bug 412244 | 21:03 |
| ubottu | Launchpad bug 412244 in bzr "unlock fails to unlock over FTP with Windows IIS6 FTP server which keeps files after delete" [Medium,Confirmed] https://launchpad.net/bugs/412244 | 21:03 |
| lifeless | vila: it will make you laugh, it will make you cry. | 21:03 |
| vila | lifeless: ha right, I read that a couple of minutes ago, the server that is able to tell us about deleted files right ? | 21:03 |
| jam | IIS6 FTP basically says "ok, that is deleted" but then you can go back and read the file at the deleted location. | 21:03 |
| jam | more importantly renaming the directory | 21:04 |
| lifeless | it also says 'ok thats renamed' and you can read from the old path | 21:04 |
| jam | leaves the file in places so a future rename to fails | 21:04 |
| jam | mv lock broken; mv new-lock lock # fails | 21:04 |
| lifeless | Noldorin: so, they acknowledge that it happens and then say to use filezilla; and that their linux platform is better. (They are right, it is :P). | 21:04 |
| vila | lifeless: your comments sounded so much like what I wanted to answer jam :) | 21:04 |
| vila | jam: so, about the boudaries, wireshark FTW :) | 21:04 |
| vila | boundaries | 21:05 |
| lifeless | Noldorin: its clearly in violation of the RFC. They can open a ticket with Microsoft. | 21:05 |
| * lifeless is sorely tempted to blog about this | 21:05 | |
| lifeless | oooh look, sunshine | 21:06 |
| lifeless | not a lot, but better than full dark | 21:07 |
| lifeless | SamB: so the reason cross format fetching has to repack is that the data is in the reverse order needed. | 21:08 |
| lifeless | SamB: 2a compresses new->old | 21:08 |
| lifeless | data conversion is old->new | 21:08 |
| Noldorin | lifeless: yeah, i agree. i somehow suspect they would just tell me to open the ticket however, no? | 21:09 |
| lifeless | [theres more complexity under the hood too, but thats the basic driver] | 21:09 |
| jam | vila: anyway, it seems that we have a trailing content boundary that is getting 'silently discarded' | 21:09 |
| jam | vila: not worth that to me :) | 21:09 |
| jam | just a curiosity at this point | 21:09 |
| lifeless | Noldorin: you don't have the windows CAL or server licence. | 21:09 |
| vila | jam: same here :D | 21:09 |
| lifeless | Noldorin: so you can't open the ticket. | 21:09 |
| lifeless | I've dealt with MS support before. They are good - you pay money [quite a bit :P] and then work through the problem. | 21:10 |
| Noldorin | lifeless: heh, good point. | 21:11 |
| lifeless | this /may/ be your ISP's deployment. Or it may be an MS bug. | 21:11 |
| jam | lifeless: what about your patch to repack the last pack file that was created. That only triggers on cross-format fetches? | 21:11 |
| lifeless | you have no visibility into the infrastructure. | 21:11 |
| SamB | lifeless: oh. | 21:11 |
| lifeless | jam: yes, only cross format, and only the new pack(s) written in that fetch. | 21:12 |
| SamB | lifeless: but does it have to repack everything into a gigantic pack? | 21:12 |
| lifeless | SamB: when we do data conversion we only repack the data that has been converted. We leave existing data alone. | 21:12 |
| jam | lifeless: right. Just thinking that repacking the new pack would also be a way to handle the 'fetch from a non-optimal source' | 21:12 |
| jam | but I think it is probably far too much data :) | 21:12 |
| lifeless | SamB: so we don't actually create a gigantic pack (unless it is the initial fetch). | 21:12 |
| lifeless | SamB: and on the initial fetch a single large pack is the best possible size and performance to have - its desirable. | 21:13 |
| SamB | lifeless: how many weeks has this been the case for? | 21:13 |
| lifeless | I'd have to check NEWS :P | 21:13 |
| lifeless | jam: Yeah, it cross my mind too while we've been chatting. The problem I think is that its too global; we don't need to be global for this problem so lets not. | 21:14 |
| lifeless | jam: dunno if you saw, but spiv has a 5% faster tree build by grouping IO | 21:17 |
| lifeless | on lp trees | 21:18 |
| jam | lifeless: I had not seen anything to that effect yet. Sounds good | 21:18 |
| SamB | where does one get a bzr-gtk that doesn't freak out about bzr >=1.18~ ? | 21:19 |
| lifeless | 19:54 < spiv> Ooh, this groupcompress batching fix for remote IO also improves build-tree time for Launchpad by ~5%. | 21:19 |
| lifeless | 19:54 < spiv> I was worried the complexity might have the opposite effect, apparently not :) | 21:19 |
| Noldorin | lifeless: ah, thanks for updating the bug report :) | 21:24 |
| Noldorin | i'll link that in my next email to the admin | 21:24 |
| lifeless | Noldorin: the hidden subtext I get from the admin is that they don't think they can fix the windows service. | 21:25 |
| Noldorin | lifeless: i got the same impression | 21:25 |
| lifeless | They are wrong though - its only software. | 21:25 |
| Noldorin | they see a deep and most likely difficult problem, and they don't want to get involved | 21:25 |
| Noldorin | mm | 21:25 |
| SamB | what do you mean by "fix the windows service"? | 21:26 |
| jam | vila: did you change something recently with "bzr selftest -s bt" ? | 21:26 |
| jam | Because: | 21:26 |
| lifeless | jam: I'm not convinced that switching to unordered is wise | 21:26 |
| jam | wbzr selftest -s bzrlib.tests.test_group runs 38 tests | 21:26 |
| jam | wbzr selftest -s bt.test_group | 21:26 |
| jam | runs 09 | 21:26 |
| jam | sorry | 21:26 |
| jam | runs 0 | 21:26 |
| jam | lifeless: I think it is the best option *today* | 21:26 |
| jam | as sorting only introduces fragmentation | 21:27 |
| jam | I'm working on something better | 21:27 |
| vila | jam: wow, no, try adding --list | 21:27 |
| jam | but I expect it to take a while | 21:27 |
| jam | vila: no test | 21:27 |
| jam | no tests from --list | 21:27 |
| jam | note that if I add a syntax error | 21:27 |
| lifeless | jam: ah, I see it. | 21:27 |
| jam | I can see that the file is getting loaded | 21:27 |
| lifeless | jam: I'll fix. una momento | 21:27 |
| jam | lifeless: something to do with your recent test speedups? | 21:27 |
| kiko | hey | 21:28 |
| vila | jam: I guess so | 21:28 |
| kiko | lifeless, jam: any news on 1.18? | 21:28 |
| jam | kiko: released waiting for installers to be built | 21:28 |
| SamB | skipping the running of the tests is NOT a valid method of speeding up the tests ;-P | 21:28 |
| jam | I build the win32 ones | 21:28 |
| jam | Not sure about Mac status, etc. | 21:28 |
| kiko | jam, awesome -- are packages in PPA or are we waiting to upload? | 21:29 |
| jam | kiko: I believe johnf does the ppa packages now | 21:29 |
| jam | and I don't see them yet | 21:29 |
| lifeless | jam: test-start-with branch pushing now | 21:30 |
| lifeless | johnf does them, and hes packaging more plugins now | 21:30 |
| kiko | okay cool | 21:30 |
| lifeless | he needs to wait for all the versioned locked plugins to have releases done before he can push any binaries | 21:31 |
| lifeless | or else apt throws a tizzy and things go south | 21:31 |
| lifeless | thats bzrtools, bzr-svn and bzr-gtk | 21:31 |
| jam | and probably qbzr :) | 21:31 |
| jam | though someone else packages those | 21:31 |
| lifeless | jam: its pushd | 21:32 |
| jam | lifeless: where? | 21:33 |
| lifeless | test-start-with | 21:33 |
| jam | lifeless: also, the *old* topo sort was not deterministic either, I thought | 21:33 |
| lifeless | lp:~lifeless/bzr/test-start-with that is | 21:33 |
| jam | since its starting point was determined to be "dict.popitem()" | 21:33 |
| lifeless | jam: well, feel free to reword :) | 21:34 |
| kiko | lifeless, ah, awesome to know. thanks! | 21:34 |
| lifeless | we need a repeatable sort for gc-compress or we'll get pack churn | 21:34 |
| jam | lifeless: yeah, I'm working on that now | 21:34 |
| lifeless | kiko: so to make the PPA more usable we're doing the following on releases now: | 21:34 |
| lifeless | - make a source tarball | 21:34 |
| lifeless | - tell plugin folk | 21:34 |
| lifeless | - wait | 21:34 |
| lifeless | - make binaries once plugins are released | 21:34 |
| lifeless | - announce to the world | 21:34 |
| kiko | I think we can solve this by allowing a configurable expiration time -- is that correct still cprov? | 21:35 |
| lifeless | folk running nightlies will still suffer, but thats less solvable by process, and more by faster-plugin-updates | 21:35 |
| lifeless | possibly nightlies should disable version locks ;) | 21:35 |
| lifeless | kiko: ECHANNEL. | 21:35 |
| cprov | kiko: supersede-date, maybe ? (when binaries are excluded from the repo indexes) | 21:36 |
| lifeless | oh, hmm. | 21:36 |
| kiko | cprov, yeah, that's what I'm htinking too | 21:36 |
| lifeless | the apt thing is twofold though | 21:36 |
| lifeless | there is the fact that old binaries go, and we've filed a bug on that ages back :) | 21:36 |
| lifeless | but the bigger problem is the version-lock that various plugins have | 21:36 |
| lifeless | which makes it an all-or-nothing upgrade step | 21:37 |
| cprov | what's the problem with having a bzr meta-package (as ubuntu does for linux) ? | 21:37 |
| cprov | someone suggested it in the past, but I honestly don't remember the arguments against it. | 21:37 |
| lifeless | cprov: I don't quite see how that helps. | 21:37 |
| lifeless | (ignoring transition issues and the fact that installing bzr shouldn't depend: on recommends-and-suggests) | 21:38 |
| vila | SamB: Just pushed one on trunk (bxt-gtk) | 21:38 |
| SamB | vila: wonder how long until it shows up in one of my apt sources ... | 21:39 |
| cprov | lifeless: uhm, bzr doesn't really have a slow-moving ABI on which plugins depend on ... | 21:39 |
| vila | SamB: far longer as a release is needed for that :-/ | 21:39 |
| SamB | 'kay ... | 21:40 |
| vila | SamB: I'll see what I can do tomorrow | 21:40 |
| cprov | lifeless: you are right, meta-packages doesn't make sense in this scenario, the relation bzr <=> plugins is 1:1, right ? | 21:41 |
| lifeless | cprov: can you unpack that a bit; I think I know what you mean but I'm not sure I do. | 21:41 |
| cprov | lifeless: version would be part of the source/binary name of bzr and its plugins. | 21:42 |
| SamB | vila: http://arcanux.org/lambdacats_3.html#entry9 | 21:42 |
| lifeless | bug 400009 just rolled past my screen :) | 21:42 |
| ubottu | Launchpad bug 400009 in ubunet "I had a problem with... finding a tutorial for ubuntu one, particularly, understanding sharing with others." [Undecided,Fix released] https://launchpad.net/bugs/400009 | 21:42 |
| lifeless | we've come a long way since 1 | 21:42 |
| lifeless | cprov: so, some plugins work with any bzr version. | 21:43 |
| lifeless | cprov: others are API locked | 21:43 |
| vila | SamB: ROTFL | 21:43 |
| lifeless | and others are weakly API locked in that they work with e.g. 1.14 or newer only. | 21:43 |
| cprov | lifeless: right, when the old bzr version vanish plugins with version lock breaks bzr upgrades. Is this what really happens ? | 21:44 |
| cprov | lifeless: while the desirable would be apt avoiding the upgrade until the suitable plugins show up ? | 21:45 |
| SamB | vila: Simon is the name of both of the lead developers of GHC (the Glasgow Haskell Compiler), but I suppose that's hardly important to the joke ;-) | 21:48 |
| jam | lifeless: please submit your patch :) | 21:48 |
| lifeless | jam: I did | 21:49 |
| vila | Ha ! GHC, acronym of the day, was wondering what it was a couple of hours ago, thanks :) (I ended up with Gnu Haskell Compiler, close enough :) | 21:49 |
| jam | lifeless: I meant to PQM, but perhaps you did that as well | 21:49 |
| lifeless | jam: launchpad processes mail via cron, which is slow compared to listening on a socket | 21:49 |
| lifeless | jam: oh, pqm - will do once my current one lands | 21:49 |
| jam | lifeless: I saw your submission, and I approved it :) | 21:50 |
| lifeless | jam: in lsprof | 21:55 |
| jam | ? | 21:55 |
| SamB | vila: where did you encounter it then? | 21:55 |
| lifeless | _g_threadmap is only global so that the thread_profile can use it, right? | 21:55 |
| vila | SamB: while toying with an OS that insist about recompiling anything and everything everytime you breath :) | 21:57 |
| jam | lifeless: I assume it is to pass state between 'profile()' and _thread_profile | 21:57 |
| SamB | vila: what, Gentoo^10? | 21:57 |
| jam | lifeless: so... yes | 21:57 |
| vila | SamB: :) | 21:57 |
| lifeless | jam: same conclusion I came to. | 21:58 |
| lifeless | *boom bye bye baby* | 21:58 |
| === thumper-zzz is now known as thumper | ||
| === raimue is now known as Raim | ||
| ohmy | Hello | 22:26 |
| g0nzal0 | hi | 22:26 |
| g0nzal0 | this seems to be happening to me: https://bugs.launchpad.net/bzr-svn/+bug/413113 | 22:27 |
| ubottu | Launchpad bug 413113 in bzr-svn "SubversionException: ('Svndiff contains a too-large window', 185001)" [Undecided,New] | 22:27 |
| g0nzal0 | is there a workaround? | 22:27 |
| ohmy | hapy with bzr abd apedt to command line, i'm using bzr since months a go and i have to work with some windows developers and hince the ethernel question : it"s a very cool tool but what about user interface | 22:27 |
| g0nzal0 | ohmy, http://bazaar-vcs.org/BzrPlugins#GUI%20(Graphical%20User%20Interfaces%20for%20Bazaar) | 22:28 |
| ohmy | i would like to know (i have tried most of the tools provided in bzr web pages) if there are real (even comercial) gui frontend with full feature set, i mean, most of the persons i'm working with have a nice experience with bitkeeper (excellent gui) cm synergy and some already habituated with svn | 22:29 |
| thumper | is format "2a" going to become "2" before 2.0? | 22:30 |
| thumper | to me "2a" is 2-alpha, which it was at the time | 22:30 |
| thumper | but probably not the best name for a default format :) | 22:30 |
| lifeless | thumper: I feel the same way. | 22:30 |
| lifeless | thumper: I lost debating this with poolie | 22:31 |
| thumper | poolie disagreed? | 22:31 |
| abentley | thumper, lifeless: I agree with you. | 22:32 |
| ohmy | as i have said, for me command line is all what any serious developer/integrator need to use to work properly, but i didnt succeed to find anything similar to kdesvn for example, some tools only show only branches / diff .. | 22:32 |
| jam | thumper: we can't change the disk string without causing everyone to upgrade | 22:35 |
| jam | potentially we could change the command line string, though | 22:35 |
| jam | personally 'a' was just the first letter, and not representing 'alpha' | 22:35 |
| lifeless | thumper: poolie chose 2a | 22:36 |
| thumper | jam: but there is common perception that a means alpha, so 2a will be thought of as 2-alpha | 22:36 |
| thumper | no matter what _we_ think | 22:36 |
| lifeless | our docs say we should have done 1.16 | 22:36 |
| lifeless | which would confuse people in a different way | 22:36 |
| lifeless | 'what is 1.16 and why does 2.0 use it' | 22:36 |
| jam | lifeless: how 'stable' do you think the sort order needs to be ? | 22:38 |
| jam | We can have it "stable such that 2 people with the same graph get the same result" | 22:38 |
| jam | or "stable such that people with similar graphs" get the same "subsets" | 22:38 |
| jam | the problem is that not even 'merge_sort' is stable when you add extra keys which may become the new tips | 22:39 |
| lifeless | jam: lets think about the impact. in small branches, well who cares. | 22:39 |
| lifeless | in large branches, a order-change will cause group recompression in the middle of an existing large pack | 22:40 |
| lifeless | so we'll care mode | 22:40 |
| lifeless | *more* | 22:40 |
| jam | lifeless: so this is mostly about whether 'bzr pack' considers a pack to already be optimal? | 22:42 |
| jam | consider that if we fetched in gc-optimal ordering, but didn't recombine groups | 22:42 |
| lifeless | right | 22:42 |
| jam | the ordering could match exactly, but the contents would be poorly packed | 22:42 |
| lifeless | so we're fixing the recombine | 22:42 |
| === fta_ is now known as fta | ||
| lifeless | I think its ok if similar graphs get the same long runs internall | 22:43 |
| lifeless | the key thing you're saying is 'if you don't start at the edge, the sort can be different' | 22:44 |
| lifeless | but I thought that gc-optimal already required that we start at the edge ? | 22:44 |
| jam | lifeless: so we are sorting an arbitrary graph with multiple heads | 22:45 |
| jam | and compare that with another graph | 22:45 |
| jam | that adds 1 node | 22:45 |
| jam | which is a new head | 22:45 |
| lifeless | so, the partial ordering of heads. | 22:45 |
| lifeless | has to be partial by definition, I think. | 22:46 |
| lifeless | but it would be good to say that three heads | 22:46 |
| lifeless | A B C | 22:46 |
| lifeless | always come out A B C | 22:46 |
| jam | http://paste.ubuntu.com/258946/ | 22:46 |
| lifeless | wouldn't it? | 22:46 |
| jam | lifeless: sure, but you can have children of them which then become D E F, or alternatively F E D | 22:47 |
| jam | slightly illustrated in the paste | 22:47 |
| lifeless | so D is a child of A? | 22:47 |
| lifeless | 'newer than A' | 22:47 |
| jam | D is a child of A | 22:47 |
| jam | my text has a bogosity | 22:47 |
| jam | but yes, time goes down | 22:47 |
| mathbr | Hi, has anyone ever encountered this one: http://pastebin.com/m23f28c83 | 22:47 |
| mathbr | Only invoking "diff" and "status"… | 22:47 |
| lifeless | then we want DA CB | 22:47 |
| lifeless | or CB DA | 22:47 |
| lifeless | don't we? for idea compression... | 22:48 |
| jam | http://paste.ubuntu.com/258947/ | 22:48 |
| lifeless | mathbr: hmmm | 22:48 |
| lifeless | mathbr: run 'bzr check' please | 22:48 |
| jam | lifeless: isn't that the "os.listdir()" returns a filename for which "os.lstat()" claims it doesn't exist? | 22:49 |
| jam | (using the POSIX functions directly, of course) | 22:49 |
| jam | so readdir(), and lstat, IIRC | 22:49 |
| jam | lifeless: I believe you are right about DA CB or CB DA | 22:49 |
| mathbr | lifeless: This one now: http://pastebin.com/m3515a14e | 22:50 |
| jam | my specific point was that whether D or C comes first is fairly independent of which of A and B came first last time | 22:50 |
| mathbr | I indeed removed a directory by hand after bzr told me it couldn’t because there were files left in a directory | 22:50 |
| mathbr | s/a/that | 22:50 |
| jam | lifeless: so the test I was writing was something like this: | 22:54 |
| jam | http://paste.ubuntu.com/258949/ | 22:54 |
| lifeless | jam: yes thats true. we'd have to define a sort on the roots of the graph | 22:54 |
| jam | The current implementation is 'depth first' | 22:54 |
| jam | which is the first => E D F B C A | 22:54 |
| jam | we could do 'layer by layer' | 22:54 |
| jam | and get something like the second | 22:54 |
| jam | which seems to have the advantage that "B C D A" is preserved after adding nodes | 22:55 |
| jam | though I'm pretty sure with arbitrary changes I can break that | 22:55 |
| lifeless | gits approach of graph depth makes a great deal of sense to me; the problem is changing heads in that definition. | 22:56 |
| lifeless | so you're right to say 'what is this really about' | 22:57 |
| jam | the idea of 'depth first' stability, though, seems to lead to better clustering (i think) | 22:58 |
| jam | http://paste.ubuntu.com/258954/ | 22:58 |
| lifeless | perhaps this is a better way to phrase the problem/challenge: | 22:58 |
| lifeless | - gc-optimal is not a fixed order on nodes; its a fixed _goal_ of data compression | 22:58 |
| jam | even if it isn't "as stable" it is more likely to bring parents and children closer to each other | 22:59 |
| lifeless | - gc optimal reading from existing groups should be permitted to preserve the groups, as long as it shoves good-to-have-together groups together. | 22:59 |
| lifeless | - the overall goal is to make incremental operations like push/pull/autopack behave well; unneeded recompression and fragmentation is what we're seeing at the moment | 23:00 |
| lifeless | garyvdm: hi gary. Yes, its 8am here :P | 23:00 |
| jam | you know... we could use gdfo, and sort it by (gdfo, revision_id)... I would think that would handle the stability fairly well, at the expense of not being the best compression order. | 23:00 |
| garyvdm | Hi lifeless. | 23:01 |
| garyvdm | Hi jam | 23:01 |
| jam | hi garyvdm | 23:01 |
| mathbr | I did a clean checkout now since I don’t really have the time to investigate this bug. The backtraces are up for one month. Bye | 23:04 |
| itistoday | is there a way to easily have conflicts automatically resolved? | 23:08 |
| itistoday | i.e. say that I just want to get rid of the changes I have in my working dir, and keep the ones from the result of updating the tree | 23:08 |
| lifeless | bzr revert | 23:09 |
| itistoday | lifeless: thanks! | 23:10 |
| jam | lifeless: so my first goal is to make it stable wrt dict ordering | 23:10 |
| jam | as that is the major limitation of the algorithm today | 23:10 |
| jam | since python dict ordering can depend on the order the dict was populated | 23:10 |
| jam | (from collisions, etc) | 23:10 |
| poolie | hi jam, thumper, lifeless | 23:11 |
| jam | hi poolie | 23:11 |
| jam | ready for a call today? | 23:11 |
| poolie | yes that'd be good | 23:11 |
| poolie | regarding 2a, a is a sequence letter, not 'alpha' | 23:11 |
| poolie | i realize people may read it the other way | 23:11 |
| poolie | but | 23:11 |
| poolie | i'm not going to change it now | 23:12 |
| poolie | we had a thread about this and nobody seemed to have a better idea that met the requirements | 23:12 |
| poolie | the main one being that it be 2-something and not look like a release number | 23:12 |
| jam | poolie: we could just call it '--2' on the command line and worry about incrementing when we actually release the next repo format | 23:12 |
| poolie | we could say just '2' means the latest format 2 or something | 23:13 |
| jam | poolie: do you want to just skype me directly? | 23:15 |
| poolie | heh, jinx | 23:15 |
| poolie | i can't see you online... | 23:15 |
| jam | I might have accidentally stopped it. | 23:18 |
| jam | looks like | 23:18 |
| jam | try now | 23:18 |
| jam | "Contact can only receive IMs" ? | 23:19 |
| === tchan1 is now known as tchan | ||
| lifeless | poolie: are you still on the phone? | 23:49 |
| lifeless | for bug 393677 I think we should just error cleanly. 'you need to upgrade'. | 23:49 |
| ubottu | Launchpad bug 393677 in bzr "pushing a 1.9 branch stacked on a 2a branch causes problems" [High,Confirmed] https://launchpad.net/bugs/393677 | 23:49 |
| lifeless | having the branch someone pushes be something they cannot bzr pull from would just be _weird_ | 23:50 |
| lifeless | or alternatively, not error, and just push a complete branch. | 23:50 |
| lifeless | fooding, back soon | 23:52 |
| poolie | lifeless: i am | 23:56 |
| poolie | that sounds reasonable | 23:56 |
| poolie | jam: still here? | 23:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!