[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r29314 - in branches/mergeinfo-capability/subversion: include libsvn_client libsvn_ra_local libsvn_ra_svn libsvn_repos mod_dav_svn/reports svnserve

From: Karl Fogel <kfogel_at_red-bean.com>
Date: Thu, 14 Feb 2008 00:49:32 -0500

"David Glasser" <glasser_at_davidglasser.net> writes:
> On Feb 13, 2008 9:12 PM, Karl Fogel <kfogel_at_red-bean.com> wrote:
>> I just hate to add a public API before we're certain we'll need it for
>> anything else. Could we wait until the second fs capability we need,
>> and do it then? Then at least we'd know fs caps aren't a one-off...
> I mean, you're already adding a repository capability API which only
> has one capability... if you're going to turn around and do "try and
> see if it fails", you might as well just do that back in the RA code.
> I can see doing this the "try and see" way or the "ask if it's the
> right version" way, but going halfway seems odd to me.

Well, I added the svn_repos API because doing it that way got rid of a
fair amount of code duplication among the RA layers (though not all).

This also gives the outside world a clear way to ask questions about a
repository's capabilities. But an svn_fs_has_capability() API would
only be used by Subversion itself -- in fact, probably only by
libsvn_repos -- because for the rest of the world, the obvious &
recommended entry point would be svn_repos_has_capability(). It's the
absence of outside consumers that most makes me reluctant, I think.


To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-02-14 06:49:42 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.