thomiI'm sure I'm missinbg something really obvious, but how do I switch branches with the colo plugin?04:21
thumperthomi: switch04:23
thumperjust a wild stab in the dark04:23
thomioh, well that was obvious04:25
thomiI was expecting a colo-something command04:25
bob2it's le pluggable05:03
=== gthorslund is now known as gthorslund_
=== gthorslund_ is now known as gthorslund
lifelessover-usability, when things just work that you would not expect to do so05:24
fullermdBoy, if I had a nickel for every time people have said that about my software...05:31
fullermdI don't even know what I'd do.  What CAN you buy for two bits nowadays?05:32
lifelessfullermd: a nickel display cabinet05:37
bob2one one thousandth of a nickel display cabinet05:38
fullermdSo, if we band together, and find 997 like-minded people, we can have an awesome unveiling party!05:38
bob2velvet curtain will cost extra05:39
mgzmorning all!08:00
vilahey mgz et al. ;)08:53
mgzhow goes vila?09:02
vilaknee-deep in setting up a local launchpad ;)09:02
vilacatching up, I agree we should release a 2.5.1 (and merge up the delta too)09:03
quicksilveris there any way to see the extra diff in a merge?09:26
quicksilverI mean, the diff between what you would get by doing a straight merge, and what actually got committed09:26
mgznot easily09:31
mgzthere's a plugin lifeless has pointed me at least twice called...09:31
mgzthat can do that kind of thing.09:32
quicksilverstrikes me as a failing09:33
quicksilversometimes you really want it.09:33
mgzpatches welcome.09:33
quicksilverno doubt09:33
quicksilverI hope it's still permitted to discuss the bzr feature set here without being asked for a patch on each point.09:34
quicksilverdifftacular looks interesting.09:34
mgzit's such a nice answer when explaining the underlying complexities would be too much effort though :)09:34
quicksilverone could look at the merge-preview diff from the rev before, and the merge-preview diff from that rev09:35
quicksilverI wonder if anyone has considered a tool to sensibly compare two diffs09:35
fullermdThere's probably an emacs mode for it.  I think it's under ctrl-meta-hyper-sasquatch.09:37
quicksilverwell one natural way to compare to diffs is just to actually apply them to the tree (in a scratch branch)09:38
quicksilverand then compare the resulting trees09:39
fullermdAnyway, 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 nods09:39
quicksilverfullermd: why "hope it came out the same way" ?09:40
quicksilveryou mean if they chose a different merge algorithm?09:40
fullermdOr reprocess.  Or bzr changes/bugfixes/bugadditions have happened since then that change the outcome.09:40
* quicksilver nods09: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
fullermdAnd 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
fullermdWhich would be (a) cool, and (b) save you from wasting time on your original boring problem  ;)09:44
quicksilveryes, I considered the conflict problem.09:45
quicksilverIn fact this is really all about conflicts in general09:46
quicksilverbut there is of course a distinction between textual conflicts and "mere" semantic conflicts.09:46
quicksilverthe 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
fullermdNah, you just commit those.  If it's important, the end user will tell you eventually.09:47
quicksilveryou can't commit them fullermd09:47
quicksilvercommit does work unless all test pass.09:47
fullermdI 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_
jimishi, how can I diff latest committed version of a file, excluding uncommitted stuff, versus the one in another branch?13:05
mgzeg `bzr diff -r-1..branch:../trunk path/to/file`13:07
mgzbut probably you want that revspec the other way around?13:07
jimisthanks mgz13:07
jimisno that way is good13:08
jimisso -r-1 refers to the latest committed changes?13:08
mgzyup, you can count revno backwards with negative numbers, like with lists in python13:09
jimiscool, I was just thinking it was one before last commit13:10
pfrostif 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
pfrostif 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
mgzpfrost: more 'merge' than I can parse there :)13:42
pfrostit should be a fairly typical situtation in a branch-based development13:43
pfrostyou 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
mgzcan you give a more specific example of the problem when later wanting to merge the branch?13:43
mgzbecause the reverse merge is what I'd generally do.13:44
pfrostwhat do you mean by "reverse merge"?13:44
mgz-r 123..12213:45
pfrostin the production branch?13:45
pfrostok, so let's just forget about fixing the regression13:45
pfrostif 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
pfrostdoes that make sense?13:46
pfrostso what do you do to get around that?13:48
pfrostI 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
mgzthat might be more of a worry., but it's generally not hard to revert13:49
pfrostsure it's not hard, but at this point, bzr is no more functional than CVS13:49
mgzthe easy fix is for the feature branch to do exactly that, merge the rev where production does the revert13:49
mgzthen revert the contents but keep the merge marker13:49
mgzthen when it's next merged, the changes will come back to the production branch again13:50
pfrosthow's that accomplished?13:50
mgz...this is rather hard without diagrams13:50
pfrosti understand the approach, just not sure how to have bzr do it13:51
mgzso, current state is production is on r124 which reversed the merge done in r123 of the feature branch13:51
mgzso, in the feature branch do:13:51
pfrosti see bzr revert --forget-merges...i'm hoping to find something like bzr revert --keep-merges13:51
mgz`bzr revert *` is how you spell that13:51
mgzas in, revert all the contents, but keep the merge marker13:52
pfrostok, that all makes sense13:52
mgz`bzr merge -r124 ../production && bzr revert * && bzr commit`13:52
pfrostcoincidentally, i think git handles this process much more elegantly13:53
mgzI've never done it with git.13:53
mgzhave only done it a couple of times with bzr.13:53
pfrostas 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 it13:53
pfrostprovided that can be done without conflicts, it works13:53
pfrostif there are conflicts, it stops along the way so they can be resolved13:54
mgzright, that sounds like a history rewrite though13:54
mgzyou'd not want to do that on a public production branch.13:54
pfrosthm, true13:54
jelmerpfrost: right, git rebase -i13: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
pfrostwell, 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
pfrostthe 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
mgzbut they land on production before testing?13:57
mgzor just that sometimes it's only picked up after a while on production13:58
pfrostproduction might be a misleading name13:58
pfrostthe goal is to have the trunk branch be as close as what might be a release all the time13:58
mgzwhat 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 trunk13:59
pfrosti do similar, but sometimes there are issues that aren't picked up by the tests13:59
mgzif the merge has conflicts or a test fails, you get email complaining13:59
mgzright, sometimes you'll want to back something out regardless14:00
pfrostthat usually results in the merge being reverted, new tests being written to address the hole in test coverage, and another merge attempt made14:00
mgzit's a good habit, rather than letting things site14: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!