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.
Received on 2013-08-23 15:37:44 CEST