Ich Selbst wrote:
>>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".
>>
>>
>Have you ever talked with an administrator about such things? Usually they (and me too) don't want to switch over to a completely new version from one minute to the other. So having different versions for some time is needed and the switch is then done when it is absolutely sure that the new version works as wanted and as soon as ALL users have the new client installed.
>
What does that have to do with anything? You can use different versions
of the client today, and you'll always be able to do so. If there's a
major change in the API, network protocol or database schema, the
library version will change.
>Or are you capable of updating ~100 or more clients within one day? And
>teach every user the new client?
>
Yes. That's exactly the purpose of deployment planning.
>>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.
>>
>>
>That's a good idea and surely needed. But no reason to not commit the patch.
>
I don't agree. Your patch doesn't fix any immediate problem, and there's
a better solution in the works.
>>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.
>>
>>
>What other way as easy as this do you suggest?
>
I mentioned it two posts back in this thread. It involves passing a
context baton to all functions that need configuration. Then the client
can decide how to fill that context.
>>>and that's something I want to avoid - what belongs together should be
>>>stored together!
>>>
>>>
>>But your patch does exactly the opposite.
>>
>>
>Huh? How that?
>
>What I expect from a program (no matter what it does) is that it comes with an installer and ALL files/libraries it might need. I really HATE it when a program forces me to download several other libraries from different places and install them separately.
>
Nonsense. Many programs share libraries on Windows (the MS Office tools
are a famous example), and you don't have to download the libraries
separately. Every installer can include the Subversion DLLs, and just
not install them if appropriate versions are already on the system -- or
upgrade the installed ones if it has newer, compatible versions.
>I know that's the default on Linux
>
Which Linux?
>but on Windows I expect an easy installation (and so do others).
>
That's a problem for the installer to solve, not for our libraries --
except that we must actively support library versioning. Which we do.
>So: a client for Subversion needs all libraries and helper programs included. As soon as you use more than one client (e.g. a plugin for an IDE and a standalone one) you will have different libraries stored in different places and the last one installed forces to use the other clients those libraries (because those are global settings).
>
Yes, that kind of lack of planning is the reason why many Windows
programs are a pain to install and use. There's absolutely no reason not
to share libraries among different clients, sharing doesn't stop you
from having different versions installed at the same time, and the
problem of using multiple configuration sources will be solved
differently than you propose.
>I really, really want to avoid that!
>
So do I. But I don't want to "avoid" it by creating more chaos instead
of less.
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 20:01:37 2002