Re: svn commit: r1146270 - /subversion/branches/1.7.x/STATUS

[Daniel Shahaf <da...@apache.org>]

cmpilato@apache.org wrote on Wed, Jul 13, 2011 at 19:28:18 -0000:
> @@ -31,6 +31,7 @@ Candidate changes:
>     Votes:
>       +1: danielsh, rhuijben
>       -1: stsp (no-op API change)
> +     -1: cmpilato (no-op API change -- will reconsider if real utility is added)

Well, I've since implemented svn_fs_verify() on trunk; and the theory
is that backporting these two revisions for 1.7.0 is required if we're
to backport the implementation in a future 1.7.x release.

As I see it, the options are:

* Pull this backport nomination.  No svn_fs_verify() in 1.7.x

* Backport it, and backport the implementation in 1.7.x (x >= 1)

* Backport svn_fs_verify() and its implementation in 1.7.0

Re: svn commit: r1146270 - /subversion/branches/1.7.x/STATUS

["C. Michael Pilato" <cm...@collab.net>]

On 07/13/2011 03:40 PM, Daniel Shahaf wrote:
> As I see it, the options are:
> 
> * Pull this backport nomination.  No svn_fs_verify() in 1.7.x
> 
> * Backport it, and backport the implementation in 1.7.x (x >= 1)
> 
> * Backport svn_fs_verify() and its implementation in 1.7.0

I see what you see, except I don't see that middle option.  Releasing a
to-be-implemented-later API is merely an attempt to skirt our compatibility
guarantees.  And in my experience, when an API is introduced so quickly and
without an actual implementation, there's a very good chance that with the
implementation will come the frustrating reality that the API as originally
proposed was ill-suited to the purposes for which it was created.

I'm not maintaining a bias on the other two options, though:  I can go
either way right now on "pull the backport nomination" or "also nominate
some actual value for 1.7.0".

-- 
C. Michael Pilato <cm...@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand