[C. Michael Pilato]
> If only it was a binary situation ... but it isn't. We currently have the
> following interpretations of -rN:M
>
> svn log -rN:M -- iterative output from N to M, inclusive
> svn blame -rN:M -- collapsed output with data from N to M, inclusive
> svn diff/merge -rN:M -- collapsed output with data from N+1 to M
Good summary. Worth noting also is that -rN is meaningful only for the
first two cases. (Also, if N > M, the third range is N to M+1.)
> Log is about showing the changes themselves (the nodes), not the
> differences between them (the edges).
Interesting that you put it that way, because I've always heard before
that the Subversion architecture is fundamentally not about _changes_
but about _tree snapshots_. That is, each revision is a snapshot in
time, and the change that produced this tree is a second-order
(derived) object.
It has taken years, but I _finally_ figured out how to explain why 'log
-rN' bothers me in that sense. I've argued many times before that 'log
-rN' really should be 'log -cN' from a user interface consistency
perspective. This is an unpopular opinion, because apparently users
are expected to know that log information is stored _in_ the metadata
for a revision, so -rN is supposed to make sense because it talks about
a revision. But if you look at the information the user gets back from
'svn log', it hardly talks about the snapshot at all!
- textual log message: is almost always worded in terms of the
_changes_ the developer made, not in terms of the tree that was
created. Verb phrases, that is, rather than noun phrases.
- author, date: that does relate to the revision.
- 'log -v' info: again, relates to the _changes_, not to the tree.
If it were about the tree, it would resemble 'svnlook tree'. Of
course it doesn't, it resembles 'svn diff --summarize' instead.
So you can say "the log command asks for information about a particular
revision", but in plain English, what the user gets back is mostly
information about the changes that led to the revision. Never mind
that the information is physically stored in the revision node. To me
that's an implementation detail.
> Has any of this caused real user confusion? I don't know, but I
> doubt it. I mean, diff's syntax causes lots of confusion, but not
> because of how -r is treated
I find it confusing to have to explain to users, "If you want to see
what has been committed between r5 and r10, use 'svn log -r6:10'. To
see the changes in patch format, use 'svn diff -r5:10'."
As for blame, I think I assumed it used the diff sense of revision
ranges; your message just now set me straight on that. Not that it
matters very much in practice. So I guess I was one confused user. I
assumed this because I know it has to fetch deltas in order to do its
work, like diff and unlike log. (Though obviously the deltas have to
be iterative rather than cumulative.)
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Sep 20 15:49:38 2007