bzr conflicts --why to tell me about the revisions that are involved in a conflict

[James Westby]

(bug 606465 is perhaps a prerequisite)

james_w> poolie: https://code.edge.launchpad.net/~rom1-chal/bzr-builder/reporting_conflict_from_merge/+merge/30127 <- could you look at analyse_conflicts there and tell me if you know of a better way to achieve that?
<poolie> ah interesting, i think he was online before
<poolie> well i probably wouldn't put it inline in the exception of course...
<james_w> I'm thinking of showing the "bzr log" for the revisions, rather than just printing the developers, but I imagine that parsing the annotate text isn't ideal either way.
<poolie> no, it's not
<james_w> indeed
<james_w> and doing it lazily would be better
<poolie> if you peek inside the implementation of annotate i think there's an easy structured form
<poolie> james_w, so i'd probably work from _expand_annotations, at least
<poolie> that should be easily parseable
<james_w> yeah
<poolie> i think ideally this would be separated into something people could use in other bzr applications
<poolie> like in tarmac or pqm
<james_w> I don't like having to construct a Revision like that
<poolie> mm, that's weird
<poolie> gannotate works on the uncommitted changes without needing that
<poolie> hm, apparently in the same way
<poolie> that's a bit gross but perhaps it needs to be fixed in the core
<poolie> i guess that's where he got the idea from
<james_w> parsing the lines seems kind of necessary, but we can't rely on MERGE-SOURCE and TREE, but without them we might get confused
<poolie> maybe he/she copied them from gannotate
<james_w> yeah
<james_w> I just mean in general, we can query a tree for conflicted files, but not for conflicted chunks
<poolie> right
<poolie> it would be better to do the merge and annotation together
<poolie> if you did a weave merge you'd get that built in
<james_w> hmm
<james_w> that could work
<poolie> and i think also in structured form
<james_w> this is certainly better than the "OH NO CONFLICTS!!" we have now, so I'd be inclined to merge some version of this and go for incremental improvement.
<poolie> i'd like to see this in core
<poolie> maybe not run by default...
<poolie> it's kind of hard to tell where to put things that don't justify a whole plugin but that could be generally useful
<poolie> it seems like the ideal here would be something like
<poolie> 'bzr conflicts --why' to give you this summary
<poolie> listing the revisions and authors involved in each file
<james_w> yes
<poolie> https://bugs.edge.launchpad.net/bzr/+bug/606465
<ubot5> Launchpad bug 606465 in Bazaar "_expand_annotations should make it easier to annotate working tree with uncommitted changes (affected: 1, heat: 6)" [Wishlist,Confirmed]
<poolie> btw i set up http://pad.lv/606465 for a shorter form
<james_w> do you think taking the intersection of (revisions touching lines inside conflict markers) and (revisions after the LCA of the branches) would be the correct thing to do?
<james_w> (is LCA the right choice there?)

Thanks,

James