| thomi | I'm sure I'm missinbg something really obvious, but how do I switch branches with the colo plugin? | 04:21 |
|---|---|---|
| thumper | thomi: switch | 04:23 |
| thumper | just a wild stab in the dark | 04:23 |
| thomi | oh, well that was obvious | 04:25 |
| thomi | I was expecting a colo-something command | 04:25 |
| bob2 | it's le pluggable | 05:03 |
| === gthorslund is now known as gthorslund_ | ||
| === gthorslund_ is now known as gthorslund | ||
| lifeless | over-usability, when things just work that you would not expect to do so | 05:24 |
| fullermd | Boy, if I had a nickel for every time people have said that about my software... | 05:31 |
| fullermd | I don't even know what I'd do. What CAN you buy for two bits nowadays? | 05:32 |
| lifeless | fullermd: a nickel display cabinet | 05:37 |
| bob2 | one one thousandth of a nickel display cabinet | 05:38 |
| fullermd | So, if we band together, and find 997 like-minded people, we can have an awesome unveiling party! | 05:38 |
| bob2 | velvet curtain will cost extra | 05:39 |
| mgz | morning all! | 08:00 |
| vila | hey mgz et al. ;) | 08:53 |
| mgz | how goes vila? | 09:02 |
| vila | knee-deep in setting up a local launchpad ;) | 09:02 |
| vila | catching up, I agree we should release a 2.5.1 (and merge up the delta too) | 09:03 |
| quicksilver | is there any way to see the extra diff in a merge? | 09:26 |
| quicksilver | I mean, the diff between what you would get by doing a straight merge, and what actually got committed | 09:26 |
| mgz | not easily | 09:31 |
| mgz | there's a plugin lifeless has pointed me at least twice called... | 09:31 |
| mgz | lp:difftacular | 09:32 |
| mgz | that can do that kind of thing. | 09:32 |
| quicksilver | strikes me as a failing | 09:33 |
| quicksilver | sometimes you really want it. | 09:33 |
| mgz | patches welcome. | 09:33 |
| quicksilver | no doubt | 09:33 |
| quicksilver | I hope it's still permitted to discuss the bzr feature set here without being asked for a patch on each point. | 09:34 |
| quicksilver | difftacular looks interesting. | 09:34 |
| mgz | it's such a nice answer when explaining the underlying complexities would be too much effort though :) | 09:34 |
| quicksilver | one could look at the merge-preview diff from the rev before, and the merge-preview diff from that rev | 09:35 |
| quicksilver | I wonder if anyone has considered a tool to sensibly compare two diffs | 09:35 |
| fullermd | There's probably an emacs mode for it. I think it's under ctrl-meta-hyper-sasquatch. | 09:37 |
| quicksilver | ;) | 09:38 |
| quicksilver | well one natural way to compare to diffs is just to actually apply them to the tree (in a scratch branch) | 09:38 |
| quicksilver | and then compare the resulting trees | 09:39 |
| fullermd | Anyway, as far as bzr is concerned there is no post-facto "extra diff". You'd have to basically redo the merge (and hope it came out the same way, which you have no way of knowing), then compare to what's committed. | 09:39 |
| * quicksilver nods | 09:39 | |
| quicksilver | fullermd: why "hope it came out the same way" ? | 09:40 |
| quicksilver | you mean if they chose a different merge algorithm? | 09:40 |
| fullermd | Or reprocess. Or bzr changes/bugfixes/bugadditions have happened since then that change the outcome. | 09:40 |
| * quicksilver nods | 09:40 | |
| fullermd | 's not out of the question that a merge algorithm could be nondeterministic too, though I don't know of any in common use. | 09:41 |
| fullermd | (and various other even bluerskier merge behaviors that could be difficult to reproduce) | 09:42 |
| fullermd | And that aside, a straight diff could look kinda weird in the case of conflict resolution. By the third or fourth time you hit that, you'd be tempted to go off and invent a new semantic language for representing that. | 09:44 |
| fullermd | Which would be (a) cool, and (b) save you from wasting time on your original boring problem ;) | 09:44 |
| quicksilver | yes, I considered the conflict problem. | 09:45 |
| quicksilver | In fact this is really all about conflicts in general | 09:46 |
| quicksilver | but there is of course a distinction between textual conflicts and "mere" semantic conflicts. | 09:46 |
| quicksilver | the kind of work you do in a merge commit is to fix the semantic conflicts. | 09:46 |
| quicksilver | (subroutine's API got changed in the other branch, perhaps) | 09:46 |
| fullermd | Nah, you just commit those. If it's important, the end user will tell you eventually. | 09:47 |
| quicksilver | :P | 09:47 |
| quicksilver | you can't commit them fullermd | 09:47 |
| quicksilver | commit does work unless all test pass. | 09:47 |
| quicksilver | doesn't. | 09:47 |
| fullermd | I didn't say you commit them under your _own_ name! | 09:47 |
| === echo-are` is now known as echo-area | ||
| === yofel_ is now known as yofel | ||
| === wallyworld is now known as wallyworld_ | ||
| jimis | hi, how can I diff latest committed version of a file, excluding uncommitted stuff, versus the one in another branch? | 13:05 |
| mgz | eg `bzr diff -r-1..branch:../trunk path/to/file` | 13:07 |
| mgz | but probably you want that revspec the other way around? | 13:07 |
| jimis | thanks mgz | 13:07 |
| jimis | no that way is good | 13:08 |
| jimis | so -r-1 refers to the latest committed changes? | 13:08 |
| mgz | yup, you can count revno backwards with negative numbers, like with lists in python | 13:09 |
| jimis | cool, I was just thinking it was one before last commit | 13:10 |
| pfrost | if i've merged a branch and introduced a regression, what's the most reasonable way to revert the merge such that i can fix the issue and later re-merge the branch? | 13:36 |
| pfrost | if i do something like "bzr merge . -r 123..122", I can reverse the commit that did the merge, but when i later merge the branch again, all the changes prior to the first merge aren't merged. | 13:37 |
| mgz | pfrost: more 'merge' than I can parse there :) | 13:42 |
| pfrost | it should be a fairly typical situtation in a branch-based development | 13:43 |
| pfrost | you have a "production" branch, and branches for each feature. You merge feature A, then later discover it introduces a regression, so you want to un-merge it. How would you do that? | 13:43 |
| mgz | can you give a more specific example of the problem when later wanting to merge the branch? | 13:43 |
| mgz | because the reverse merge is what I'd generally do. | 13:44 |
| pfrost | what do you mean by "reverse merge"? | 13:44 |
| mgz | -r 123..122 | 13:45 |
| pfrost | in the production branch? | 13:45 |
| mgz | yup. | 13:45 |
| pfrost | ok, so let's just forget about fixing the regression | 13:45 |
| pfrost | if at that point you try to merge the feature branch again, it will do nothing, because it's already been merged to production. The fact that the merge was reverted seems irrelevant to bzr. | 13:46 |
| pfrost | does that make sense? | 13:46 |
| mgz | yup. | 13:47 |
| pfrost | so what do you do to get around that? | 13:48 |
| pfrost | I imagine another problem with doing it this way is that if feature A branch merges production, all of feature A will be blown away. | 13:48 |
| mgz | that might be more of a worry., but it's generally not hard to revert | 13:49 |
| pfrost | sure it's not hard, but at this point, bzr is no more functional than CVS | 13:49 |
| mgz | the easy fix is for the feature branch to do exactly that, merge the rev where production does the revert | 13:49 |
| mgz | then revert the contents but keep the merge marker | 13:49 |
| mgz | then when it's next merged, the changes will come back to the production branch again | 13:50 |
| pfrost | how's that accomplished? | 13:50 |
| mgz | ...this is rather hard without diagrams | 13:50 |
| pfrost | i understand the approach, just not sure how to have bzr do it | 13:51 |
| mgz | so, current state is production is on r124 which reversed the merge done in r123 of the feature branch | 13:51 |
| mgz | so, in the feature branch do: | 13:51 |
| pfrost | i see bzr revert --forget-merges...i'm hoping to find something like bzr revert --keep-merges | 13:51 |
| mgz | `bzr revert *` is how you spell that | 13:51 |
| pfrost | ah | 13:51 |
| mgz | as in, revert all the contents, but keep the merge marker | 13:52 |
| pfrost | ok, that all makes sense | 13:52 |
| mgz | `bzr merge -r124 ../production && bzr revert * && bzr commit` | 13:52 |
| pfrost | coincidentally, i think git handles this process much more elegantly | 13:53 |
| mgz | I've never done it with git. | 13:53 |
| mgz | have only done it a couple of times with bzr. | 13:53 |
| pfrost | as i recall there's a command that puts all the revisions in a text editor, and you can just delete the one you want to undo, and it deletes that revision, then attempts to re-apply all the revisions that come after it | 13:53 |
| pfrost | provided that can be done without conflicts, it works | 13:53 |
| pfrost | if there are conflicts, it stops along the way so they can be resolved | 13:54 |
| mgz | right, that sounds like a history rewrite though | 13:54 |
| mgz | you'd not want to do that on a public production branch. | 13:54 |
| pfrost | hm, true | 13:54 |
| jelmer | pfrost: right, git rebase -i | 13:54 |
| mgz | (as opposed to a branch just for deployment or something which was a leaf you don't much care about the history of) | 13:55 |
| pfrost | well, git aside, i do wish there was a way to actually undo a merge, which isn't the same as creating a new revision that applies the inverse changes. | 13:56 |
| pfrost | the way things work around here, features get branches, and if they break anything, they get rejected outright, immediately. There's no merging of broken branches, then letting them hang out for a while until a separate fix is created. | 13:57 |
| mgz | but they land on production before testing? | 13:57 |
| mgz | or just that sometimes it's only picked up after a while on production | 13:58 |
| pfrost | production might be a misleading name | 13:58 |
| pfrost | the goal is to have the trunk branch be as close as what might be a release all the time | 13:58 |
| mgz | what we do is have a bot which creates a branch, applies the merge, runs the test suite, and only if it passes pushes that to the public trunk | 13:59 |
| pfrost | i do similar, but sometimes there are issues that aren't picked up by the tests | 13:59 |
| mgz | if the merge has conflicts or a test fails, you get email complaining | 13:59 |
| mgz | right, sometimes you'll want to back something out regardless | 14:00 |
| pfrost | that usually results in the merge being reverted, new tests being written to address the hole in test coverage, and another merge attempt made | 14:00 |
| mgz | it's a good habit, rather than letting things site | 14:00 |
| mgz | *sit | 14:00 |
| === deryck is now known as deryck[lunch] | ||
| === deryck[lunch] is now known as deryck | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!