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

Re: Question about tests

From: Karl Fogel <kfogel_at_red-bean.com>
Date: 2007-11-12 19:09:30 CET

Daniel Rall <dlr@collab.net> writes:
>> Also I want to implement relative url support directly in the various
>> client api functions so that other apps can take advantage of them.
>> Some subcommands it is simple to just let the relative url go all the
>> way to the client API call and thus you have a test. However, some
>> cases (such as merge) do so much stuff in the command line function
>> that it only makes sense to resolve the relative url as soon as
>> possible.
> What to other people think about pushing support for this into
> libsvn_client? Personally, it seems most immediately useful to me to
> the command-line client, but I may be biased here. I could certainly
> see it being useful to third-party clients like Subclipse and
> TortoiseSVN, but would it make more sense for those clients to use a
> conversion routine from libsvn_subr?
> If we do push this into libsvn_client, having a few spots where we
> call the conversion routine externally in the client code itself seems
> okay to me.

I'd feel slightly more comfortable having callers resolve the URLs,
and not having libsvn_client() handle relative URLs directly, for now.
Once we add it, we'll be supporting it forever, and the API changes
for 1.5 are already quite large.

Going from caller-responsible to callee-responsible in 1.6 is a small,
fairly easy step. Since it's irreversible, why don't we see how
necessary it is before we do it?

If others feel really strongly about putting this into libsvn_client,
though, that's fine. The above is just my cautious instincts talking.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 12 19:15:33 2007

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.