Julian Foad wrote on Mon, Jun 23, 2014 at 09:15:15 +0100:
> Markus Schaber wrote (in thread "controversial issues in the tracker"):
> > 4154 svn add foo foo complains
> > http://subversion.tigris.org/issues/show_bug.cgi?id=4154
> >
> > This issue suggests removing duplicates in the argument list of "svn
> > add". The example was the command line
> > svn add f* *o
> > which lead to errors because the file "foo" was matched twice.
> >
> > The discussion showed that there is no consensus on the correct behavior:
> > http://thread.gmane.org/iz4154@subversion.tigris.org
> >
> > Problems were that this could easily paper over typos in the filenames, and the
> > consistency between commands ("svn revert" currently doesn't error
> > out on duplicate targets, while "svn cat" should not eliminate
> > duplicates, as that will change semantics).
>
> I think the issue reported is too narrow: if we are going to
> consider making a change here we should consider the behaviour of all
> the subcommands not just 'add'.
>
In general, the question is whether 'svn $subcommand -- $targets'
considers $targets as a set or as a list.
For 'revert', this doesn't matter: either interpretation will lead to
the same results (unless the wc lock is released and reäcquired between
targets). For 'cat' this definitely matters (and we must use the 'list'
interpretation for compatibility).
For 'add', in the set interpretation we shouldn't generate a warning,
but in the list interpretation we should (just like 'svn add foo; svn
add foo' generates a warning from the second call).
> > As there is an easy workaround of using "--force", my personal
> > suggestion is to set this issue to "won't fix".
>
> The linked email thread ends with Daniel (the original issue reporter,
> cc'd) writing "Anyway, I won't pursue it." which suggests we can set
> it to "won't fix".
No objections here. I expected the 'svn add' to use the set
interpretation, but it uses the list interpretation; that's reasonable.
Received on 2014-06-23 14:22:04 CEST