You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Karl Fogel <kf...@newton.ch.collab.net> on 2002/11/04 18:32:54 UTC
Re: patch suggestion
"Ich Selbst" <ic...@gmx.ch> writes:
> I suggest a patch to enable clients to use their own
> registry base - that way the settings like proxy, path
> to diff and diff3 and the like can be handled on a client
> basis.
A compile time option for this seems of minimal benefit, but maybe I'm
just not understanding the scenario here. What is the problem you
encountered?
-K
> patch as follows:
>
> file libsvn_subr\config_impl.h
> line 83 now:
> # define SVN_REGISTRY_PATH "Software\\Tigris.org\\Subversion\\"
>
> after patching:
> #ifndef SVN_REGISTRY_PATH
> # define SVN_REGISTRY_PATH "Software\\Tigris.org\\Subversion\\"
> #endif
> Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: patch suggestion
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
"Ich Selbst" <ic...@gmx.ch> writes:
> I don't have a problem (this time :) - 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 or the
> client
> has a built-in diff/diff3 or ...
> And since that change belongs to the really small ones I thought it would
> be a good idea.
Let's avoid adding complexity until someone actually runs into a
problem (as a general rule, I hope :-) ).
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: patch suggestion
Posted by Philip Martin <ph...@codematters.co.uk>.
"Ich Selbst" <ic...@gmx.ch> writes:
> > 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.
That this will be "difficult" has been mentioned a few times now, but
I don't think making such a change is that hard. Just change the
low-level function declaration and the compiler tells you everywhere
that needs to change, change those and repeat until you reach the top
level. Yes, it may affect lots of lines of code, but the change is
fairly mechanical, the same context baton just gets passed through.
Should be far easier than adding access batons :)
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: about context parameter
Posted by Philip Martin <ph...@codematters.co.uk>.
[I've been meaning to respond to this for some time...]
Greg Stein <gs...@lyra.org> writes:
> I believe we should have something like svn_client_t. That object would be
> opaque and could hold a number of things:
>
> * auth info
> * config info
> * notification funcs?
>
> It should be documented that it is totally fine to mix and match
> svn_client_t structures in case a person wants to use different notification
> functions, for example. To make it apparent that we aren't storing state in
> the context (thus, they can be mixed/matched), we might actually want to
> make the structure non-opaque.
I'm not sure svn_client_t is a good name, I don't think this is part
of the client library, is it? We don't want the lower level libraries
to have to depend on libsvn_client. Perhaps svn_environment_t, or
svn_context_t, or even svn_t would be better. I'll use svn_client_t
in what follows, but that's just for convenience.
How exactly do you see this working? I assume the svn_client_t object
gets passed from the application down to the lower levels, such as
ra_dav, where it can be used to obtain certain information. If the
type is opaque what does the ra_dav code look like? Is it like this
svn_error_t *ra_dav_foo (svn_client_t *context)
{
int n;
SVN_ERR (svn_context_get_yyy (&n, context));
}
If so, then how will an application be able to provide it's own
implementation of a context retrieval function? It would appear to
need something like
svn_error_t *
svn_context_register_get_yyy(svn_client_t *context,
svn_error_t *(*fn)(int *, void *),
void *fn_baton);
which stores fn/fn_baton in the context object, so that a later call
to svn_context_get_yyy can call fn and pass fn_baton.
It may be simpler to have a non-opaque object, a vtable/baton
combination
typedef struct svn_client_t {
svn_error_t *get_yyy(int *, void *);
svn_error_t *get_zzz(const char **, void *);
void *baton;
} svn_environment_t;
and have the ra_dav code look like
svn_error_t *ra_dav_foo (svn_client_t *context)
{
int n;
SVN_ERR (context->get_yyy (&n, context->baton));
}
Subversion would provide a generic
svn_client_t *svn_context_create();
and the application is free to substitute any of the vtable functions.
The svn_client_t could also contain cancellation information, this
could either be another function pointer, or it could be a data
pointer. The latter would provide a cancellation mechanism without
the overhead of a function call, which could be important if the check
goes into SVN_ERR. We could even have both a function pointer and a
data pointer and so let the application decide which to use.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: about context parameter
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Nov 05, 2002 at 10:06:19PM +0200, Nuutti Kotivuori wrote:
> brane@xbc.nu wrote:
> > The discussion blocked some time ago when it seemed that adding a
> > context param would be expensive. Later on I suggested storing the
> > context in the top-level pool (which would be different for each
> > client thread), but there haven't been any replies yet. Serves me
> > right for pushing comments into the issue tracker instead of posting
> > them here. But maybe I should just implement that...
>
> Well, I was kind of waiting for the discussion to sort itself out
> after a while - but then it happened to die off altogether.
>
> I'm also interested in seeing the context parameters appear in the
> code. :-)
I believe we should have something like svn_client_t. That object would be
opaque and could hold a number of things:
* auth info
* config info
* notification funcs?
It should be documented that it is totally fine to mix and match
svn_client_t structures in case a person wants to use different notification
functions, for example. To make it apparent that we aren't storing state in
the context (thus, they can be mixed/matched), we might actually want to
make the structure non-opaque.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Re: patch suggestion
Posted by Bill Tutt <ra...@lyra.org>.
I agree as well. There are several forms of multi-threaded programming
that migrate user contexts between differing threads of execution.
Relying on a particular model would be annoying.
Bill
----
Do you want a dangerous fugitive staying in your flat?
No.
Well, don't upset him and he'll be a nice fugitive staying in your flat.
> -----Original Message-----
> From: Greg Hudson [mailto:ghudson@MIT.EDU]
> Sent: Tuesday, November 05, 2002 11:09 PM
> To: Branko Cibej
> Cc: dev@subversion.tigris.org
> Subject: Re: patch suggestion
>
> On Tue, 2002-11-05 at 15:15, Branko Čibej wrote:
> > Not exactly. It's a per-thread global variable (assuming different
> > threads use separate global pools, which they'd be insane not to),
and
> > in this case I believe it makes sense.
>
> So, as I understand your reasoning, you think there should be multiple
> contexts, but you can't use one context in multiple threads, or
multiple
> contexts in one thread? I think you're assuming a very specific model
> of threaded programming, and we shouldn't be so inflexible.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: patch suggestion
Posted by Greg Hudson <gh...@MIT.EDU>.
On Tue, 2002-11-05 at 15:15, Branko Čibej wrote:
> Not exactly. It's a per-thread global variable (assuming different
> threads use separate global pools, which they'd be insane not to), and
> in this case I believe it makes sense.
So, as I understand your reasoning, you think there should be multiple
contexts, but you can't use one context in multiple threads, or multiple
contexts in one thread? I think you're assuming a very specific model
of threaded programming, and we shouldn't be so inflexible.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: patch suggestion
Posted by Branko Čibej <br...@xbc.nu>.
Karl Fogel wrote:
>Branko Čibej <br...@xbc.nu> writes:
>
>
>>When somebody implements it? :-)
>>The discussion blocked some time ago when it seemed that adding a
>>context param would be expensive.
>>
>>
>
>"expensive" only in the "lots of work" sense, not performance.
>
Yes, of course.
>>Later on I suggested storing the
>>context in the top-level pool (which would be different for each
>>client thread), but there haven't been any replies yet. Serves me
>>right for pushing comments into the issue tracker instead of posting
>>them here. But maybe I should just implement that...
>>
>>
>
>Yucko :-). This is just global variables by another name; let's at
>least make it an explicit parameter. But no, I'm not volunteering
>right now, either.
>
Not exactly. It's a per-thread global variable (assuming different
threads use separate global pools, which they'd be insane not to), and
in this case I believe it makes sense. There aren't all that many
functions that use configuration data, and passing an extra parameter to
all functions just for those lucky few seems like overkill. OTOH, all
the relevant functions _do_ take a pool parameter. So why not hang this
data off of the top-level pool?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: patch suggestion
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Branko Čibej <br...@xbc.nu> writes:
> When somebody implements it? :-)
> The discussion blocked some time ago when it seemed that adding a
> context param would be expensive.
"expensive" only in the "lots of work" sense, not performance.
> Later on I suggested storing the
> context in the top-level pool (which would be different for each
> client thread), but there haven't been any replies yet. Serves me
> right for pushing comments into the issue tracker instead of posting
> them here. But maybe I should just implement that...
Yucko :-). This is just global variables by another name; let's at
least make it an explicit parameter. But no, I'm not volunteering
right now, either.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: patch suggestion
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Nov 05, 2002 at 08:27:36PM +0100, Branko Cibej wrote:
>...
> context param would be expensive. Later on I suggested storing the
> context in the top-level pool (which would be different for each client
> thread), but there haven't been any replies yet. Serves me right for
> pushing comments into the issue tracker instead of posting them here.
> But maybe I should just implement that...
We should avoid using pools as a way to store global variables, or even
per-thread variables. That is just ugly. The old callback system worked that
way, and hoo boy, was it confusing. I recall a problem with it and
explaining that to Ben and how it interacted with that callback stuff; even
though he had helped to work on the callbacks, he was flabbergasted. Had no
idea how that particular interaction occurred. At that point, he was a True
Convert to get rid of that pool hackiness.
And no, don't point out that the error pool stuff are effectively globals in
the pools, as that is still all about pool management. Not storage of state.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
about context parameter
Posted by Nuutti Kotivuori <na...@iki.fi>.
brane@xbc.nu wrote:
> The discussion blocked some time ago when it seemed that adding a
> context param would be expensive. Later on I suggested storing the
> context in the top-level pool (which would be different for each
> client thread), but there haven't been any replies yet. Serves me
> right for pushing comments into the issue tracker instead of posting
> them here. But maybe I should just implement that...
Well, I was kind of waiting for the discussion to sort itself out
after a while - but then it happened to die off altogether.
I'm also interested in seeing the context parameters appear in the
code. :-)
-- Naked
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: patch suggestion
Posted by Branko Čibej <br...@xbc.nu>.
Ich Selbst wrote:
>>>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.
>>
>>
>ok. when will it be ready to use?
>
When somebody implements it? :-)
The discussion blocked some time ago when it seemed that adding a
context param would be expensive. Later on I suggested storing the
context in the top-level pool (which would be different for each client
thread), but there haven't been any replies yet. Serves me right for
pushing comments into the issue tracker instead of posting them here.
But maybe I should just implement that...
>>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
>do
>that by installing them in a specific subfolder. If Subversion wants to do
>that
>then it has to define a fix folder location.
>
Of course. Or rather, a standard way to find that folder. AFAIK, shuch
mechanisms exist in the Windows installer world.
>>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
>installing
>a windows program but surely almost every time I tried installing a program
>on linux.
>
:-)
> A windows installer never complained about missing libraries and
>then
>stopped.
>
Like I said, there's no reason not to include the libraries in _every_
installer, but only install them if necessary. The Windows installer
does that today with the Cygwin stuff.
Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: patch suggestion
Posted by Ich Selbst <ic...@gmx.ch>.
> >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.
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
solution.
> 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
do
that by installing them in a specific subfolder. If Subversion wants to do
that
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
installing
a windows program but surely almost every time I tried installing a program
on linux. A windows installer never complained about missing libraries and
then
stopped. Under linux that happend to me almost every time (which resulted in
time consuming web sessions to search for the missing libraries, downloading
them
and install them, and often those libraries needed other libraries as well
which
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
delete
those files when uninstalling the program which copied those libraries there
just
because you can't be sure that no other program is using them also. So after
some
time you end up with many many orphaned library files.
But if a program installs all libraries it needs into its own folder then
you can
uninstall that program without either risking deleting files other apps need
as well
and without probably leaving orphaned files. THAT's what I call a clean
installation.
Sharing libraries has its advantages too, but only if the library is used by
many programs,
it's very big and is updated only rarely. In all other cases it's better not
to share the
libraries.
Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: patch suggestion
Posted by Branko Čibej <br...@xbc.nu>.
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
Re: patch suggestion
Posted by Ich Selbst <ic...@gmx.ch>.
> I don't see how. Proxy behaviour should be completely independent of the
> actual client used.
They still can be - just store them in the config files instead of 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.
That's the wanted behaviour - so each program can store its own settings
in the registry and if the user wants global settings then use the config
files.
> 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.
Or are you capable of updating ~100 or more clients within one day? And
teach every user the new client?
> 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 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?
> >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. I know that's the default on Linux but on Windows I expect an
easy
installation (and so do others). 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).
I really, really want to avoid that!
Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: patch suggestion
Posted by Branko Čibej <br...@xbc.nu>.
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 <br...@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
Re: patch suggestion
Posted by Ich Selbst <ic...@gmx.ch>.
>
> Bah.
Gesundheit
> > - 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'
3. using other proxy settings for different clients could also be usefull
for testing
> > 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?
And I really think that different clients should use also different
subversion
libraries and not be forced to use the same! 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).
And besides: right now its only possible to link directly to subversion so
each client HAS a different subversion library built in.
> 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).
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
and that's something I want to avoid - what belongs together should be
stored together!
Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: patch suggestion
Posted by Branko Čibej <br...@xbc.nu>.
Ich Selbst wrote:
>>"Ich Selbst" <ic...@gmx.ch> writes:
>>
>>
>>>I suggest a patch to enable clients to use their own
>>>registry base - that way the settings like proxy, path
>>>to diff and diff3 and the like can be handled on a client
>>>basis.
>>>
>>>
>>A compile time option for this seems of minimal benefit, but maybe I'm
>>just not understanding the scenario here. What is the problem you
>>encountered?
>>
>>
>
>I don't have a problem (this time :)
>
Bah.
> - 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?
> 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.
>And since that change belongs to the really small ones I thought it would
>be a good idea.
>
>
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.
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.
--
Brane Čibej <br...@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
Re: patch suggestion
Posted by Ich Selbst <ic...@gmx.ch>.
> "Ich Selbst" <ic...@gmx.ch> writes:
> > I suggest a patch to enable clients to use their own
> > registry base - that way the settings like proxy, path
> > to diff and diff3 and the like can be handled on a client
> > basis.
>
> A compile time option for this seems of minimal benefit, but maybe I'm
> just not understanding the scenario here. What is the problem you
> encountered?
I don't have a problem (this time :) - 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 or the
client
has a built-in diff/diff3 or ...
And since that change belongs to the really small ones I thought it would
be a good idea.
Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org