Annotate policies

[James Westby]

Hi,

John, thanks for the write-up, it does a good job of explaining
the different options.

I was going to write a long reply, but then realised Martin
had already given the core of my argument.

On Thu, 2008-05-29 at 12:42 +1000, Martin Pool wrote:
> One option would be to allow for several of them and pass down an option
> saying what method to use; then we can get some user feedback or at least
> let them wiggle around to get a good result in a particular situation.  I
> have to admit though that doing this for merge has had only limited
> success: only a subset of users will actually try this if they hit a bad
> situation and we don't get a huge amount of clear feedback about how we
> could improve the default.
> 

It seems like this is one case where there isn't a clear winner,
as any algorithm could be rationalised. I'm not so concerned with
getting user feedback on the best one to use, but if we can come up
with a good way to present the information to the users, then
exposing the different results could allow them to discover things
about the code they are looking at.

However, I'm not sure this is worth the effort, as it will probably
be little used, and having to implement all the different algorithms
will be time-consuming and prone to bugs due to most not being used
much (though it sounds like John may have implemented most already),
and the UI would be a real pain to get right.

If we can't separate the algorithms on correctness, then should we
just eliminate the ones that we don't like and select on another
criteria, such as speed, or suitability for incremental annotation?

> I think ultimately the question "why is this line like this?" needs more
> than a one word (one revid) answer.  I think I'd like to conceptually get
> the highlighted parts of the revision graph showing how that line got to
> where it finally ended up, whether that is by its original addition,
> merges, conflict resolution, etc, and maybe even being to jump over
> sections where it was added and then replaced.  I don't

That's an interesting idea, and certainly something that I would
have liked to use last night, as "viz" and left-parent diffs were
confusing me.

Would you want it to act just on a line, or a region of a file,
e.g. a method? Would that just be adding several orders of magnitude
more complexity?

Thanks,

James