Ich Selbst wrote:
>>>- I just think it better if someone uses
>>>several clients that each client can make its own settings - maybe a
>>>
>>>
>client
>
>
>>>wants to use a different diff/diff3 version than another client
>>>
>>>
>>>
>>What's the benefit here?
>>
>>
>1. testing diff programs with new filetypes
>2. using non gnu diff programs (i.e. they use slightly different parameters
>for calling) and
> the client 'translates'
>
This is impossible without changes in libsvn_subr, because that's where
the diff programs are called from. At the moment, that's also where the
configuration is read.
>3. using other proxy settings for different clients could also be usefull
>for testing
>
I don't see how. Proxy behaviour should be completely independent of the
actual client used.
>>>or the client has a built-in diff/diff3 or ...
>>>
>>In that case, you won't be able to use the svn_client_diff API at all.
>>
>>
>why not? If it follows the same calling conventions?
>
>
>
>>It's not a really small change, and your change is wrong because it
>>totally ignores config files. Besides, making this a compile-time
>>options means that different clients wouldn't be able to share the same
>>Subversion libraries. Yuck.
>>
>>
>as far as I could see the config files are still used - if not then why even
>implement using the registry?
>
Yes, they are used, but your patch changed only the registry path -- it
didn't change the config file name. And config file settings override
registry settings.
>And I really think that different clients should use also different
>subversion
>libraries and not be forced to use the same!
>
Well, I think you're totally wrong here. The whole point of implementing
most of the functionality in libraries is to share them between clients.
>Imagine one day Subversion
>is improved to a point where backward compatibility is not fully possible -
>then you MUST be able to use different clients with different subversion
>libraries (one for older repos, one for the new ones).
>
Well of course, but library versioning deals with that. Mutually
incompatible libraries will have different names. As for supporting
older repositories -- hopefully, after 1.0 the schema won't change as
often as it does now; and the recommended way to deal with schema
changes will always be "svnadmin dump old-repo | svnadmin load new-repo".
>And besides: right now its only possible to link directly to subversion so
>each client HAS a different subversion library built in.
>
Ah, I think you're looking at Windows only, right? Yes, at the moment,
we only build static libraries on Windows. This will change, and by
default we'll be creating DLLs. Also, the library version will be
encoded in the DLL name, just as it is on Unix.
>>If you want that level of configurability, I suggest designing
>>client.side hooks/callbacks. But the first step is to finally implement
>>some kind of context from which the library functios can pull
>>configuration settings, instead of every function parsing the config all
>>over again.
>>
>>
>no offense - but I think my patch is usefull anyway. Since you're not
>forced to use it - either use it (by specifying the define in the compiler)
>or use the default (the way it is now).
>
I did agree that having a way to pull settings from elsewhere at runtime
would be useful. I just don't agree that your patch is the right way to
do it.
>Another thought: If a client/user uses the registry for storing config data
>then the settings for the same program (the client) will be on different
>base paths: the one for subversion under Software\tigris.org\subversion and
>the rest under Software\ClientCompany\Clientname
>
If a GUI client has its own configuration that's independent of what
we're using now, then I don't care where it puts it. Also, the main
place for storing configuration data will always be in files, not the
registry. We use the registry on Windows for convenience, not instead of
config files. The settings in the config files will always override
registry settings.
>and that's something I want to avoid - what belongs together should be
>stored together!
>
>
But your patch does exactly the opposite.
--
Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Nov 5 00:42:19 2002