[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Confusing situation regarding revisions and changes

From: Erik Huelsmann <ehuels_at_gmail.com>
Date: 2007-09-20 14:09:16 CEST

On 9/20/07, C. Michael Pilato <cmpilato@collab.net> 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
> here.

My mail was triggered by a mail (or IRC) thread which I have trouble
finding now.

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.

bye,

Erik.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Sep 20 14:09:29 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.