On 9/20/07, C. Michael Pilato <firstname.lastname@example.org> wrote:
> Mark Phippard wrote:
> >> I find this utterly confusing and even though several people have
> >> argued that users think of revisions as changes, I don't think it's a
> >> reason for us to start conflating the two.
> > Utterly confusing? Really? In all of the proposed places it is using
> > this format it is in a situation where these revisions have already
> > been applied. Arguably, this is closer to svn log, then it is to svn
> > merge/diff where you are using the revisions to tell it to do
> > something.
> 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
> Some of the disparity is due to the nature of the commands: the data used
> for log output can't really be collapsed, because the nature of the command
> is to show that raw data iteratively. Log is about showing the changes
> themselves (the nodes), not the differences between them (the edges).
> Blame, diff, and merge are more about showing the edges -- not the actually
> snapshots, but the state changes between them.
> 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 -- in my experience its the fact that diff's path arguments are
> iterative when most folks expect them to be comparative (like GNU diff's
> are). If diff's use of -r doesn't confuse you, neither will merge's. And
> it could be that most folks just don't use the revision-range form of blame.
> I dunno ... I don't have enough anecdotal evidence to speak with authority
My mail was triggered by a mail (or IRC) thread which I have trouble
But we have never (until now) sent output to the user which looks like this:
$ svn merge -r40:45 <some-url> .
Merging revisions 41 to 45
(What happened to 40?!)
The mail I read (the one I have trouble finding) said something along
the lines "merge tracking has started using revision ranges to, so, I
can now see which commands have been entered at the command line: look
the mergeinfo prop says '/branch:40-45', so, the command was 'svn
merge -r40:45". This line of reasoning is completely logical to me
from a users perspective, but completely the wrong conclusion.
This is why I say, "let's support -c 40-45" which would mean exactly
what people can find in the mergeinfo property *and* as the output
from the commandline client. That way, there's little room for
confusion, since we'll just start telling people to use -c with diff
and merge. -r is for looking at the nodes, -c for the edges, meaning
that -r makes sense for log, update, switch, copy etc. Just not for
diff, merge and mergetracking output.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Thu Sep 20 14:09:29 2007