[00:00] 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] ah, with bzrlib you surely can resume properly [00:00] hi beuno, all [00:00] if that's what your previous question was about [00:00] I was referring to jsut using the cli [00:01] hey hey poolie! [00:02] 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:03] jbowtie, I'd suggest emailing the list about this [00:03] or getting poolie's attention ;) [00:03] jbowtie, that'that sounds great [00:04] jbowtie, so just at a guess you need to make sure the fetch finishes before updating the branch pointer [00:04] ah, and perhaps check that you've released the write lock on the repository too [00:04] which should serve to flush out pending state [00:04] hth [00:04] spiv, are you here? [00:05] Good morning! [00:05] hey there, isn't it impressively damp in sydney today [00:07] poolie: Well, if an exception gets thrown that's what should be happening. [00:08] 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:09] poolie: So when I lose the connection in the middle of building a revision, I expect the repository is in a consistent state. [00:10] poolie: But no branch is created since the repository hasn't finished populating yet. [00:10] poolie: So I'm sitting there with a partially populated repository, no branch, no working copy. [00:11] poolie: I'm just not sure how I'm supposed to resume from the command line, or if that's even possible. [00:12] you should be able to just branch again into the same repository? [00:12] poolie, but only if he has a shared repo [00:13] poolie: I get an error about the directory already existing. [00:13] not sure if --use-existing helps there or not [00:13] ah ok, so the half-created branch is getting in the way? [00:13] there's a bug open for this [00:13] for now unfortunately you have to just delete it [00:14] poolie: I expect so, yes. [00:14] poolie: That's what I've been doing. [00:14] poolie: I was just hoping there was a better way, TFS is so slooooooow. [00:15] poolie: Branching 1000 revisions is an overnight job. [00:16] Is there a way via bzrlib to get rid of the half-created branch and resume fetching the revisions into the repository? [00:16] poolie: Do you know the bug number? [00:18] jbowtie, from bzrlib, resuming should be easy-ish [00:19] that said, I'm going afk to walk the dog and dinner with the inlaws :) [00:20] beuno: It's morning for me, so I'll still be here if you want to illuminate me later. [00:20] Will anything break if I have a bzrdir that has neither repository, branch nor checkout? [00:23] ah, bzr-colo does it already [00:34] jbowtie, it's something like https://bugs.edge.launchpad.net/bzr/+bug/125067 or bug 116148 [00:34] 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] Launchpad bug 125067 in Bazaar "allow 'bzr checkout' to resume (affected: 1, heat: 14)" [Wishlist,Confirmed] [01:21] jam: had fun ? [01:50] How do I enable colors in bzr diff's output? [01:51] zerd, consider bzr cdiff; you may need bzrtools installed [01:57] ah. nice. [01:58] Is it any way to automatically use a pager (less) to paginate long output? [01:59] * nDuff doesn't know. [02:00] There's a bzr-pager plugin, not sure how up to date it is. [02:04] hmm.. cdiff didn't act nice with less [02:07] zerd, less -r [02:32] poolie: I propose we give mgz landing rights [02:40] +1 [03:29] * igc lunch === retupmoca` is now known as retupmoca [04:35] mgz: ping ... gz .. is that you. the irc denizen formerly known as a[0-9]+ :) [04:41] Argh! TFS says a label can't be more than 64 characters! [04:41] That means I have no way to store a bzr-revid for roundtripping of commits. [04:46] maybe you can stash it in a hidden file in the branch === jamesh_ is now known as jamesh [04:54] poolie: Sorry, I'm being dense, how would that work? [04:58] jbowtie, is this pullying from tfs into bzr, or vice versa, or both? [05:01] poolie: This was pushing a commit from bzr into tfs, then pulling back to bzr. [05:02] 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:03] 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:05] A little uglier than I would like but it's pretty foolproof as far as round-tripping goes. [05:05] I'll just need to create an actual foreign VCS mapping class (which I'd managed to avoid to date). [07:14] 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:15] hi all, oops, first things first [07:15] vila: Sure [07:16] vila: I imagine if it works in emacs then it's probably close enough ;) [07:17] spiv: that's the point, look at 4747.4.3 [07:18] vila: ah, and I see there's a test in test_osutils that that patch will trip up on. [07:19] spiv: haaaaa, I'm so glad about this :) [07:19] spiv: comment sent, basically COLUMNS *can* differ from _terminal_size and be right [07:20] I was wondering where relevant tests were; I did run some blackbox tests as a smoke test. [07:20] But running the full suite just takes too long for me now :( [07:20] apart from the emacs case, I think resizing a window so that a scrollbar appears may be another one [07:20] and then there is.... let me find that bash setting [07:21] checkwinsize [07:21] spiv: try to play a bit with 'checkwinsize' ... you'll live interesting times [07:22] I'll do that. [07:22] spiv: I'd like to fix the test suite [07:22] but thats another story [07:22] There is definitely something screwy about the code as it is in 2.1 today, though. [07:22] lifeless: me too! [07:23] spiv: apart from the EINTR fallouts you mean ? [07:23] Because the SIGWINCH handler will happily reset os.environ['COLUMNS'] [07:23] Using the value from _terminal_size [07:23] spiv: see comment, that's a shortcut [07:24] spiv: once you respect COLUMNS, you should continue :) [07:24] spiv: even by tricking yourself :) [07:24] holy cow [07:24] tripit is good [07:24] it combined two separate bookings into one trip [07:24] poolie: ^ :) [07:25] vila: which comment? [07:25] vila: the code + comments as they are at the moment don't make sense to me [07:25] 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] spiv: I was referring to the mp comment [07:26] spiv: don't make sense doesn't mean incorrect :) [07:26] the root is that COLUMNS and _terminal_size can disagree, the rest follows from that [07:27] vila: well, I changed the comment to match the change to the code, not because I disagreed :) [07:27] spiv: but you didn't change the docstring ! :-p [07:27] Yes, but what precisely should happen when they disagree? [07:27] vila: well, I'm not perfect :) [07:27] no worries, just kidding [07:28] spiv: good question, the actual answer was giving me a correct behavior in all configs I tried [07:28] so [07:29] At the moment the policy *seems* to be "trust $COLUMNS until SIGWINCH happens (then trust _terminal_size)" [07:29] what happens if we just revert everything [07:29] what would break [07:29] spiv: yup [07:29] Which doesn't seem to make much sense to me, because if we can trust _terminal_size after SIGWINCH, why not before? [07:29] spiv: because there are known cases where it's wrong, try 'checkwinsize' [07:30] spiv: that's what I try to explain in the mp comment [07:30] (My sigwinch-without-signalmodule-583941 can preserve that behaviour without causing EINTR) [07:31] * spiv looks at checkwinsize [07:31] spiv: ECONTEXT, why the new proposal then ? [07:31] Because that proposal added a new C module [07:31] lifeless: I'm pretty sure we will end up with terminal_width defaulting to None instead of 80 before the patchES [07:32] i.e. blowing up buildbot with flog files full of spaces or something [07:32] hehe, yeah flog [07:32] checkwinsize means bash promises that COLUMNS will be up-to-date when it invokes bzr, AIUI? [07:32] spiv: yes [07:32] So _terminal_size would == $COLUMNS, then? [07:33] spiv: no [07:33] that's the point [07:33] COLUMNS can be set by the application controlling the terminal [07:34] think scrollbars, split (sp?) screens, etc [07:34] Which is bash, if we're talking about checkwinsize [07:35] 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] So here's what I don't understand. [07:36] I think perhaps you are talking about emacs-running-bash-running-bzr? [07:36] Or, actually, that doesn't matter. [07:37] no, doesn't matter, yes that's my *daily* env === nlisgo_ is now known as nlisgo [07:38] spiv: http://www.ohse.de/uwe/software/resize.c.html for some background (but note that he doesn't respect COLUMNS knowingly) [07:38] 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] spiv: roughly yes, [07:39] after SIGWINCH, it's not "better" but... the best we have IMHO [07:40] hi vila [07:40] Because we know that the size must have changed, and _terminal_size is the only thing that indicates how? [07:40] poolie: hey ! [07:40] spiv i can't remember if i voted but i like the approach much better [07:40] So, if that's the case: [07:40] spiv: ... did I make a such poor job to explain myself in that mp's comment or what ? :) [07:41] 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] spiv: sure [07:41] spiv: my point was to respect COLUMNS at the first try [07:42] 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] 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:43] vila: _terminal_size takes 11 microseconds on my slowish laptop. [07:43] cool [07:44] Can you give me a precise recipe to observe COLUMNS being more accurate than _terminal_size? [07:45] Ha, the tricky one :-/ [07:45] not from memory but I can try to find it back === nlisgo_ is now known as nlisgo [07:55] spiv: http://www.zsh.org/mla/workers/1999/msg01597.html seem to contain an analysis of various softwares behaviors [07:57] 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 [08:00] spiv: hehe, see http://old.nabble.com/Unable-to-see-os.environ-%27COLUMNS%27--td19487200.html for additional fun :) [08:02] 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:03] 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] But you've had trouble yourself? [08:04] yes, emacs + bash + bzr [08:05] but the discussion about zsh is very close to the one we're having here [08:06] 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:07] 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:08] The zsh discussion was mainly about when to update and when to export the shell-internal COLUMNS/LINES values. [08:09] spiv: but mentions that COLUMNS should be respected at start [08:09] spiv: the fact that I can't find a recipe shouldn't invalidate the fact that many people refer implicitly to such recipes :) [08:10] vila: the perl link has comment that doesn't match the code! [08:11] spiv: really ? It calls TICOCGWINSZ and *then* overrides with COLUMNS is set, what doesn't match ? [08:12] s/is set/if set/ [08:12] 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] So it's very unclear to me whether it does that by accident or on purpose. [08:13] 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:14] It's entirely possible there's a solid justification for it, but no-one seems to know what it is :) [08:14] spiv: and based on that you're going to consider that it's false ? [08:14] Well, "lots of other people do it" is an argument for us doing it too. [08:15] 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] apart from the emacs one I'm sure I encountered another one but I can't remember what was involved [08:16] * StevenK grumbles. bzr add-pipe died with a NoneType has no attribute get_config [08:16] StevenK: upgrade your bzr [08:16] some terminal emulator or even vim or less or... [08:16] vila: tell me more about the emacs case. This is emacs running in a terminal, not in its own GUI window? [08:17] own GUI window, shell as a subprocess [08:18] Huh, so why isn't the TIOCGWINSZ going to be correct in a tty emacs created? emacs bug? [08:20] spiv: But 2.1.2 isn't out yet? :-) [08:20] spiv: TIOCGWINSZ when WINCH is more correct because emacs can't change the bash env variable when the window is resized [08:22] hi vila [08:22] vila: right, but TIOCGWINSZ should also be totally correct before WINCH too [08:23] vila: i.e. in that situation it seems to me the best thing to do would be to ignore COLUMNS entirely [08:23] 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] vila: ooh, tell me more! [08:23] 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:24] 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] StevenK: you're on the lp team now, add the bzr ppa :) [08:25] spiv: start bzr log, resize window, osutils.terminal_width() got the good value [08:25] StevenK: and no, not the releases one. The *other* one :P [08:25] vila: ah, a recipe, thanks! Time to dust of my memory of emacs... [08:26] lifeless: There's another one? :-) [08:26] nightlies [08:27] 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] lifeless: Which team does that one hide under, since it isn't ~bzr? [08:28] statik, I think [08:28] hey, use the vaunted ppa search [08:28] or look on our downloads page ;) [08:28] spiv: the value set when the bash subprocess was started, and my recipe is wrong because SIGWINCH is not propagated anyway :( [08:28] wiki page I mean [08:28] vila: so perhaps its 'emacs is broken, gnar gnar gnar ? [08:29] spiv: no wait [08:29] lifeless: :) [08:30] grr, what was the application that was able to split the screen damnit, I didn't mention it out of thin air.... [08:30] screen? [08:30] terminator? [08:30] maybe, I used neither of them :( [08:30] or its new version, hate [08:30] Ng: ^ :P [08:32] lifeless: I find it odd that the nightly-ppa hasn't been updated in two months [08:32] haha [08:32] statik: ^ [08:32] ok, I give, run trunk. [08:34] igc: would love it if you could start setting commit messages in your merge proposals [08:34] lifeless: ah - ok. Will do [08:35] also [08:36] 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] when you send something to pqm please say so on the mp [08:36] so that I don't double submit :) [08:36] hydrazine will do this for you [08:37] ok [08:38] 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] igc: the result of automation: - http://pqm.bazaar-vcs.org/ [08:39] lifeless: nice [08:40] spiv: this is equally superstitious about TIOCGWINSZ returning wrong values and COLUMNS being right in that case [08:40] vila: (to be more precise, COLUMNS is accurate when emacs starts the M-x shell, and the termios size is never set) [08:41] spiv: and where is the recipe for termios size never set ? :-P [08:42] vila: I don't think it's particularly superstitious. [08:44] 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] 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:45] Then fallback to COLUMNS, which if set is likely to be better than nothing, then fallback to 80 as the default everyone expects. [08:46] spiv: yeah, I did that *first* and then I switched [08:46] but don't force 80 either, some callers expect None for no defined width [08:47] Ah, sure. [08:47] Why did you switch? [08:47] shudder [08:48] * igc dinner [08:48] because I encountered a case where it was needed, found some evidence for it reading the web and... [08:48] fail to note the recipe (I should have known better :) [08:48] :) [08:49] Perhaps we should just let users with broken terminals write a plugin to override osutils.terminal_width as they need :P [08:49] now, did I reproduce it or was I so convinced by some explanation that I didn't reproduce it in fact ? [08:49] spiv: That's why I added BZR_COLUMNS: this terminal size stuff is messy, let's punt [08:49] :) [08:50] vila: you should have made it be a python expression, for maximum flexibility ;) [08:51] spiv: see, you use emacs for a minute and already you're starting to put hooks everywhere :-) [08:52] vila: don't worry, my evil overload laugh was well-honed already ;) [08:53] spiv: bzr selftest -v | less :-( [09:02] 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:04] ~~~~ [09:13] Hi, I get two strange messages when comitting to my branch: Unrecognized interpretation: SOURCE_CODE, Unrecognized manifestation: FILE_DATA_OBJECT [09:13] What do they mean? [09:16] could use a second reviewer on https://code.launchpad.net/~parthm/bzr/584650-incorrect-alias-info-in-help/+merge/26018 [09:16] poolie: ^ if you're around, its trivial [09:16] ok maybe very quickly [09:16] then i need to go [09:16] bzrlib.help.help the comedian's a bear! [09:17] done [09:17] thanks lotzman [09:17] and good night === radoe_ is now known as radoe === nlisgo_ is now known as nlisgo === nlisgo_ is now known as nlisgo [10:25] gmorning! [10:26] Is there any way to "rewrite" some old commit messages (due to character encoding change)? [10:33] only if you're ok to the fact all your history after that commit will be rewritten too. [10:33] GaryvdM: ping [10:37] how come I can't modify the author name and/or message of a single commit? [10:37] oh man, lots of exciting log to read this morning [10:38] 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] the sad thing is... I should be being sarcastic, but am not. [10:38] vila: yeah, "bzr ... | less" or even just "| cat" is basically doomed as far as I can tell [10:39] vila: at least in my environment, in that situation COLUMNS is not set and _ioctl_terminal_size returns None,None [10:40] speakman: because DVCS insist on the immutability of the history [10:40] 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] bialix: Yes I know, but in this case it doesn't matter. [10:40] (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:41] speakman: if you change past commit, all commits after it should be changed too (at least their revids) [10:41] vila: right. So I'm thinking I'll make two patches: [10:41] bialix: is the revid connected to the author/commit message? [10:41] 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:42] 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] ack! if y'all keep talking, I'll never catch up [10:42] revid is revision id. it's unique [10:42] 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] yes, revid based on the author, commit message and all previous history [10:43] bialix: I can't possibly retain revid when changing message/committer? [10:44] 1) adding the comment I forgot about why COLUMNS is mutated this way, yes, sounds good, minimal risk for 2.1 [10:44] 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] speakman: you should not [10:44] vila: Well, I can't add that comment, because I still don't know why it is mutated [10:44] spiv: yup, behavior change for 2.2 , sounds good too [10:45] spiv: because it masks the ioctl call() [10:45] 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:46] spiv: good, we want subprocesses to inherit the most current value :-) [10:46] Oh, so that part was intentional? Ok, that was totally unclear to me :) [10:47] 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] since it [10:47] meh [10:47] 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:48] 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] (To be clear, I'm not sure that it is a bad idea to set either) [10:49] Nothing in bzrlib/ looks at COLUMNS other than osutils [10:49] 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:50] spiv: well, at least we got that right: a single place where term size is determined :) [10:50] Yeah, that was a great relief to see :) [10:50] but as the discussion with bialix at UDS revealed, the definition of what we do with that is still a bit unclear [10:51] 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] spiv: but you're free to ignore this bit for your current submission :-O [10:52] spiv: bzrlib.status.show_pending_merge() for one :-/ [10:52] vila: what? [10:53] 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:54] yep [10:55] 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:56] vila: you broke this in selftest :-P [10:56] vila: ugh, yes, I fully intend to ignore that :P [10:57] vila: thanks for your patience [10:57] * spiv -> dinner [10:57] * bialix -> lunch [10:57] (Someone should have breakfast to complete the set... any takers?) [10:58] I've just had breakfast [10:58] here we are... [10:58] well, s/just/one-and-a-half-hours ago [10:58] too late, now we know [10:59] :-) [10:59] spiv: you're welcome, I should have discussed this when I was working on it... [11:00] okay, caught up. think I understand all of that. [11:00] but, well, it sounds so inocuous :) [11:00] mgz: not sure we do :P [11:00] mgz: Do you have recipes ? :-P [11:04] 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:05] if COLUMNS is valid, and kernel width is valid, but they differ, use COLUMNS [11:06] (keeping BZR_COLUMNS overriding both of those, of course) [11:07] given the huge number of different setup possibilities, never going to get this right for everything [11:10] bzr backed wiki: 0.1 now out the door: http://how-bazaar.blogspot.com/2010/05/wikkid-wiki.html [11:10] 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] well, it clearly depends on the application, of which there are many :) [11:12] thumper: \o/ [11:12] thumper: nice ! [11:13] * thumper puts down laptop for the night [11:14] 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] gnight [11:14] night! [11:15] mgz: I swear I encountered one in the past but couldn't find it back, so the bets are open :) [11:15] lifeless: gnight [11:15] why switch between qbzr trunk and qbzr 0.18 produce conflicts??? there is no uncommitted changes [11:15] this operation should not merge [11:15] why??? grrr [11:15] well, you and spiv covered pretty much all the possible options in that discussion [11:15] is it worth a bug report? [11:16] bialix: dir with unversioned contents? [11:16] I think there is a bug already [11:16] and a workaround [11:16] bzr resolve --take-other or something [11:16] no, conflict in the versioned file [11:16] ah, please file a bug for that then [11:16] * lifeless really goes [11:16] (re)finding real world cases seems reasonable [11:17] all this makes the windows terminal start to look sane, you know. [11:17] bialix: ^ :-P [11:18] :-P [11:19] you know what I haven't made you worry about yet: knowing how wide what you're actually printing is [11:20] because an 80 codepoint string sure isn't always 80 spaces wide :D === nlisgo_ is now known as nlisgo [11:20] mgz: :) [11:21] mgz: let's get the signal mess out of the way first :) [11:22] :D [11:23] I think bzr largely avoids the issue, no critical word wrapping code [11:26] ah, terminal hacking [11:27] * mwhudson remembers that [11:28] mgz: we thought about reusing the nice TeX implementation but the dependency was considered too much :) [11:39] hey parth, thanks for looking over my filelifetimes branch [11:40] (and yes, to your query from earlier) [11:40] mgz: I read the mail so I didn't have the context, what is this ',,bogus-inv' thing ? [11:41] will you be sad if I say "notaclue"? [11:41] yeah, terribly :-( [11:41] ;) [11:42] I suspect we never realize the consequences since it has never conflicted in real like... [11:42] 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] in a couple of places I actually considered the surrounding context, but not many [11:43] (you may well be right that just using a tempfile there would make more sense... but it'd still need closing! [11:43] ) [11:43] certainly [11:45] parthm: that also answers your query about why I added comments saying "should use try/finally" rather than just doing it [11:46] 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:48] mgz: makes sense :) [11:51] is it possible to show the logs of a branch since it was branched? [11:53] sili: 'bzr missing --mine-only ' ? [11:57] aha. I think that will work. Thanks vila [12:20] is there any roadmap on when 2.1.2 will be released? === 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 [17:45] Is there a loggerhead of the bzr trunk? [17:48] awilkins: yeah, lp:~bzr-pqm/bzr/bzr.dev [17:53] jelmer, Thanks === IslandUsurperAFK is now known as IslandUsurper [18:17] 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] share changes as in, when I merge / push to other repos, I want those directories filtered.. [18:28] for some reason ".bzrignore" does not seem be excluding intended files -- where does it have to be placed? -- what are some gotchas??? [18:30] rsvp: it has to be in the root of the tree [18:30] rsvp: what sort of files is it not ignoring and when? [18:33] 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:34] if so, how does one remove versioning but NOT the file itself ??? [18:35] rsvp: yes, that's correct [18:35] rsvp: iirc "bzr remove --keep NAME" [18:35] what's iirc [18:35] ? [18:37] if I remember correctly [18:38] ah, OK... thanks very much, jelmer === beuno-lunch is now known as beuno [18:42]