Ben Reser wrote on Thu, Aug 22, 2013 at 22:18:49 -0700: > bA=^/project1/branches/branchA > svn merge $bA
That was also the argument against adding ^/, wasn't it? The counter-argument is that "Make URL targets easier to input" is a problem that every user of the cmdline client has (scripts included, btw), so it makes sense to solve it centrally. > I'm sure you can probably even get your shell to be fancy and figure out > what project you're working in and apply the proper root (you have > access to this with svn info). > > Additionally I'm concerned that this just confuses the meaning for users > of how ^/ works. I can already see the user complaints that Subversion > merged the wrong thing for them because they forget -b. > > Let's just say that at this point I'm skeptical of the need for this. I don't like -b. It's a confusing syntax, mixing named and positional arguments (how would it work with 'svn diff --old=URL'?), interferering with the '--' convention, etc. But extending ^/bar to ^foo/bar is something I've long wanted to see, precisely so that URLs other than the repository root may be abbreviated. (Right now ^ must always be followed by /.) I've been thinking of a config file entry, mapping "foo" to expanded value of "^/foo", but an inherited property (so we don't need to figure out "/subversion" from the wc root URL's[1]) is an interesting alternative. A problem with the regexp captures approach is that it doesn't allow shortening the basename, while I would like to, say, shorten "fsfs-improvements" and "invoke-diff-cmd-feature" to "fsfs-imp" and, say, "idc". Perhaps we should extend the syntax to allow making something other than \1 (first capture group) the shortname of a given regexp match? Daniel [1] We can't assume a particular repository layout.
