Branko Čibej wrote on Sun, Nov 11, 2018 at 12:02:14 +0100:
> On 11.11.2018 10:54, Daniel Shahaf wrote:
> > It wasn't clear to me what you were proposing.
> >
> > It still isn't, actually. Have I overlooked a commit or email where you
> > spelled out what the new algorithm would be? None of the emails in this
> > thread spells out an algorithm.
>
> That's because I don't know it yet ... since I can't describe precisely
> what is wrong with the way we currently do things, but I do have the
> feeling that we're doing something wrong. I was hoping this discussion
> would clarify things.
>
Makes sense.
> > What change, if any, do you propose?
>
> As I said, I'm still trying to work this out. For example, one of the
> things that's been driving me up the wall is that when the user writes
> 'foo/._at_bar', the error message says a peg revision isn't allowed at
> 'foo_at_bar', regardless of whether 'foo/.@bar' exists. Yes, the syntax is
> wrong, the user should have typed 'foo/._at_bar@' instead, but surely we
> can be smart enough to notice that instead of emitting an error about
> something the user almost certainly didn't have in mind?
This sounds like two separate issues.
1. When printing an error about a path not existing, and the path
contains an "@" that was parsed as a peg revision marker, stat() the
argument as typed, and if it exists add a hint to the error message.
2. Error messages contain «svn_dirent_local_style(svn_dirent_canonicalize(argv[N]))»
and do not contain argv[N] as typed. Including the former is indeed
unusual, but it has its upsides: it shows the user how svn parsed the
argument. For example, when a user intends to run «svn cat ./foo» but
accidentally runs «svn cat ../foo» instead, the error message might
actually be easier to understand with ../foo printed as an abspath
(which aspect is actually orthogonal to canonicalization…).
Cheers,
Daniel
Received on 2018-11-11 12:52:40 CET