subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Foad <julianf...@btopenworld.com>
Subject Re: Don't reject arguments of the form ".@PEG"
Date Wed, 29 Oct 2014 14:35:35 GMT
I (Julian Foad) wrote:
>> Don't you think we should bump the API for this?
> 
> The change to svn_client_args_to_target_array2 is relaxing an error behaviour 
> that it didn't document in the first place. All usage that worked 
> (didn't error) before will still work. It seems unlikely that anything is 
> relying on this error behaviour in a way that will cause problems, so I 
> don't think that's necessary.

Bah, I got that wrong. svn_client_args_to_target_array2() was NOT the problem, and its behaviour
is unchanged by this commit.

The problem was AFTER svn_client_args_to_target_array2 had converted paths to "internal style",
then when we call svn_opt__split_arg_at_peg_revision() (typically via svn_opt_parse_path()
or svn_cl__eat_peg_revisions()).

So svn_opt_parse_path() is the only public function whose behaviour changes. I think it would
be sufficient to annotate its doc string like this:

  * @since New in 1.1.
+ * @since Since 1.6.5, this returns an error if @a path contains a peg
+ * specifier with no path before it, such as "@abc".
+ * @since Since 1.9.0, this no longer returns an error if @a path contains a peg
+ * specifier with no path before it, such as "@abc".

r1635151 adds this note, and also tweaks the docs of svn_client_args_to_target_array*().

- Julian


Mime
View raw message