> >That's a good idea and surely needed. But no reason to not commit the
> I don't agree. Your patch doesn't fix any immediate problem, and there's
> a better solution in the works.
ok. when will it be ready to use?
> 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.
I don't think that's an 'easy' way. But I admit it would offer a cleaner
> 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.
If you mention the Office tools: Yes, they share their libraries. But they
that by installing them in a specific subfolder. If Subversion wants to do
then it has to define a fix folder location.
> >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.
It seems we have different opinions on this: I never had any problems
a windows program but surely almost every time I tried installing a program
on linux. A windows installer never complained about missing libraries and
stopped. Under linux that happend to me almost every time (which resulted in
time consuming web sessions to search for the missing libraries, downloading
and install them, and often those libraries needed other libraries as well
surely are not included and needed a seperate search/download session).
If you want to share libraries under windows you'd have to install them in
the windows/system32 folder and that's a thing I hate. Because you can't
those files when uninstalling the program which copied those libraries there
because you can't be sure that no other program is using them also. So after
time you end up with many many orphaned library files.
But if a program installs all libraries it needs into its own folder then
uninstall that program without either risking deleting files other apps need
and without probably leaving orphaned files. THAT's what I call a clean
Sharing libraries has its advantages too, but only if the library is used by
it's very big and is updated only rarely. In all other cases it's better not
to share the
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Tue Nov 5 20:19:03 2002