Karl Fogel wrote:
[...]
> Thoughts?,
Yes, lots :-)
Firstly - about the configuration file in general.
I think the configuration file should be a feature of the command-line
client only. Ofcourse a Subversion library can provide access to a
common configuration file, but the "svn_client.h" functions should not
internally use the configuration file. Instead, some configuration
parameter should be given to them. Someone mentioned a lot of good
reasons already - but basically I think this is correct because
there's going to be quite a few places where different clients are
going to be wanting to store their configurations.
Then - about the human representation of dates.
I think the human representation of dates is purely the responsibility
of the client. By that I mean that the command-line client, svnadmin
and svnlook are the ones wanting that behaviour - and it's their
business only. A GUI client is most probably wanting to use a vastly
different representation of dates, as are other kind of clients. The
fact that libsvn_subr provides the function is merely a convenience
for all the users of that library. And through this I also claim that
it should have no knowledge what so ever of any configuration files -
instead it should somehow take in the desired format.
And still more - about interface separation.
I think it should be much more clearly defined that what includes and
libraries are a part of the "Subversion client library" - and what are
just convenience functions that can be used by the caller, if they
wish. Personally, I think that the "svn_client.h" should be
standalone. Callers would include that file and use the functions
there to perform all operations. But this would mean that all the
results of the functions should be directly parseable by APR functions
- or the parsing functions need to be made a part of that
interface. Today this is not so, for example because the
svn_client_log function returns dates as strings to the log message
receiver - and you need to use svn_time_from_nts to get an APR date
out of that.
So - what to do then?
I think svn_time_to_human_nts should be modified to accept the format
as a parameter somehow. It might be mandatory, or there might be an
easy hard-coded default that can be used. Then the command-line client
subcommands log and info, svnadmin and svnlook would be modified to
just read the configuration file themselves and pass the date format
parameter to svn_time_to_human_nts. And then issues should be filed
about getting sense into the configuration file processing in the long
term.
Thoughts? ;-)
-- Naked
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 18 01:13:49 2002