John Arbash Meinel
john at arbash-meinel.com
Wed Jun 4 18:45:46 BST 2008
-----BEGIN PGP SIGNED MESSAGE-----
James Westby wrote:
| 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.
I think the hardest part is coming up with *names* for the different algorithms.
I don't think people want to be running:
~ bzr annotate --algorithm=4b
I'm pretty sure the code is fairly flexible. ATM I just need to figure out what
priority to give to it.
| 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 would be nice, but I think it is something other than a plain 'annotate'.
Certainly it could be something that a tool like 'gannotate' might end up
| 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?
Well it is fairly simple to create a revision graph of just the revisions that
touched a file. It can be extended to show the graph of revisions that merged
revisions that touched the file (we do this for 'bzr log filename').
You could then filter that graph by what entries actually touched a given subset
of the lines.
My biggest concern would be how to present it all to the user. How would you
select the lines, how would you navigate the graphs, how do you define the
concept of 'this line' as it evolves over time. If I have:
~ foo = bar();
And I change that to:
~ foo = baz();
Is that a new line? What about:
~ foo = bar(10+10*100);
~ completely_diff_variable = diff_function():
(assuming the surrounding lines don't change).
Line identity is a pretty difficult problem. You can box a region as "lines
10-20" but that is in a given version of the text. How do those boundaries move
with patches. Some resolutions are obvious (patches before 10 will move that
boundary, after 20 won't move that one, inbetween 10-20 will probably change the
range), but not all (what do you do when a patch crosses the boundary).
It certainly fits what Stefan was wanting, though.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the bazaar