On Mar 23, 2005, at 7:21 PM, Julian Foad wrote:
> Here is a quick review of the public APIs marked "@since New in 1.2"
> in r13616, and of the doc strings of the APIs deprecated by them.
>
Thanks for this fantastic review, Julian. What a great cleanup this
will be. As you can see, we committed most of this stuff as giant
to-do list, so we can start picking stuff off.
What I'm replying to here are the (very few) things that we're *not*
putting on the list.
>
> svn_client_checkout2
> svn_client_update2
> svn_client_diff2
> svn_client_diff_peg2
> svn_client_propset2
> svn_client_propget2
> svn_client_proplist2
> svn_client_export3
> svn_client_ls2
> svn_client_info
> svn_ra_do_update
> svn_ra_do_switch
> svn_ra_do_status
> svn_ra_do_diff
> svn_wc_process_committed2
> svn_wc_crawl_revisions2
> svn_wc_get_update_editor2
> svn_wc_get_diff_editor3
> svn_wc_diff3
> Enhancement: Ought to use "depth" instead of "recurse".
>
Our feeling is that this is out of scope for 1.2. There's already an
issue filed on this, and it needs to be a carefully-constructed,
widespread API change. There's certain nothing forcing us to do this
*now*. (Maybe we should assign the issue to 1.3?)
> svn_client_status2
> svn_wc_get_status_editor2
> svn_wc_resolved_conflict2
> Enhancement: Ought to use "depth" instead of "descend" or
> "recursive".
> Maybe "descend" and "recursive" ought to be renamed to "recurse" for
> consistency.
>
...however, the word 'descend' should definitely be excised now.
That's quick and easy. Then, in the future, we merely need to go
through all the mentions of 'recurs(ive)" and "nonrecursive" and
replace them with a real depth-indication system (enum?).
>
>
> svn_client_update2
> Enhancement: Ought to update all targets from the same repository to
> the
> same revision.
>
Again, this is already a filed issue with a long and painful history,
definitely not easy to fix. I don't think svn 1.2 should block on it.
> svn_cmdline_init2
> I'm not terribly happy with this. I don't think it makes clear what
> "server mode" is and why.
Hm, this API seems to have vanished...?
>
>
>
> svn_error_is_lock_error
> svn_error_is_unlock_error
> Someone raised a concern about whether these belong in svn_error.h.
>
>
What exactly is the complaint here? These are now macros, and all
three RA implementations need to share them. Should they go somewhere
else instead?
>
> SVN_ERR_REPOS_UNSUPPORTED_VERSION
> SVN_ERR_FS_UNSUPPORTED_FORMAT
> Why has the error number changed? Isn't that an ABI violation if we
> are now returning a different number for semantically the same error?
> Shouldn't the new name be added, equal to the old name, and the
> default message be changed to
> the new one?
Hm, considering we're getting ready to revert kfogel's repos-bumping
change, I suspect we'll have a nice fresh chance to revisit this.
> svn_fs_attach_lock
> Contradiction: "@a lock->owner must be filled in with an
> authenticated username. If not, ...". Change "must" to "may".
This API is now gone.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 28 23:06:38 2005