| jbowtie | So I have to assume that I'm not leaving the branch in a consistent state in my plugin, trying to understand what's resumable. | 00:00 |
|---|---|---|
| beuno | ah, with bzrlib you surely can resume properly | 00:00 |
| poolie | hi beuno, all | 00:00 |
| beuno | if that's what your previous question was about | 00:00 |
| beuno | I was referring to jsut using the cli | 00:00 |
| beuno | hey hey poolie! | 00:01 |
| jbowtie | Well, I need to understand what the cli is supposed to do so I can use that in my scenario and see what gets called. | 00:02 |
| beuno | jbowtie, I'd suggest emailing the list about this | 00:03 |
| beuno | or getting poolie's attention ;) | 00:03 |
| poolie | jbowtie, that'that sounds great | 00:03 |
| poolie | jbowtie, so just at a guess you need to make sure the fetch finishes before updating the branch pointer | 00:04 |
| poolie | ah, and perhaps check that you've released the write lock on the repository too | 00:04 |
| poolie | which should serve to flush out pending state | 00:04 |
| poolie | hth | 00:04 |
| poolie | spiv, are you here? | 00:04 |
| spiv | Good morning! | 00:05 |
| poolie | hey there, isn't it impressively damp in sydney today | 00:05 |
| jbowtie | poolie: Well, if an exception gets thrown that's what should be happening. | 00:07 |
| jbowtie | poolie: I call target.unlock in the exception handler; I also wrap the creation of inventory and revision in a write_group and call abort_write_group if something goes wrong. | 00:08 |
| jbowtie | poolie: So when I lose the connection in the middle of building a revision, I expect the repository is in a consistent state. | 00:09 |
| jbowtie | poolie: But no branch is created since the repository hasn't finished populating yet. | 00:10 |
| jbowtie | poolie: So I'm sitting there with a partially populated repository, no branch, no working copy. | 00:10 |
| jbowtie | poolie: I'm just not sure how I'm supposed to resume from the command line, or if that's even possible. | 00:11 |
| poolie | you should be able to just branch again into the same repository? | 00:12 |
| beuno | poolie, but only if he has a shared repo | 00:12 |
| jbowtie | poolie: I get an error about the directory already existing. | 00:13 |
| beuno | not sure if --use-existing helps there or not | 00:13 |
| poolie | ah ok, so the half-created branch is getting in the way? | 00:13 |
| poolie | there's a bug open for this | 00:13 |
| poolie | for now unfortunately you have to just delete it | 00:13 |
| jbowtie | poolie: I expect so, yes. | 00:14 |
| jbowtie | poolie: That's what I've been doing. | 00:14 |
| jbowtie | poolie: I was just hoping there was a better way, TFS is so slooooooow. | 00:14 |
| jbowtie | poolie: Branching 1000 revisions is an overnight job. | 00:15 |
| jbowtie | Is there a way via bzrlib to get rid of the half-created branch and resume fetching the revisions into the repository? | 00:16 |
| jbowtie | poolie: Do you know the bug number? | 00:16 |
| beuno | jbowtie, from bzrlib, resuming should be easy-ish | 00:18 |
| beuno | that said, I'm going afk to walk the dog and dinner with the inlaws :) | 00:19 |
| jbowtie | beuno: It's morning for me, so I'll still be here if you want to illuminate me later. | 00:20 |
| Lor | Will anything break if I have a bzrdir that has neither repository, branch nor checkout? | 00:20 |
| Lor | ah, bzr-colo does it already | 00:23 |
| poolie | jbowtie, it's something like https://bugs.edge.launchpad.net/bzr/+bug/125067 or bug 116148 | 00:34 |
| ubot5 | Launchpad bug 116148 in Bazaar "bzr branch should be resumable if interrupted (affected: 4, heat: 13)" [Wishlist,Confirmed] https://launchpad.net/bugs/116148 | 00:34 |
| ubot5 | Launchpad bug 125067 in Bazaar "allow 'bzr checkout' to resume (affected: 1, heat: 14)" [Wishlist,Confirmed] | 00:34 |
| lifeless | jam: had fun ? | 01:21 |
| zerd | How do I enable colors in bzr diff's output? | 01:50 |
| nDuff | zerd, consider bzr cdiff; you may need bzrtools installed | 01:51 |
| zerd | ah. nice. | 01:57 |
| zerd | Is it any way to automatically use a pager (less) to paginate long output? | 01:58 |
| * nDuff doesn't know. | 01:59 | |
| spiv | There's a bzr-pager plugin, not sure how up to date it is. | 02:00 |
| zerd | hmm.. cdiff didn't act nice with less | 02:04 |
| nDuff | zerd, less -r | 02:07 |
| lifeless | poolie: I propose we give mgz landing rights | 02:32 |
| poolie | +1 | 02:40 |
| * igc lunch | 03:29 | |
| === retupmoca` is now known as retupmoca | ||
| parthm | mgz: ping ... gz .. is that you. the irc denizen formerly known as a[0-9]+ :) | 04:35 |
| jbowtie | Argh! TFS says a label can't be more than 64 characters! | 04:41 |
| jbowtie | That means I have no way to store a bzr-revid for roundtripping of commits. | 04:41 |
| poolie | maybe you can stash it in a hidden file in the branch | 04:46 |
| === jamesh_ is now known as jamesh | ||
| jbowtie | poolie: Sorry, I'm being dense, how would that work? | 04:54 |
| poolie | jbowtie, is this pullying from tfs into bzr, or vice versa, or both? | 04:58 |
| jbowtie | poolie: This was pushing a commit from bzr into tfs, then pulling back to bzr. | 05:01 |
| jbowtie | poolie: TFS requires the admin to create metadata fields on a per-project basis, so there's no reliable place to store the revid. | 05:02 |
| jbowtie | However, I have just worked out a clever solution - hide the revid at the bottom of the comment when I push to TFS, strip it off when I pull. | 05:03 |
| jbowtie | A little uglier than I would like but it's pretty foolproof as far as round-tripping goes. | 05:05 |
| jbowtie | I'll just need to create an actual foreign VCS mapping class (which I'd managed to avoid to date). | 05:05 |
| vila | spiv: Don't land lp:~spiv/bzr/no-sigwinch-583941 into lp:bzr/2.1 yet, I'd like to discuss it first which requires a bit of investigation | 07:14 |
| vila | hi all, oops, first things first | 07:15 |
| spiv | vila: Sure | 07:15 |
| spiv | vila: I imagine if it works in emacs then it's probably close enough ;) | 07:16 |
| vila | spiv: that's the point, look at 4747.4.3 | 07:17 |
| spiv | vila: ah, and I see there's a test in test_osutils that that patch will trip up on. | 07:18 |
| vila | spiv: haaaaa, I'm so glad about this :) | 07:19 |
| vila | spiv: comment sent, basically COLUMNS *can* differ from _terminal_size and be right | 07:19 |
| spiv | I was wondering where relevant tests were; I did run some blackbox tests as a smoke test. | 07:20 |
| spiv | But running the full suite just takes too long for me now :( | 07:20 |
| vila | apart from the emacs case, I think resizing a window so that a scrollbar appears may be another one | 07:20 |
| vila | and then there is.... let me find that bash setting | 07:20 |
| vila | checkwinsize | 07:21 |
| vila | spiv: try to play a bit with 'checkwinsize' ... you'll live interesting times | 07:21 |
| spiv | I'll do that. | 07:22 |
| lifeless | spiv: I'd like to fix the test suite | 07:22 |
| lifeless | but thats another story | 07:22 |
| spiv | There is definitely something screwy about the code as it is in 2.1 today, though. | 07:22 |
| spiv | lifeless: me too! | 07:22 |
| vila | spiv: apart from the EINTR fallouts you mean ? | 07:23 |
| spiv | Because the SIGWINCH handler will happily reset os.environ['COLUMNS'] | 07:23 |
| spiv | Using the value from _terminal_size | 07:23 |
| vila | spiv: see comment, that's a shortcut | 07:23 |
| vila | spiv: once you respect COLUMNS, you should continue :) | 07:24 |
| vila | spiv: even by tricking yourself :) | 07:24 |
| lifeless | holy cow | 07:24 |
| lifeless | tripit is good | 07:24 |
| lifeless | it combined two separate bookings into one trip | 07:24 |
| lifeless | poolie: ^ :) | 07:24 |
| spiv | vila: which comment? | 07:25 |
| spiv | vila: the code + comments as they are at the moment don't make sense to me | 07:25 |
| vila | spiv: I think I didn't realize that when I wrote the code but that desserve a comment in the code about it | 07:25 |
| vila | spiv: I was referring to the mp comment | 07:25 |
| vila | spiv: don't make sense doesn't mean incorrect :) | 07:26 |
| vila | the root is that COLUMNS and _terminal_size can disagree, the rest follows from that | 07:26 |
| spiv | vila: well, I changed the comment to match the change to the code, not because I disagreed :) | 07:27 |
| vila | spiv: but you didn't change the docstring ! :-p | 07:27 |
| spiv | Yes, but what precisely should happen when they disagree? | 07:27 |
| spiv | vila: well, I'm not perfect :) | 07:27 |
| vila | no worries, just kidding | 07:27 |
| vila | spiv: good question, the actual answer was giving me a correct behavior in all configs I tried | 07:28 |
| lifeless | so | 07:28 |
| spiv | At the moment the policy *seems* to be "trust $COLUMNS until SIGWINCH happens (then trust _terminal_size)" | 07:29 |
| lifeless | what happens if we just revert everything | 07:29 |
| lifeless | what would break | 07:29 |
| vila | spiv: yup | 07:29 |
| spiv | Which doesn't seem to make much sense to me, because if we can trust _terminal_size after SIGWINCH, why not before? | 07:29 |
| vila | spiv: because there are known cases where it's wrong, try 'checkwinsize' | 07:29 |
| vila | spiv: that's what I try to explain in the mp comment | 07:30 |
| spiv | (My sigwinch-without-signalmodule-583941 can preserve that behaviour without causing EINTR) | 07:30 |
| * spiv looks at checkwinsize | 07:31 | |
| vila | spiv: ECONTEXT, why the new proposal then ? | 07:31 |
| spiv | Because that proposal added a new C module | 07:31 |
| vila | lifeless: I'm pretty sure we will end up with terminal_width defaulting to None instead of 80 before the patchES | 07:31 |
| vila | i.e. blowing up buildbot with flog files full of spaces or something | 07:32 |
| vila | hehe, yeah flog | 07:32 |
| spiv | checkwinsize means bash promises that COLUMNS will be up-to-date when it invokes bzr, AIUI? | 07:32 |
| vila | spiv: yes | 07:32 |
| spiv | So _terminal_size would == $COLUMNS, then? | 07:32 |
| vila | spiv: no | 07:33 |
| vila | that's the point | 07:33 |
| vila | COLUMNS can be set by the application controlling the terminal | 07:33 |
| vila | think scrollbars, split (sp?) screens, etc | 07:34 |
| spiv | Which is bash, if we're talking about checkwinsize | 07:34 |
| vila | At the time I researched, COLUMN and _terminal_size could differ, bash's chekwinsize was just the easiest way I found to demonstrate it | 07:35 |
| spiv | So here's what I don't understand. | 07:35 |
| spiv | I think perhaps you are talking about emacs-running-bash-running-bzr? | 07:36 |
| spiv | Or, actually, that doesn't matter. | 07:36 |
| vila | no, doesn't matter, yes that's my *daily* env | 07:37 |
| === nlisgo_ is now known as nlisgo | ||
| vila | spiv: http://www.ohse.de/uwe/software/resize.c.html for some background (but note that he doesn't respect COLUMNS knowingly) | 07:38 |
| spiv | You're saying somehow there's a situation in which a) $COLUMNS is different to and more correct than _terminal_size, but also b) that after a SIGWINCH _terminal_size is better than COLUMNS | 07:38 |
| vila | spiv: roughly yes, | 07:38 |
| vila | after SIGWINCH, it's not "better" but... the best we have IMHO | 07:39 |
| poolie | hi vila | 07:40 |
| spiv | Because we know that the size must have changed, and _terminal_size is the only thing that indicates how? | 07:40 |
| vila | poolie: hey ! | 07:40 |
| poolie | spiv i can't remember if i voted but i like the approach much better | 07:40 |
| spiv | So, if that's the case: | 07:40 |
| vila | spiv: ... did I make a such poor job to explain myself in that mp's comment or what ? :) | 07:40 |
| spiv | a) we can do that without SIGWINCH; just ask for _terminal_size every time but prefer $COLUMNS until we observe a change in _terminal_size | 07:41 |
| vila | spiv: sure | 07:41 |
| vila | spiv: my point was to respect COLUMNS at the first try | 07:41 |
| spiv | b) I'm skeptical that this tradeoff is working well in practice, because if _terminal_size is initially wrong due to the issues you mention then it will always be wrong. | 07:42 |
| vila | spiv: on the performance front, remember that before handling SIGWINCH some parts of the code were caching a value, now we'll call ioctl() for *each* output line produced | 07:42 |
| spiv | vila: _terminal_size takes 11 microseconds on my slowish laptop. | 07:43 |
| vila | cool | 07:43 |
| spiv | Can you give me a precise recipe to observe COLUMNS being more accurate than _terminal_size? | 07:44 |
| vila | Ha, the tricky one :-/ | 07:45 |
| vila | not from memory but I can try to find it back | 07:45 |
| === nlisgo_ is now known as nlisgo | ||
| vila | spiv: http://www.zsh.org/mla/workers/1999/msg01597.html seem to contain an analysis of various softwares behaviors | 07:55 |
| vila | spiv: while not giving a recipe to reproduce, it demonstrate that in many cases people chose to respect COLUMNS first, then TIOCGWINSZ when the terminal is resized | 07:57 |
| vila | spiv: hehe, see http://old.nabble.com/Unable-to-see-os.environ-%27COLUMNS%27--td19487200.html for additional fun :) | 08:00 |
| vila | spiv: perl does it too: http://cpansearch.perl.org/src/AMBS/Lingua-Jspell-1.63/src/term.c (not sure if you will buy that though :) | 08:02 |
| spiv | The only example situation that I see in those links so far is using a terminal over a crummy protocol that can't report window size changes (except by moving the cursor via ANSI sequences and then asking via another ANSI sequence where the terminal thinks it is). | 08:03 |
| spiv | But you've had trouble yourself? | 08:03 |
| vila | yes, emacs + bash + bzr | 08:04 |
| vila | but the discussion about zsh is very close to the one we're having here | 08:05 |
| spiv | The python-list link didn't tell me anything new, just that shells may or may not export $COLUMNS, and of course the shell can't reach into a subprocess to update its $COLUMNS after it starts. | 08:06 |
| vila | spiv: forget that one, was just for fun about a non-exported variable, but yes once python is started there is no way to get back at the env variable, even if it's updated which is not always the case | 08:07 |
| spiv | The zsh discussion was mainly about when to update and when to export the shell-internal COLUMNS/LINES values. | 08:08 |
| vila | spiv: but mentions that COLUMNS should be respected at start | 08:09 |
| vila | spiv: the fact that I can't find a recipe shouldn't invalidate the fact that many people refer implicitly to such recipes :) | 08:09 |
| spiv | vila: the perl link has comment that doesn't match the code! | 08:10 |
| vila | spiv: really ? It calls TICOCGWINSZ and *then* overrides with COLUMNS is set, what doesn't match ? | 08:11 |
| vila | s/is set/if set/ | 08:12 |
| spiv | vila: the comment says the env variables override the *termcap* info, but the code actually overrides the termios (TIOCGWINSZ) values with env variables as well. | 08:12 |
| spiv | So it's very unclear to me whether it does that by accident or on purpose. | 08:12 |
| spiv | vila: so my concern at this point is that "use COLUMNS until WINCH happens" is sounding more and more like a superstition without solid evidence the more links I read! | 08:13 |
| spiv | It's entirely possible there's a solid justification for it, but no-one seems to know what it is :) | 08:14 |
| vila | spiv: and based on that you're going to consider that it's false ? | 08:14 |
| spiv | Well, "lots of other people do it" is an argument for us doing it too. | 08:14 |
| spiv | But it feel pretty nervous and unconvinced, which is why I'd like to be able to reproduce a scenario where I can see the difference. | 08:15 |
| vila | apart from the emacs one I'm sure I encountered another one but I can't remember what was involved | 08:15 |
| * StevenK grumbles. bzr add-pipe died with a NoneType has no attribute get_config | 08:16 | |
| spiv | StevenK: upgrade your bzr | 08:16 |
| vila | some terminal emulator or even vim or less or... | 08:16 |
| spiv | vila: tell me more about the emacs case. This is emacs running in a terminal, not in its own GUI window? | 08:16 |
| vila | own GUI window, shell as a subprocess | 08:17 |
| spiv | Huh, so why isn't the TIOCGWINSZ going to be correct in a tty emacs created? emacs bug? | 08:18 |
| StevenK | spiv: But 2.1.2 isn't out yet? :-) | 08:20 |
| vila | spiv: TIOCGWINSZ when WINCH is more correct because emacs can't change the bash env variable when the window is resized | 08:20 |
| igc | hi vila | 08:22 |
| spiv | vila: right, but TIOCGWINSZ should also be totally correct before WINCH too | 08:22 |
| spiv | vila: i.e. in that situation it seems to me the best thing to do would be to ignore COLUMNS entirely | 08:23 |
| vila | spiv: In fact, I can even find cases where both COLUMNS and TIOCGWINSZ are wrong (for the user: me) when python starts and changing the window size *after* that can only be accessed via TIOCGWINSZ | 08:23 |
| spiv | vila: ooh, tell me more! | 08:23 |
| vila | spiv: ok, I resign, I tried to explain that there are cases where COLUMNS *must* be respected, if you want to ignore that, just fo it | 08:23 |
| vila | spiv: start emacs, start a shell, resize windows, echo $COLUMNS, python -c 'from bzrlib import osutils; print "COL: [%r]" % (osutils.terminal_width(),)' will both disaply the *old* value | 08:24 |
| lifeless | StevenK: you're on the lp team now, add the bzr ppa :) | 08:24 |
| vila | spiv: start bzr log, resize window, osutils.terminal_width() got the good value | 08:25 |
| lifeless | StevenK: and no, not the releases one. The *other* one :P | 08:25 |
| spiv | vila: ah, a recipe, thanks! Time to dust of my memory of emacs... | 08:25 |
| StevenK | lifeless: There's another one? :-) | 08:26 |
| lifeless | nightlies | 08:26 |
| spiv | vila: while I'm waiting for apt, what does python -c 'from bzrlib import osutils; print osutils._terminal_size(None, None)' report in that case? | 08:27 |
| * vila use history since the command is already there :) | 08:27 | |
| StevenK | lifeless: Which team does that one hide under, since it isn't ~bzr? | 08:27 |
| lifeless | statik, I think | 08:28 |
| lifeless | hey, use the vaunted ppa search | 08:28 |
| lifeless | or look on our downloads page ;) | 08:28 |
| vila | spiv: the value set when the bash subprocess was started, and my recipe is wrong because SIGWINCH is not propagated anyway :( | 08:28 |
| lifeless | wiki page I mean | 08:28 |
| lifeless | vila: so perhaps its 'emacs is broken, gnar gnar gnar ? | 08:28 |
| vila | spiv: no wait | 08:29 |
| vila | lifeless: :) | 08:29 |
| vila | grr, what was the application that was able to split the screen damnit, I didn't mention it out of thin air.... | 08:30 |
| spiv | screen? | 08:30 |
| lifeless | terminator? | 08:30 |
| vila | maybe, I used neither of them :( | 08:30 |
| lifeless | or its new version, hate | 08:30 |
| lifeless | Ng: ^ :P | 08:30 |
| StevenK | lifeless: I find it odd that the nightly-ppa hasn't been updated in two months | 08:32 |
| lifeless | haha | 08:32 |
| lifeless | statik: ^ | 08:32 |
| lifeless | ok, I give, run trunk. | 08:32 |
| lifeless | igc: would love it if you could start setting commit messages in your merge proposals | 08:34 |
| igc | lifeless: ah - ok. Will do | 08:34 |
| lifeless | also | 08:35 |
| spiv | vila: so for me, in M-x shell, COLUMNS is 80 regardless of window size, and _terminal_size is 0,0 regardless of window size | 08:36 |
| lifeless | when you send something to pqm please say so on the mp | 08:36 |
| lifeless | so that I don't double submit :) | 08:36 |
| lifeless | hydrazine will do this for you | 08:36 |
| igc | ok | 08:37 |
| spiv | vila: so it seems to me that an equally good policy for you would be "try BZR_COLUMNS, then TIOCGWINSZ then COLUMNS, until you find one that is not missing and not zero. If all else fails, guess 80." | 08:38 |
| lifeless | igc: the result of automation: - http://pqm.bazaar-vcs.org/ | 08:38 |
| igc | lifeless: nice | 08:39 |
| vila | spiv: this is equally superstitious about TIOCGWINSZ returning wrong values and COLUMNS being right in that case | 08:40 |
| spiv | vila: (to be more precise, COLUMNS is accurate when emacs starts the M-x shell, and the termios size is never set) | 08:40 |
| vila | spiv: and where is the recipe for termios size never set ? :-P | 08:41 |
| spiv | vila: I don't think it's particularly superstitious. | 08:42 |
| vila | spiv: then go for it, both solutions need to be tested in the field, I wasn't entirely clear with my solution, I don't think yours is worse or better, just different, the interweb doesn't seem to agree on either one anyway and BZR_COLUMNS is there to address obscure cases | 08:44 |
| spiv | The logic is simply: BZR_COLUMNS first, because it's an explicit user-knows-best override. Then ask the OS directly if it thinks it knows the terminal size (and if the terminal creator is good enough, it will be correct -- I don't know of any reason why emacs couldn't issue TIOCSWINSZ to set the size), because the OS ought to know best and can update it for window resizes. | 08:44 |
| spiv | Then fallback to COLUMNS, which if set is likely to be better than nothing, then fallback to 80 as the default everyone expects. | 08:45 |
| vila | spiv: yeah, I did that *first* and then I switched | 08:46 |
| vila | but don't force 80 either, some callers expect None for no defined width | 08:46 |
| spiv | Ah, sure. | 08:47 |
| spiv | Why did you switch? | 08:47 |
| vila | shudder | 08:47 |
| * igc dinner | 08:48 | |
| vila | because I encountered a case where it was needed, found some evidence for it reading the web and... | 08:48 |
| vila | fail to note the recipe (I should have known better :) | 08:48 |
| spiv | :) | 08:48 |
| spiv | Perhaps we should just let users with broken terminals write a plugin to override osutils.terminal_width as they need :P | 08:49 |
| vila | now, did I reproduce it or was I so convinced by some explanation that I didn't reproduce it in fact ? | 08:49 |
| vila | spiv: That's why I added BZR_COLUMNS: this terminal size stuff is messy, let's punt | 08:49 |
| vila | :) | 08:49 |
| spiv | vila: you should have made it be a python expression, for maximum flexibility ;) | 08:50 |
| vila | spiv: see, you use emacs for a minute and already you're starting to put hooks everywhere :-) | 08:51 |
| spiv | vila: don't worry, my evil overload laugh was well-honed already ;) | 08:52 |
| vila | spiv: bzr selftest -v | less :-( | 08:53 |
| vila | spiv: whatever, the lesson for me is once again: 'untested code is broken code', change that failing test to match your implementation, unless bugs are filed for specific cases I don't see how to address all possible cases without recipes :) | 09:02 |
| bialix | ~~~~ | 09:04 |
| joh | Hi, I get two strange messages when comitting to my branch: Unrecognized interpretation: SOURCE_CODE, Unrecognized manifestation: FILE_DATA_OBJECT | 09:13 |
| joh | What do they mean? | 09:13 |
| lifeless | could use a second reviewer on https://code.launchpad.net/~parthm/bzr/584650-incorrect-alias-info-in-help/+merge/26018 | 09:16 |
| lifeless | poolie: ^ if you're around, its trivial | 09:16 |
| poolie | ok maybe very quickly | 09:16 |
| poolie | then i need to go | 09:16 |
| poolie | bzrlib.help.help the comedian's a bear! | 09:16 |
| poolie | done | 09:17 |
| poolie | thanks lotzman | 09:17 |
| poolie | and good night | 09:17 |
| === radoe_ is now known as radoe | ||
| === nlisgo_ is now known as nlisgo | ||
| === nlisgo_ is now known as nlisgo | ||
| speakman | gmorning! | 10:25 |
| speakman | Is there any way to "rewrite" some old commit messages (due to character encoding change)? | 10:26 |
| bialix | only if you're ok to the fact all your history after that commit will be rewritten too. | 10:33 |
| bialix | GaryvdM: ping | 10:33 |
| speakman | how come I can't modify the author name and/or message of a single commit? | 10:37 |
| mgz | oh man, lots of exciting log to read this morning | 10:37 |
| mgz | there appears to be a good hour's worth just on signals and terminal size detection, now that is my idea of a good time. | 10:38 |
| mgz | the sad thing is... I should be being sarcastic, but am not. | 10:38 |
| spiv | vila: yeah, "bzr ... | less" or even just "| cat" is basically doomed as far as I can tell | 10:38 |
| spiv | vila: at least in my environment, in that situation COLUMNS is not set and _ioctl_terminal_size returns None,None | 10:39 |
| bialix | speakman: because DVCS insist on the immutability of the history | 10:40 |
| vila | COLUMNS is specific to some setups, that was my big problem with it, so no need to mention it if it's not set :) The problematic cases are when it *is* set :) | 10:40 |
| speakman | bialix: Yes I know, but in this case it doesn't matter. | 10:40 |
| spiv | (At least if the other end of the pipe is less then arbitrarily long lines don't matter much, unless we want to right-justify text at some point.) | 10:40 |
| bialix | speakman: if you change past commit, all commits after it should be changed too (at least their revids) | 10:41 |
| spiv | vila: right. So I'm thinking I'll make two patches: | 10:41 |
| speakman | bialix: is the revid connected to the author/commit message? | 10:41 |
| vila | spiv: I think the consensus for that was that bzr use None when the output is not a terminal, BZR_COLUMNS can rescue specific cases here | 10:41 |
| bialix | speakman: then I'd say you can branch that commit, uncommit, commit again with correct data. then replay all other commits on top of it | 10:42 |
| mgz | ack! if y'all keep talking, I'll never catch up | 10:42 |
| bialix | revid is revision id. it's unique | 10:42 |
| spiv | 1) for 2.1, a minimal patch that removes SIGWINCH by tries to preserve the existing behaviour (initially use COLUMNS then use termios width once we observe a change), including the rather odd part where os.environ['COLUMNS'] is mutated | 10:42 |
| bialix | yes, revid based on the author, commit message and all previous history | 10:42 |
| speakman | bialix: I can't possibly retain revid when changing message/committer? | 10:43 |
| vila | 1) adding the comment I forgot about why COLUMNS is mutated this way, yes, sounds good, minimal risk for 2.1 | 10:44 |
| spiv | 2) for trunk, a patch to use the implementation I outlined earlier, and see how that works out for people. I'll try to include an explicit list of relevant cases, e.g. M-x shell, and "bzr | less". | 10:44 |
| bialix | speakman: you should not | 10:44 |
| spiv | vila: Well, I can't add that comment, because I still don't know why it is mutated | 10:44 |
| vila | spiv: yup, behavior change for 2.2 , sounds good too | 10:44 |
| vila | spiv: because it masks the ioctl call() | 10:45 |
| spiv | vila: I mean, I know it is one way to get the "initially COLUMNS until WINCH" behaviour, but at the cost of mutating global state as a side-effect, state that subprocesses inherit! | 10:45 |
| vila | spiv: good, we want subprocesses to inherit the most current value :-) | 10:46 |
| spiv | Oh, so that part was intentional? Ok, that was totally unclear to me :) | 10:46 |
| spiv | I'm... unsure that it's a good idea, especially how we set it even if it wasn't set, but ok. I'm not too worried about subprocesses :) | 10:47 |
| vila | since it | 10:47 |
| vila | meh | 10:47 |
| spiv | After all, if this discussion has taught me anything, it's that random programs might do all sorts of things to determine the terminal size! :) | 10:47 |
| vila | since it's taken into account once set, WINCH blindly set it with the up-to-date value so that all subsequent callers get it, but the WINCH handler doesn't *respect* it of course | 10:48 |
| spiv | (To be clear, I'm not sure that it is a bad idea to set either) | 10:48 |
| spiv | Nothing in bzrlib/ looks at COLUMNS other than osutils | 10:49 |
| vila | spiv: good, that was my experience too when I worked on it (and boy did I not anticipate the can of worms it will open with other signals... I had enough with the term size...) | 10:49 |
| vila | spiv: well, at least we got that right: a single place where term size is determined :) | 10:50 |
| spiv | Yeah, that was a great relief to see :) | 10:50 |
| vila | but as the discussion with bialix at UDS revealed, the definition of what we do with that is still a bit unclear | 10:50 |
| vila | I don't remember if there are still places where we subtract one from that value for terms that include '\n' in that count | 10:51 |
| vila | spiv: but you're free to ignore this bit for your current submission :-O | 10:51 |
| vila | spiv: bzrlib.status.show_pending_merge() for one :-/ | 10:52 |
| bialix | vila: what? | 10:52 |
| vila | bialix: is terminal_width() the number of characters that could be displayed or should we subtract 1 because some terminals (including... the one you use on windows) requires it | 10:53 |
| bialix | yep | 10:54 |
| vila | bah, looking at the code it seems we *always* subtract 1, the progress bar stuff is a bit less clear about that so I'm only 50% sure there, but in all other cases it seems to be done unconditionally | 10:55 |
| bialix | vila: you broke this in selftest :-P | 10:56 |
| spiv | vila: ugh, yes, I fully intend to ignore that :P | 10:56 |
| spiv | vila: thanks for your patience | 10:57 |
| * spiv -> dinner | 10:57 | |
| * bialix -> lunch | 10:57 | |
| spiv | (Someone should have breakfast to complete the set... any takers?) | 10:57 |
| jelmer | I've just had breakfast | 10:58 |
| vila | here we are... | 10:58 |
| jelmer | well, s/just/one-and-a-half-hours ago | 10:58 |
| vila | too late, now we know | 10:58 |
| jelmer | :-) | 10:59 |
| vila | spiv: you're welcome, I should have discussed this when I was working on it... | 10:59 |
| mgz | okay, caught up. think I understand all of that. | 11:00 |
| vila | but, well, it sounds so inocuous :) | 11:00 |
| lifeless | mgz: not sure we do :P | 11:00 |
| vila | mgz: Do you have recipes ? :-P | 11:00 |
| mgz | how about this as a simple way for handling the case where the terminal size the kernel returns is not what the terminal emulator actually uses in the window: | 11:04 |
| mgz | if COLUMNS is valid, and kernel width is valid, but they differ, use COLUMNS | 11:05 |
| mgz | (keeping BZR_COLUMNS overriding both of those, of course) | 11:06 |
| mgz | given the huge number of different setup possibilities, never going to get this right for everything | 11:07 |
| thumper | bzr backed wiki: 0.1 now out the door: http://how-bazaar.blogspot.com/2010/05/wikkid-wiki.html | 11:10 |
| vila | mgz: So, the problem is two-fold (at least): 1) COLUMNS being an env variable it doesn't play well with subprocesses, 2) Whether COLUMNS is more or less right than the kernel is unclear (and when) | 11:10 |
| mgz | well, it clearly depends on the application, of which there are many :) | 11:10 |
| bialix | thumper: \o/ | 11:12 |
| vila | thumper: nice ! | 11:12 |
| * thumper puts down laptop for the night | 11:13 | |
| vila | mgz: the case at point is to find a recipe where COLUMNS and ioctl(1, termios.TIOCGWINSZ...) disagree and see which is right | 11:14 |
| lifeless | gnight | 11:14 |
| mgz | night! | 11:14 |
| vila | mgz: I swear I encountered one in the past but couldn't find it back, so the bets are open :) | 11:15 |
| vila | lifeless: gnight | 11:15 |
| bialix | why switch between qbzr trunk and qbzr 0.18 produce conflicts??? there is no uncommitted changes | 11:15 |
| bialix | this operation should not merge | 11:15 |
| bialix | why??? grrr | 11:15 |
| mgz | well, you and spiv covered pretty much all the possible options in that discussion | 11:15 |
| bialix | is it worth a bug report? | 11:15 |
| lifeless | bialix: dir with unversioned contents? | 11:16 |
| lifeless | I think there is a bug already | 11:16 |
| lifeless | and a workaround | 11:16 |
| lifeless | bzr resolve --take-other or something | 11:16 |
| bialix | no, conflict in the versioned file | 11:16 |
| lifeless | ah, please file a bug for that then | 11:16 |
| * lifeless really goes | 11:16 | |
| mgz | (re)finding real world cases seems reasonable | 11:16 |
| mgz | all this makes the windows terminal start to look sane, you know. | 11:17 |
| vila | bialix: ^ :-P | 11:17 |
| bialix | :-P | 11:18 |
| mgz | you know what I haven't made you worry about yet: knowing how wide what you're actually printing is | 11:19 |
| mgz | because an 80 codepoint string sure isn't always 80 spaces wide :D | 11:20 |
| === nlisgo_ is now known as nlisgo | ||
| vila | mgz: :) | 11:20 |
| vila | mgz: let's get the signal mess out of the way first :) | 11:21 |
| mgz | :D | 11:22 |
| mgz | I think bzr largely avoids the issue, no critical word wrapping code | 11:23 |
| mwhudson | ah, terminal hacking | 11:26 |
| * mwhudson remembers that | 11:27 | |
| vila | mgz: we thought about reusing the nice TeX implementation but the dependency was considered too much :) | 11:28 |
| mgz | hey parth, thanks for looking over my filelifetimes branch | 11:39 |
| mgz | (and yes, to your query from earlier) | 11:40 |
| vila | mgz: I read the mail so I didn't have the context, what is this ',,bogus-inv' thing ? | 11:40 |
| mgz | will you be sad if I say "notaclue"? | 11:41 |
| vila | yeah, terribly :-( | 11:41 |
| vila | ;) | 11:41 |
| vila | I suspect we never realize the consequences since it has never conflicted in real like... | 11:42 |
| mgz | I just use a file tracking script to detect file objects that didn't get closed, and then added a bunch of close calls :) | 11:42 |
| mgz | in a couple of places I actually considered the surrounding context, but not many | 11:42 |
| mgz | (you may well be right that just using a tempfile there would make more sense... but it'd still need closing! | 11:43 |
| mgz | ) | 11:43 |
| vila | certainly | 11:43 |
| mgz | parthm: that also answers your query about why I added comments saying "should use try/finally" rather than just doing it | 11:45 |
| mgz | reindenting a twenty lines of code I didn't really understand seemed a bad idea to address a problem no one using cpython encounters | 11:46 |
| parthm | mgz: makes sense :) | 11:48 |
| sili | is it possible to show the logs of a branch since it was branched? | 11:51 |
| vila | sili: 'bzr missing --mine-only ' ? | 11:53 |
| sili | aha. I think that will work. Thanks vila | 11:57 |
| Leonidas | is there any roadmap on when 2.1.2 will be released? | 12:20 |
| === mrevell is now known as mrevell-lunch | ||
| === mrevell-lunch is now known as mrevell | ||
| === nlisgo_ is now known as nlisgo | ||
| === nlisgo_ is now known as nlisgo | ||
| === nlisgo_ is now known as nlisgo | ||
| === nlisgo_ is now known as nlisgo | ||
| === IslandUsurper is now known as IslandUsurperAFK | ||
| === nlisgo_ is now known as nlisgo | ||
| === beuno is now known as beuno-lunch | ||
| === nlisgo_ is now known as nlisgo | ||
| awilkins | Is there a loggerhead of the bzr trunk? | 17:45 |
| jelmer | awilkins: yeah, lp:~bzr-pqm/bzr/bzr.dev | 17:48 |
| awilkins | jelmer, Thanks | 17:53 |
| === IslandUsurperAFK is now known as IslandUsurper | ||
| Phoenixz | I have two projects that share a large part (some 90%) of the same code base.. When adding functions / fixes to project 1 I want to share those with project two, but there are various directories from which I do not want to share changes.. How do I do this? | 18:17 |
| Phoenixz | share changes as in, when I merge / push to other repos, I want those directories filtered.. | 18:17 |
| rsvp | for some reason ".bzrignore" does not seem be excluding intended files -- where does it have to be placed? -- what are some gotchas??? | 18:28 |
| jelmer | rsvp: it has to be in the root of the tree | 18:30 |
| jelmer | rsvp: what sort of files is it not ignoring and when? | 18:30 |
| rsvp | I think I found the gotcha: "The ignore pattern only applies to non-added (ie unknown) files. Once a file is added, it remains versioned regardless of whether it matches an ignore pattern or not." -- can we can confirmation of this, please? -- it's not mentioned in the manual by the way. | 18:33 |
| rsvp | if so, how does one remove versioning but NOT the file itself ??? | 18:34 |
| jelmer | rsvp: yes, that's correct | 18:35 |
| jelmer | rsvp: iirc "bzr remove --keep NAME" | 18:35 |
| rsvp | what's iirc | 18:35 |
| rsvp | ? | 18:35 |
| jelmer | if I remember correctly | 18:37 |
| rsvp | ah, OK... thanks very much, jelmer | 18:38 |
| === beuno-lunch is now known as beuno | ||
| rsvp | it appears that the correct syntax is "bzr rm --keep NAME" -- per https://answers.launchpad.net/bzr/+question/28805 which uncovers our mystery. | 18:42 |
| jelmer | rsvp: that's what I said :-) | 18:42 |
| rsvp | jelmer, is rm bzr's shorthand for remove? | 18:43 |
| jelmer | rsvp: yep | 18:43 |
| rsvp | ok, superb, thanks again. | 18:43 |
| rsvp | using "bzr ignored" to verify which files will be ignored -- this has indeed confirmed our discussion. | 18:52 |
| C-S | I have the following error with 'bzr qlog': bzr: ERROR: exceptions.AttributeError: 'NoneType' object has no attribute 'style' | 19:19 |
| C-S | any ideas? | 19:19 |
| C-S | traceback is: Traceback (most recent call last): | 19:21 |
| C-S | File "/usr/local/lib/python2.6/site-packages/bzrlib/plugins/qbzr/lib/revtreeview.py", line 193, in paint | 19:21 |
| C-S | style = widget.style() | 19:21 |
| C-S | AttributeError: 'NoneType' object has no attribute 'style' | 19:21 |
| luks | I think that was fixed in new version sof qbzr | 19:24 |
| C-S | which version do you mean? | 19:28 |
| C-S | I use the newest published version of qbzr | 19:29 |
| luks | maybe I was wrong | 19:29 |
| C-S | maybe it is not published yet. | 19:29 |
| luks | which version do you have? | 19:30 |
| luks | according to the changelog, it was fixed in 0.18.5 | 19:31 |
| luks | https://bugs.launchpad.net/qbzr/+bug/544928 | 19:31 |
| ubot5 | Launchpad bug 544928 in QBzr 0.18 "qlog fails with a special combination of PyQt4 and Qt (affected: 19, heat: 0)" [Critical,Fix released] | 19:31 |
| C-S | bzr version 2.1.1 and I am working on 0.19 qbzr | 19:31 |
| C-S | that is weird indeed | 19:31 |
| C-S | actually I have 019~b1 | 19:32 |
| C-S | and still get this error? | 19:32 |
| luks | seems 0.18.5 was released after 0.19beta | 19:32 |
| luks | so the fix is probably not there | 19:32 |
| C-S | ah. maybe | 19:33 |
| C-S | let me check | 19:33 |
| C-S | you seem to be right. | 19:33 |
| C-S | luks: thank you very very much. it works now :-) | 19:38 |
| luks | no problem :) | 19:40 |
| === nlisgo_ is now known as nlisgo | ||
| === nlisgo_ is now known as nlisgo | ||
| rsvp | the command "bzr remove --keep" at first sight is ambiguous, and users may hestitate for the fear of losing their files; would recommend creating "bzr unversion" instead. Your thoughts ?? | 20:21 |
| poolie | rsvp, that would be a reasonable name for it | 20:21 |
| poolie | however remember that when this change is merged somewhere else, it actually will cause deletions | 20:22 |
| rsvp | poolie, deletion of the versions, or the actual files themselves? | 20:23 |
| poolie | the files themselves | 20:24 |
| poolie | we don't record "was unversioned" vs "was deleted" | 20:25 |
| rsvp | that might be a problem then... | 20:26 |
| rsvp | but then why the distinction from this another option: "bzr remove --force" ; so once again the means and the end results are not crystal clear to the user. | 20:31 |
| maxb | What is unclear? | 20:31 |
| maxb | I think "bzr unversion" would be unwise, because it implies there is more difference in the operation that there actually is | 20:32 |
| itistoday | how do I byte-compile the files in a plugin folder? | 20:36 |
| rsvp | I think what the typical user will want is to stop versions of a certain file, yet to have it remain on disk, without manually editing .bzrignore | 20:36 |
| rsvp | so "bzr unversion" will do just that, including adding an entry to .bzrignore automatically -- just a suggestion. | 20:38 |
| itistoday | i.e., I've done this: bzr get http://people.samba.org/bzr/jelmer/bzr-rewrite/trunk ~/.bazaar/plugins/rewrite | 20:38 |
| itistoday | normally when you run setup.py install it byte-compiles the stuff in there | 20:38 |
| itistoday | but it installs it into the system location | 20:38 |
| itistoday | i'd like to leave it there in my user folder, but byte-compile the files | 20:39 |
| poolie | itistoday, if you can write to the directory it will be automatically bytecompiled when you first use it | 20:45 |
| itistoday | poolie: ah neat, didn't know that | 20:45 |
| itistoday | thanks! | 20:45 |
| rsvp | so I just created two aliases in my bazaar.conf : "unversion = remove --keep" and "destroy = remove --force" | 20:50 |
| poolie | ok | 20:52 |
| rsvp | functionally more clear, no? | 20:52 |
| bamarob | Greetings... is this the place for a newbie to get some help? | 20:52 |
| poolie | sure | 20:54 |
| bamarob | Actually, as I posted that, I continued to read through https://answers.launchpad.net/bzr and *may* have found some answers... If not, I'll be back... :) Thanks. | 20:57 |
| === tchan1 is now known as tchan | ||
| awmcclain | Hi friendly bzr'ers. I've been updating bzr via easy_install for years and I just downloaded the DMG to get explorer... and now I'm getting a bzrlib version doesn't match error -- even though the bzrlib.__version__ matches the bzr version (2.1.0) | 21:39 |
| poolie | awmcclain, i'd guess you have an old bzr or bzrlib hanging around somewhere | 21:40 |
| lifeless | mkanat: hi | 21:52 |
| mkanat | Hey lifeless. | 21:52 |
| mkanat | lifeless: Did you find out if the pygments fix and the latest hang fix had actually been deployed? | 21:55 |
| lifeless | I found out how to find out | 21:55 |
| lifeless | and found out | 21:55 |
| lifeless | the way to find out is to look at lp:~launchpad-pqm/loggerhead/devel | 21:55 |
| mkanat | lifeless: Ahh, okay. :-) | 21:55 |
| lifeless | that branch is rolled out in cron | 21:55 |
| lifeless | at a 24 hour frequency | 21:56 |
| lifeless | it contains the pygments size cap | 21:56 |
| lifeless | so 'yes' to the pygments thing being rolled out | 21:56 |
| lifeless | did we file a bug on pygments about its 'most excellent scaling characteristics' ? :) | 21:57 |
| mkanat | lifeless: Hahaha. No, I don't think I did. | 21:57 |
| lifeless | I think we should | 21:57 |
| mkanat | lifeless: Yeah, agreed. | 21:57 |
| mkanat | Okay, and the rolled-out branch also contains the lru fix. | 21:57 |
| lifeless | for two reasons - the open source quid pro quo of feedback, and also so that when its fixed we can remove the size limit | 21:58 |
| mkanat | lifeless: BTW, I can't access that pastebin that's linked in the bug description. | 21:58 |
| lifeless | I can, let me grab it | 21:58 |
| mkanat | lifeless: I don't know that it will be resolved--the problem is that pygments is slow. "Make pygments fast" would be the solution. Perhaps via pyrex or something. | 21:58 |
| lifeless | right | 21:58 |
| lifeless | I understood it to be nonlinear though | 21:58 |
| mkanat | lifeless: I'll go find their bug tracker. | 21:58 |
| mkanat | lifeless: No, it's linear. It's just really bad. | 21:58 |
| lifeless | ok | 21:58 |
| mkanat | Oh lovely, they use Trac. | 21:59 |
| lifeless | no wonder they are patient on performance | 21:59 |
| mkanat | Hahaha. | 21:59 |
| === khmarbaise_ is now known as khmarbaise | ||
| lifeless | pasted to you | 22:03 |
| lifeless | it wasn't very large | 22:03 |
| mkanat | lifeless: Cool, thanks. | 22:04 |
| lifeless | so we have an internal process gap | 22:04 |
| mkanat | lifeless: Okay, so that looks like a similar problem to the pygments problem. I'm guessing Locations.xml.in is a large file. | 22:04 |
| lifeless | pull the branch, should be easy to check :) | 22:05 |
| mkanat | lifeless: Yeah, I will. | 22:05 |
| mkanat | lifeless: I'll do some testing, see what takes so long. | 22:05 |
| Phoenixz | How can I merge 2 branches but filter certain directories? I have two projects that share a large part (some 90%) of the same code base.. When adding functions / fixes to project 1 I want to share those with project two, but there are various directories from which I do not want to share changes.. How do I do this? | 22:05 |
| lifeless | Phoenixz: sounds like you have three project | 22:06 |
| lifeless | mkanat: anyhow | 22:06 |
| Phoenixz | lifeless: three projects? | 22:07 |
| lifeless | mkanat: all the hangs we're seeing - peaking at 1/hour - were getting internally logged on the pygments bug, in may | 22:07 |
| lifeless | Phoenixz: common code, proj 1, proj 2 | 22:07 |
| Phoenixz | well, I have multiple projects, yes, but for the ease of it, I limited it to two.. | 22:07 |
| Phoenixz | lifeless: pretty much that yeah, common, prj 1, prj2, prjn... | 22:07 |
| lifeless | mkanat: I'm learning about how they get assigned and so on now, so that we can try to get better communication to you | 22:07 |
| Phoenixz | lifeless: so how could I merge in between these projects but filtering out a few directories so that I will not have those changes intermix? | 22:08 |
| lifeless | Phoenixz: the easiest way is not to filter stuff out | 22:08 |
| lifeless | but to have the common code as a source project | 22:08 |
| lifeless | that you merge - completely - into both proj1 and proj2 | 22:08 |
| mkanat | lifeless: Okay, awesome. | 22:10 |
| mkanat | lifeless: Only hangs after May 10 are significant, though, because that's when the system was updated. | 22:10 |
| lifeless | you're sure ? Looked like the merge was 24th april to me | 22:11 |
| lifeless | http://bazaar.launchpad.net/~launchpad-pqm/loggerhead/devel/revision/175 | 22:11 |
| mkanat | lifeless: https://bazaar.launchpad.net/~launchpad-pqm/loggerhead/devel/changes | 22:11 |
| mkanat | lifeless: It's revision 177 that matters. | 22:11 |
| lifeless | ah, for both the pygments fix and the hang bug | 22:12 |
| mkanat | Yeah. | 22:12 |
| Phoenixz | lifeless: meaning, I should make framework edits ONLY in the codebase, not in prj1, prj2, etc so that I never have to merge back, right? | 22:12 |
| lifeless | Phoenixz: yes | 22:12 |
| lifeless | mkanat: right, I see | 22:13 |
| Phoenixz | lifeless: problem is.. on various occasions its much easier to make those changes directly in the projects.. Like, I find a bug in the codebase while working on prj1, I fix it there, test it, its okay, etc.. then merge back to codebase... | 22:13 |
| lifeless | Phoenixz: so, make it where you want to; shelve the other changes, bzr switch to the framework, commit, bzr switch back, merge from the framework and you have your fix ready | 22:14 |
| Phoenixz | Having to make changes only in codebase... would make it hard to test.. find bug in codebase while working on prj1, fix in codebase, commit, push, merge, pull into prj1, test, shit, forgot detail X, do it all again.. | 22:14 |
| lifeless | well you're going to need tests for the framework anyway | 22:14 |
| mkanat | lifeless: You actually have stats that say that the machine starts to swap during that hang and other similar hangs? | 22:15 |
| lifeless | spm: are you perhaps up, in ye place of monsoon ? | 22:16 |
| Phoenixz | lifeless: shelve.. seen that option, haven't used it yet.. Gotta do some reading on it first then.. | 22:16 |
| Phoenixz | shelve is like.. temporarily storing the changes you currently have so that you can work on somehting else, commit that, and return to the changes you had before? | 22:16 |
| lifeless | yes | 22:17 |
| Phoenixz | sweet | 22:17 |
| Phoenixz | BZR rocks.. :P | 22:17 |
| jpds | It sure does! | 22:17 |
| Phoenixz | lifeless: anyway.. still there are some problems.. So I find a bug, I shelve, switch, fix... But there are functions that only really show when used in projects.. | 22:18 |
| Phoenixz | lifeless: I don't suppose its possible to filter directories on merges? | 22:18 |
| lifeless | it is, but with various sideeffects you may not like | 22:19 |
| Phoenixz | lifeless: like? | 22:19 |
| lifeless | depending on how you do it - including only some, or excluding ones you don't like after the merge. | 22:19 |
| Phoenixz | Nobody likes sideeffects, but sometimes it may be worth it.. | 22:19 |
| lifeless | If you include only some, there's no record of whats merged, and you'll have unneeded conflicts. | 22:19 |
| lifeless | if you exclude ones you didn't want after the merge, you'll have both proj1 and proj2 in your history. | 22:20 |
| lifeless | bzr, just like git and hg, is a *full tree* vcs, so it records things in terms of trees, not individual files. | 22:20 |
| Phoenixz | lifeless: basically, I have separated directories for programs, libraries, configuration, etc.. all I want is to merge the library directories.. | 22:20 |
| lifeless | sure | 22:20 |
| Phoenixz | lifeless: so what would options be? | 22:21 |
| lifeless | I've outlined them all now | 22:21 |
| lifeless | my recommended one is to have a dedicated libraries project. | 22:21 |
| Phoenixz | ah, sorry, thought there was another one | 22:21 |
| gdoubleu | I've got a branch of a svn repo (let's call it trunk), and then a feature branch from that. Now, I want to get my changes from the feature branch into the svn repo, while preserving the individual commits. | 22:22 |
| gdoubleu | As I understand things, a push to trunk is needed (instead of merge) so that the individual changes are reflected instead of one large merge commit | 22:23 |
| gdoubleu | Problem is, what if my feature branch has been long-running and I've already done a few merges from trunk along the way? | 22:23 |
| lifeless | gdoubleu: dpush is what you want, AIUI | 22:23 |
| gdoubleu | dpush directly from the feature branch? | 22:24 |
| Phoenixz | lifeless: shelve does not store changes in between a switch, I suppose? | 22:25 |
| lifeless | Phoenixz: the changes are stored in the tree, so yes it does store them | 22:25 |
| gdoubleu | I've normally merged completed features back to trunk and then dpush from there. In that case only one commit gets pushed to the svn repo, the merge commit. | 22:25 |
| gdoubleu | In this case I would like to push all of the individual commits and not just the merge commit. | 22:26 |
| lifeless | sure | 22:26 |
| lifeless | my understanding is that dpush is the tool for that | 22:26 |
| Phoenixz | lifeless: because then I could make the changes in project1, test them, if all is ok, shelve, switch, unshelve, commit.. no? | 22:26 |
| gdoubleu | lifeless, trying to dpush from the feature branch straight to the svn repo complains that it would change mainline history | 22:28 |
| gdoubleu | I'm assuming this is because along the way in my feature branch, I've merged in updates from trunk | 22:29 |
| gdoubleu | Any ideas as to how I could clean those merge commits out of the feature branch so it's clean and doesn't change mainline history when trying to push back to the svn repo? | 22:31 |
| lifeless | mkanat: so on the 20th it was using too much swap and the losas restarted it | 22:54 |
| mkanat | lifeless: Okay. And it was also using a lot of threads at that time? | 22:54 |
| mkanat | lifeless: I want to make sure that there's not just one runaway thread using a ton of memory. | 22:55 |
| lifeless | can't tell | 22:56 |
| lifeless | there isn't a dump attached, its just a simple text log file | 22:56 |
| lifeless | saying date, fault description, qa info | 22:56 |
| mkanat | lifeless: Okay. Are there still logs around from that time? | 22:57 |
| mkanat | lifeless: mwhudson or spm should be able to get them. | 22:57 |
| lifeless | mwhudson: ^ | 22:57 |
| lifeless | 2010-05-20 12:10 UTC | 22:57 |
| mkanat | lifeless: I have a crazy codebrowse log analyzer that I can use to see what was going on. | 22:57 |
| mwhudson | mkanat: could that be adapted to something that could grab logs for a particular time range? | 22:59 |
| mwhudson | it's a horribly manual process for me at the moment | 22:59 |
| mkanat | mwhudson: I don't know--I don't know how the logs are stored, or what you do to grab them. | 22:59 |
| mkanat | mwhudson: If you just want to send me the whole log, I can break it down. | 23:00 |
| mkanat | lifeless: Okay, yes, Locations.xml.in is 1.5MB. | 23:01 |
| lifeless | mwhudson: are there docs on getting the logs at the moment, or is it black magic? | 23:02 |
| mwhudson | lifeless: it's not exactly black magic, it's just grotty | 23:03 |
| mwhudson | and no docs | 23:03 |
| mkanat | lifeless: Okay, also, loading that file causes a TREMENDOUS MEMORY LEAK. | 23:03 |
| mkanat | We leak almost 100MB every time that file is loaded. | 23:04 |
| lifeless | \o/ | 23:04 |
| lifeless | poolie: ^ see what I mean | 23:05 |
| poolie | yay max | 23:06 |
| mkanat | Hahaha, thanks poolie. :-) | 23:06 |
| mkanat | Maybe it's time to learn how to use meliae. :-) | 23:09 |
| lifeless | its pretty nice | 23:09 |
| poolie | jam, hi? | 23:09 |
| poolie | mkanat, i filed a bug asking that we should dump memory usage when we get eg SIGUSR1 | 23:10 |
| poolie | you might like to implement that ;-) | 23:10 |
| poolie | oh and there's another asking for a memory dump when we run out of memory | 23:10 |
| mkanat | poolie: :-D | 23:10 |
| poolie | if we had the latter and we put a ulimit on loggerhead, we'd potentially get useful data semi automaticalyl | 23:10 |
| lifeless | poolie: that latter one wouldn't help loggerhead so much ... machine has lots of swap configured | 23:10 |
| mwhudson | mkanat: http://people.canonical.com/~mwh/debug.log.2-sub.gz <- logs from around 2010-05-20 12:10 UTC | 23:10 |
| lifeless | ah yes | 23:10 |
| lifeless | ulimit ftw | 23:10 |
| mkanat | mwhudson: Thank you! :-) | 23:10 |
| mkanat | poolie: Well, lemme figure out meliae, first. :-) | 23:11 |
| poolie | lifeless, in other words "a credit card limit is not a challenge" | 23:11 |
| poolie | we can spend less :) | 23:11 |
| lifeless | what, sensible home accounts? nooo | 23:15 |
| mkanat | Is there any actual documentation on how to use meliae? | 23:18 |
| lifeless | yes | 23:19 |
| lifeless | http://jam-bazaar.blogspot.com/2009/11/memory-debugging-with-meliae.html | 23:20 |
| mkanat | lifeless: Thanks. | 23:20 |
| lifeless | jam: ow, zing | 23:30 |
| mkanat | jam: python: Objects/typeobject.c:2672: type_traverse: Assertion `type->tp_flags & (1L<<9)' failed. | 23:40 |
| mkanat | Aborted (core dumped) | 23:40 |
| lifeless | rotfl | 23:40 |
| lifeless | its never easy | 23:40 |
| mkanat | jam: I got that using meliae on loggerhead. | 23:40 |
| mkanat | I'll try meliae trunk. | 23:41 |
| mkanat | Yeah, same assertion and core dump. | 23:42 |
| mkanat | I'll file a bug with the core attached, if it's not too huge. | 23:43 |
| lifeless | does loggerhead have custom types in use | 23:50 |
| lifeless | special ones I mean, not the bzr stock ones | 23:50 |
| mkanat | lifeless: Not sure. | 23:57 |
| mwhudson | no c ones | 23:57 |
| mwhudson | i guess maybe it's something from sqlite? | 23:58 |
| lifeless | it has the ctype stuff for killing threads | 23:58 |
| mkanat | I'm still trying to get enough debuginfo packages installed to get a reasonable backtrace from the core. | 23:58 |
| mwhudson | mkanat: use this: https://code.edge.launchpad.net/~pygdb-hackers/pygdb/trunk | 23:59 |
| lifeless | if you're on ubuntu, apport-retrace can grab them for you, I think. | 23:59 |
| mkanat | lifeless: I'm on Fedora. | 23:59 |
| lifeless | oh, sorry :) | 23:59 |
| mkanat | lifeless: Hahaha. :-) | 23:59 |
| mkanat | mwhudson: Awesome, thank you. | 23:59 |
| mwhudson | mkanat: are you on 64 bit? | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!