On Sun, 11 Nov 2007, Troy Curtis Jr wrote:
> So I just submitted that initial relative-url patch and now I'm off
> trying to implement it right everywhere else. Is it expected that
> each command that could take a relative url must have a test made for
> it? Or is it enough that the functionality is tested in merge-tests?
In terms of code coverage, it'd of course be better to have each usage
tested. Practically speaking, we don't always do so (it's certainly a
lot more test code to maintain). If you only test one or two
sub-commands, and do so really really thoroughly, I'd say it's
sufficient to get us started with.
> 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 notice there is no 'libsvn_client' test directory. Is it
> just assumed that what you are testing for makes it through the
> command line client and is thus caught by the cmdline tests?
We've been using a combination of the cmdline test suite and bindings
tests (e.g. Java, Ruby, Python, Perl) to verify libsvn_client.
- application/pgp-signature attachment: stored
Received on Mon Nov 12 18:28:22 2007