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/.@bar', the error message says a peg revision isn't allowed at > 'foo@bar', regardless of whether 'foo/.@bar' exists. Yes, the syntax is > wrong, the user should have typed 'foo/.@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
