You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Stephen Warren <sw...@paramanet.com> on 2004/03/31 00:45:35 UTC
Configuration area in the repository
I see that there's a configuration area for each machine (e.g. /etc/...) and in the user's home directory.
It would be nice to have one per-server, or per repository (better, and probably simpler) too.
The reason being: I want to set global-ignores, and automatic property settings (e.g. mime-type) *but* I don't want to force developers to manually keep their configuration areas up to date.
This could work by having a special set of properties on the root of the repository, or having a special directory at the root of the repository. The format of data here would match existing configuration areas. This data would be placed into the working-copy on each update, just like anything else.
Probably the system and per-user configuration areas would over-ride repository settings?
Is this a good idea? How else might one accomplish this? I thought of post commit triggers, but they can't modify the transaction, and I don't think server-side propsets are implemented yet (and besides, that would just run the post-commit hook again this causing an endless loop, wouldn't it?)
--
Stephen Warren, Software Engineer, Parama Networks, San Jose, CA
http://www.wwwdotorg.org/work_contact/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Configuration area in the repository
Posted by Dominic Anello <da...@danky.com>.
On 2004-03-31 21:27:26 +0200, Lele Gaifax wrote:
> >>>>> "Dominic" == Dominic Anello <da...@danky.com> writes:
>
> Dominic> Sorry if this has been proposed before, but what about
> Dominic> making the per-repo config a property (eg svn:config) of
> Dominic> the repo root directory? Then you wouldn't have to worry
> Dominic> about collisions with local files.
>
> A viable alternative, although this only allow to /mandate/ some
> settings, since a property have to be committed and this imply that
> everyone's forced to use those settings within that context. As for
> the API, "svn propedit" is already there :-)
>
> OTOH, it suffers of the same problem raised by John, ie how to "spread
> down" the settings so that a user that checks out just a portion of
> the repository will acquire the same options.
Handle it like auth caching is currently handled. It could be placed in
~/.subversion/conf/<repo-uuid>.
Then it just becomes part of the merged config tree:
command line switches -> ~/.subversion/config
-> ~/.subversion/conf/<repo-uuid> -> /etc/subversion/config
Where "->" means "overrides". I think the main hurdle would be that
there would need to be some method to tell the client it needs to update
its per-repo config.
Security would probably have to be handled by a pre-commit hook - only
allow "admin" users to commit changes to svn:config.
--
So, I've made peace with the falling leaves. I see their same fate in
my own body. But I won't be frightened when I am awoken from this dream
and returned to that which gave birth to me.
-Bright Eyes, "Method Acting"
Re: Configuration area in the repository
Posted by Lele Gaifax <le...@nautilus.homeip.net>.
>>>>> "Dominic" == Dominic Anello <da...@danky.com> writes:
Dominic> Sorry if this has been proposed before, but what about
Dominic> making the per-repo config a property (eg svn:config) of
Dominic> the repo root directory? Then you wouldn't have to worry
Dominic> about collisions with local files.
A viable alternative, although this only allow to /mandate/ some
settings, since a property have to be committed and this imply that
everyone's forced to use those settings within that context. As for
the API, "svn propedit" is already there :-)
OTOH, it suffers of the same problem raised by John, ie how to "spread
down" the settings so that a user that checks out just a portion of
the repository will acquire the same options.
ciao, lele.
--
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
email: lele@seldati.it | -- Fortunato Depero, 1929.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Configuration area in the repository
Posted by Dominic Anello <da...@danky.com>.
On 2004-03-31 09:21:25 -0500, John Peacock wrote:
----8<----
> There is also the issue of Namespace collision in the repository. If I
> decide to place my entire home directory under version control (not unheard
> of), your proposed './.subversion' will collide with the existing
> '~/.subversion' directory. This is not a killer problem, but the code
> would have to deal with the fact that in this case the local /directory/
> config and the local /user/ config are one and the same.
Sorry if this has been proposed before, but what about making the
per-repo config a property (eg svn:config) of the repo root directory?
Then you wouldn't have to worry about collisions with local files.
-Dominic
----8<----
Re: Configuration area in the repository
Posted by Lele Gaifax <le...@nautilus.homeip.net>.
>>>>> "John" == John Peacock <jp...@rowman.com> writes:
John> By what you are saying here, you expect the
John> directory-resident config files to be used _instead of_ any
John> user homedir config settings. I know that there are people
John> who would chafe at that restriction.
That's a matter of implementation. I can imagine an hypothetical
/3rd/.subversion/config file containing::
[miscellany]
overrides-defaults-in-same-section-of-file = ~/.subversion/config
use-commit-times = no
enable-auto-props = no
or something similar.
BTW, in a previous message you talked about keeping the homedir under
version control (as I do :): this fits perfectly with my view, since
by definition from my homedir down I'd expect my ~/.subversion
settings honored, though I'd override it under my "~/work-in-progress"
directory, that may be filled with other-repos working copies, with
their own policies...
John> You are also introducing some edge cases that I don't think
John> you have considered. Specifically, a user is able to check
John> out a "project" at any point in the tree. So for example, I
John> check out http://.../trunk/docs to work on (pretend I'm a
John> documentation specialist). However, the site admin placed a
John> directory-based config file at http://.../trunk that I
John> should also be getting. As far as the client code is
John> concerned, my WC root folder is /docs. Do you suggest that
John> client search all the way up, against the repository, for
John> possible config settings? How does this work with
John> disconnected operations?
I see, that's right. But this is not a singularity of this proposal,
since I suppose that in the same situation, the same problem would
occur, even with a repos-centric solution: you surely would like that
in some way, at checkout/update time, your client could query the
server for the equivalent information, maintaining at the same time _a
local cache_. Yes, you can store it in the already existing .svn
metadata dir, but then I guess somebody will ask for an API to manage
that information, since the .svn content is even (and right so!)
read-only...
thanx,
ciao, lele.
--
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
email: lele@seldati.it | -- Fortunato Depero, 1929.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Configuration area in the repository
Posted by John Peacock <jp...@rowman.com>.
Lele Gaifax wrote:
> John> Your method would require that I add possibly duplicated
> John> .subversion folders to each and every directory in a
> John> potentially very large project.
>
> Uhm, not exactly: I meant the same, ie, putting the settings for
> example under /trunk would affect everything below that point, no need
> to duplicate it in every subdirectory. This of course means that the
> svn_client layer should walk up the tree to find out the nearest
> settings folder: failing that, it should behave as now, ie reading
> from ~/.subversion/.
You are adding [much] more complexity to the client by doing that. By what you
are saying here, you expect the directory-resident config files to be used
_instead of_ any user homedir config settings. I know that there are people who
would chafe at that restriction. Personally, I would expect the config files
would be additive, with the user ~/.subversion stanzas overriding any other for
a simplistic system. With more sophisticated inheritance code in place, I would
also expect that certain configuration settings could be locked at the
repository level, and others would be overrideable locally.
You are also introducing some edge cases that I don't think you have considered.
Specifically, a user is able to check out a "project" at any point in the
tree. So for example, I check out http://.../trunk/docs to work on (pretend I'm
a documentation specialist). However, the site admin placed a directory-based
config file at http://.../trunk that I should also be getting. As far as the
client code is concerned, my WC root folder is /docs. Do you suggest that
client search all the way up, against the repository, for possible config
settings? How does this work with disconnected operations?
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Configuration area in the repository
Posted by Lele Gaifax <le...@nautilus.homeip.net>.
>>>>> "John" == John Peacock <jp...@rowman.com> writes:
John> 1) Initialization - is the global config used when creating
>> Uh? My proposal simply add a new place to look for settings,
>> that is look also in './.subversion' after '~/.subversion'.
>> The suggested approach has several advantages over a
>> per-repository new conf/ setting.
John> Then you can take away the discussion that your proposal was
John> not clear (to me at least ;) as to what you were actually
John> proposing.
Sorry, but English is not my native tongue. As said, I was chatting
with Ben when I submitted the issue, and it was (apparently) clear to
him.
John> 2) Collision - are repository-wide settings additive with
John> user config, or do the globals trump the user settings (or
John> more likely vice versa).
>> The proposal is an /alternative/ to having such repos-wide
>> settings.
John> You still have to deal with the possibility of the same
John> settings in both locations and how they interact. In my
John> mind, this is a far more important part of the design
John> discussion than the actual location of the additional config
John> stanzas.
John> There is also the issue of Namespace collision in the
John> repository. If I decide to place my entire home directory
John> under version control (not unheard of), your proposed
John> './.subversion' will collide with the existing
John> '~/.subversion' directory. This is not a killer problem,
John> but the code would have to deal with the fact that in this
John> case the local /directory/ config and the local /user/
John> config are one and the same.
Well, I think that the very same problem will raise, any how you
decide to tackle the issue. I mean, in every way there will be a
chance that the repos-wide settings collide with the user-owned ones
in its ~/.subversion/, doesn't it?
John> Additionally, there are existing issues with Win32
John> development (specifically Visual Studio Web projects) when a
John> directory or file starts with a period (only an extension
John> and no filename). Given that it is already a problem to
John> have .svn, it would not be good to then go ahead and add yet
John> another problem case. The Win32 people are very sensitive
John> to perceived slights of their worldwide dominance. ;~0
That is another story: the solution to the '.svn' dilemma on win32 can
be applied to the '.subversion' folder. When there will be the
possibility of keeping wc metadata out of the working dir, by any
change there will be a mechanism to store "per-directory" information
somewhere else in place. The very same mechanism could then be used
to store "that-directory-auto-props-settings", for example.
John> I'm not even sure where you intend the './.subversion' file
John> to be located. No, *each* subdirectory of a repository
>> may contain the .subversion
John> ^^^^^^^^^^ You mean Working
John> Copy here, right?
Yes, of course.
>> settings folder, that applies on the containing directory and
>> its subtree. This way you can get different policies in
>> different part of the repository.
John> ^^^^^^^^^^ Again, you are proposing a WC-centric
John> configuration file, that just may be stored in the
John> repository sometimes.
Yes, sorry for the confusion. To make it clear, my proposal touches
*only* the client-side of the matter.
John> I have to say that I would not find this (directory centric
John> configs) as useful as, for example, a property associated
John> with a containing directory. In both cases, to do it right
John> would involve the tough discussion of inheritance and
John> collision. I would rather set the project-centric
John> configuration once at the top level of the project (as a
John> property), and have that inherited by the entire project.
John> Your method would require that I add possibly duplicated
John> .subversion folders to each and every directory in a
John> potentially very large project.
Uhm, not exactly: I meant the same, ie, putting the settings for
example under /trunk would affect everything below that point, no need
to duplicate it in every subdirectory. This of course means that the
svn_client layer should walk up the tree to find out the nearest
settings folder: failing that, it should behave as now, ie reading
from ~/.subversion/.
The admin will the be free to impose or not particular settings in
different areas of the repository, and the single developers too, to
some degree. As said, I keep under SVN several third-party software
(think at Plone and all the related material, that come from various
SF.net CVS repositories). I'd like to be able to say "under /3rd do
not *ever* apply svn keywords, keep the upstream CVS ones, but do
activate them all under /trunk, that host my own applications and
customizations". With a repository-centric approach, this would be
impossible, as it is now.
thanx&bye, lele.
--
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
email: lele@seldati.it | -- Fortunato Depero, 1929.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Configuration area in the repository
Posted by John Peacock <jp...@rowman.com>.
Lele Gaifax wrote:
> John, I do know the matter, and I even chatted with Ben and others
> before issueing it. Ben said that at one point he will create a
> meta-issue to collect these ideas.
That's good. Since I am working on a custom Properties patch, I may be a little
more sensitive to the issues involved.
> John> 1) Initialization - is the global config used when creating
>
> Uh? My proposal simply add a new place to look for settings, that is
> look also in './.subversion' after '~/.subversion'. The suggested
> approach has several advantages over a per-repository new conf/
> setting.
Then you can take away the discussion that your proposal was not clear (to me at
least ;) as to what you were actually proposing.
>
> John> 2) Collision - are repository-wide settings additive with
> John> user config, or do the globals trump the user settings (or
> John> more likely vice versa).
>
> The proposal is an /alternative/ to having such repos-wide settings.
You still have to deal with the possibility of the same settings in both
locations and how they interact. In my mind, this is a far more important part
of the design discussion than the actual location of the additional config stanzas.
There is also the issue of Namespace collision in the repository. If I decide
to place my entire home directory under version control (not unheard of), your
proposed './.subversion' will collide with the existing '~/.subversion'
directory. This is not a killer problem, but the code would have to deal with
the fact that in this case the local /directory/ config and the local /user/
config are one and the same.
Additionally, there are existing issues with Win32 development (specifically
Visual Studio Web projects) when a directory or file starts with a period (only
an extension and no filename). Given that it is already a problem to have .svn,
it would not be good to then go ahead and add yet another problem case. The
Win32 people are very sensitive to perceived slights of their worldwide
dominance. ;~0
>
> John> I'm not even sure where you intend the './.subversion' file
> John> to be located.
>
> No, *each* subdirectory of a repository may contain the .subversion
^^^^^^^^^^
You mean Working Copy here, right?
> settings folder, that applies on the containing directory and its
> subtree. This way you can get different policies in different part of
> the repository.
^^^^^^^^^^
Again, you are proposing a WC-centric configuration file, that just may be
stored in the repository sometimes.
I have to say that I would not find this (directory centric configs) as useful
as, for example, a property associated with a containing directory. In both
cases, to do it right would involve the tough discussion of inheritance and
collision. I would rather set the project-centric configuration once at the top
level of the project (as a property), and have that inherited by the entire
project. Your method would require that I add possibly duplicated .subversion
folders to each and every directory in a potentially very large project.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Configuration area in the repository
Posted by Lele Gaifax <le...@nautilus.homeip.net>.
>>>>> "John" == John Peacock <jp...@rowman.com> writes:
John> Lele Gaifax wrote:
>> I opened an enhancement issue on the subject, see
>> http://subversion.tigris.org/issues/show_bug.cgi?id=1813
John> The generally accepted practice on this project is to not
John> create issues without discussing the subject on the dev list
John> first (this is different than lots of projects). In this
John> case, the need for repository-wide configuration files is
John> well known, and impacts a number of existing proposed
John> features, see #890 in addition to 1002 (which you mention).
John> There are others, I am sure.
John, I do know the matter, and I even chatted with Ben and others
before issueing it. Ben said that at one point he will create a
meta-issue to collect these ideas.
John> In specific, your proposed solution is not that helpful
John> because you don't deal with several issues inherent in the
John> topic:
John> 1) Initialization - is the global config used when creating
John> the user's local configuration? This is one facet of
John> Subversion which others have noted is very annoying to have
John> hardcoded in the binary instead of configurable. This kind
John> of repository-defaults should probably be stored in conf/
John> somewhere.
Uh? My proposal simply add a new place to look for settings, that is
look also in './.subversion' after '~/.subversion'. The suggested
approach has several advantages over a per-repository new conf/
setting.
John> 2) Collision - are repository-wide settings additive with
John> user config, or do the globals trump the user settings (or
John> more likely vice versa).
The proposal is an /alternative/ to having such repos-wide settings.
John> 3) Updates - if the repository-wide settings are updated,
John> how is that communicated to the client?
In fact, this is why I think my idea is much simpler and as effective
as the repos-wide one, without requiring additional code to transfer
to/from the server another config file.
John> 4) Mixed WC's - if you are proposing storing
John> repository-specific defaults, how to you handle working
John> copies with svn:external links to other repositories. There
John> are inheritance issues here, too.
No, each directory could contain its own .subversion folder, and the
developers are free to put it under revision control or not.
John> I'm not even sure where you intend the './.subversion' file
John> to be located. That is a relative path, but you don't say
John> where it is relative to; I'm assuming you are talking about
John> the repository root (i.e. in the repository itself). If so,
John> there is no point in using the special ".subversion"
John> filename, since that is an artifact of *nix filesystem
John> semantics (hidden file) which has no [current] special
John> handling within the Subversion filesystem code.
No, *each* subdirectory of a repository may contain the .subversion
settings folder, that applies on the containing directory and its
subtree. This way you can get different policies in different part of
the repository. For example, mine have a '/3rd/' tree that contains
external software synced tipically with some sourceforge.net CVS
repository: for obvious reasons, I do not want SVN properties be
active there and below, while it would be nice if in the other trees
(say, '/mine/trunk') I could activate auto-props.
John> I'm not trying to dissuade you from making suggestions, just
John> pointing out that the issue has been considered before, and
John> it is much more complex than might be initially obvious.
Ya, of course. That's the main reasoning behind making an issue out
of it.
thanx,
bye, lele.
--
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
email: lele@seldati.it | -- Fortunato Depero, 1929.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Configuration area in the repository
Posted by John Peacock <jp...@rowman.com>.
Lele Gaifax wrote:
> I opened an enhancement issue on the subject, see
> http://subversion.tigris.org/issues/show_bug.cgi?id=1813
The generally accepted practice on this project is to not create issues without
discussing the subject on the dev list first (this is different than lots of
projects). In this case, the need for repository-wide configuration files is
well known, and impacts a number of existing proposed features, see #890 in
addition to 1002 (which you mention). There are others, I am sure.
In specific, your proposed solution is not that helpful because you don't deal
with several issues inherent in the topic:
1) Initialization - is the global config used when creating the user's local
configuration? This is one facet of Subversion which others have noted is very
annoying to have hardcoded in the binary instead of configurable. This kind of
repository-defaults should probably be stored in conf/ somewhere.
2) Collision - are repository-wide settings additive with user config, or do the
globals trump the user settings (or more likely vice versa).
3) Updates - if the repository-wide settings are updated, how is that
communicated to the client?
4) Mixed WC's - if you are proposing storing repository-specific defaults, how
to you handle working copies with svn:external links to other repositories.
There are inheritance issues here, too.
I'm not even sure where you intend the './.subversion' file to be located. That
is a relative path, but you don't say where it is relative to; I'm assuming you
are talking about the repository root (i.e. in the repository itself). If so,
there is no point in using the special ".subversion" filename, since that is an
artifact of *nix filesystem semantics (hidden file) which has no [current]
special handling within the Subversion filesystem code.
I'm not trying to dissuade you from making suggestions, just pointing out that
the issue has been considered before, and it is much more complex than might be
initially obvious.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Configuration area in the repository
Posted by Lele Gaifax <le...@nautilus.homeip.net>.
>>>>> "Stephen" == Stephen Warren <sw...@paramanet.com> writes:
Stephen> It would be nice to have one per-server, or per
Stephen> repository (better, and probably simpler) too.
I opened an enhancement issue on the subject, see
http://subversion.tigris.org/issues/show_bug.cgi?id=1813
ciao, lele.
--
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
email: lele@seldati.it | -- Fortunato Depero, 1929.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [Issue 1813] Using ./.subversion, if it exists, to override/augment ~/.subversion settings
Posted by kf...@collab.net.
Lele Gaifax <le...@nautilus.homeip.net> writes:
> kfogel> But if we can't get some context into that issue tracker,
> kfogel> we have a problem. Let's try to solve it...
>
> Wandering around I discovered I needed the observer role to reopen the
> issue and be able to add the context. Hopefully it's fixed now.
Thanks!
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Issue 1813] Using ./.subversion, if it exists, to override/augment ~/.subversion settings
Posted by Lele Gaifax <le...@nautilus.homeip.net>.
>>>>> "kfogel" == kfogel <kf...@collab.net> writes:
kfogel> But if we can't get some context into that issue tracker,
kfogel> we have a problem. Let's try to solve it...
Wandering around I discovered I needed the observer role to reopen the
issue and be able to add the context. Hopefully it's fixed now.
hth,
ciao, lele.
--
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
email: lele@seldati.it | -- Fortunato Depero, 1929.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Issue 1813] Using ./.subversion, if it exists, to override/augment ~/.subversion settings
Posted by kf...@collab.net.
Lele Gaifax <le...@nautilus.homeip.net> writes:
> kfogel> Or, if there *is* a mailing list thread on this, reopen
> kfogel> this issue and link to it.
> >> Uhm, *can* I actually do that?
>
> kfogel> Uhm, yes, otherwise I wouldn't have asked. Did you try?
>
> Uhm, yes, otherwise I wouldn't have asked.
Then, please don't just ask "*can* I actually do that?" and give no
more information. Instead, describe what you tried to do and how it
didn't work. The issue tracker should allow you to add comments to
any issue, if you're logged in, and clearly you were at some point,
because you filed the issue.
There was no way for me to tell from your sentence what you tried to
do and/or what went wrong. But if we can't get some context into that
issue tracker, we have a problem. Let's try to solve it...
Thanks,
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Issue 1813] Using ./.subversion, if it exists, to override/augment ~/.subversion settings
Posted by Lele Gaifax <le...@nautilus.homeip.net>.
>>>>> "kfogel" == kfogel <kf...@collab.net> writes:
kfogel> Notice the big yellow box with text near the top, and see
kfogel> the third bulleted item in that box.
Yes, and it seems I did followed it, didn't I?
kfogel> Or, if there *is* a mailing list thread on this, reopen
kfogel> this issue and link to it.
>> Uhm, *can* I actually do that?
kfogel> Uhm, yes, otherwise I wouldn't have asked. Did you try?
Uhm, yes, otherwise I wouldn't have asked.
>> So, again, if it's a stupid idea, say that, and I'll be happy.
>> But before that, spend a few seconds to think about it, because
>> even if evidently *others* have done that before you, this
>> should not interfere with its goodness/badness ratio.
kfogel> You have no idea how many seconds (or more) I spent
kfogel> thinking about it before I asked for more context, so
kfogel> please don't make guesses.
As I have an exact idea of the amount of time I devoted to this issue,
and yet I did not hear anything sensible about it, I guess it's got
its chance.
kfogel> If you'll just include the context the first time, this
kfogel> won't happen. (And if you forget to, that's fine, but
kfogel> don't complain that you've been done an injustice, just
kfogel> because someone asks you to follow the clear & posted
kfogel> issue tracker guidelines :-) ).
That was *not* my complain, btw.
ciao, lele.
--
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
email: lele@seldati.it | -- Fortunato Depero, 1929.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Issue 1813] Using ./.subversion, if it exists, to override/augment ~/.subversion settings
Posted by kf...@collab.net.
Lele Gaifax <le...@nautilus.homeip.net> writes:
> kfogel> http://subversion.tigris.org/issues/show_bug.cgi?id=1813
>
> kfogel> We generally prefer to discuss new ideas on the mailing
> kfogel> lists, then summarize the conclusions in the issue tracker
> kfogel> (with pointers to the mailing list thread, of course).
> kfogel> This is so the issue tracker remains more or less a todo
> kfogel> list, instead of being a discussion forum, since it's not
> kfogel> well-suited technically for the latter.
>
> Pardon me, but while I wished for better arguments to justify
> status'ing it Resolved, as already said in this ML (see below), I
> *did* talk about that both on IRC and on ML, and you are the second
> person that instead of making a point, or see if others can take
> advantage of an idea (or not!-) just drop it because "we didn't talk
> /there/ about /this/": maybe this should be made clear before letting
> one submit a new issue, but, imho, one should never assume that "since
> I never heard of it, it must not be relevant".
No, you misunderstood what I wrote.
You opened an issue about a discussion that took place on mailing
lists / in IRC... but you attached none of that context to the issue!
Therefore, I had no way to know that there *was* any such context.
So I closed the issue, asking for discussion first, but also said if
the discussion had already been had, to please reopen with pointers to
the correct archives.
And, since you mention it, this policy *is* "made clear", right on the
front page of the issue tracker:
http://subversion.tigris.org/project_issues.html
Notice the big yellow box with text near the top, and see the third
bulleted item in that box.
> Anyway...
>
> kfogel> Can you take this idea to dev@subversion.tigris.org?
>
> Here I am :-)
Yes, thank you.
> kfogel> Or, if there *is* a mailing list thread on this, reopen
> kfogel> this issue and link to it.
>
> Uhm, *can* I actually do that?
Uhm, yes, otherwise I wouldn't have asked. Did you try?
> See these messages:
>
> [...]
>
> And browse this "focusnipped" chat on #svn, 29/03/2004 23:15:05 CET:
>
> [...]
Yes, this is exactly the stuff I was asking for you to put in the
issue when you reopen it. Can you do that? Thanks.
> So, again, if it's a stupid idea, say that, and I'll be happy. But
> before that, spend a few seconds to think about it, because even if
> evidently *others* have done that before you, this should not
> interfere with its goodness/badness ratio.
You have no idea how many seconds (or more) I spent thinking about it
before I asked for more context, so please don't make guesses.
If you'll just include the context the first time, this won't happen.
(And if you forget to, that's fine, but don't complain that you've
been done an injustice, just because someone asks you to follow the
clear & posted issue tracker guidelines :-) ).
Thanks,
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Issue 1813] Using ./.subversion, if it exists, to override/augment ~/.subversion settings
Posted by Lele Gaifax <le...@nautilus.homeip.net>.
>>>>> "kfogel" == kfogel <kf...@tigris.org> writes:
kfogel> http://subversion.tigris.org/issues/show_bug.cgi?id=1813
kfogel> We generally prefer to discuss new ideas on the mailing
kfogel> lists, then summarize the conclusions in the issue tracker
kfogel> (with pointers to the mailing list thread, of course).
kfogel> This is so the issue tracker remains more or less a todo
kfogel> list, instead of being a discussion forum, since it's not
kfogel> well-suited technically for the latter.
Pardon me, but while I wished for better arguments to justify
status'ing it Resolved, as already said in this ML (see below), I
*did* talk about that both on IRC and on ML, and you are the second
person that instead of making a point, or see if others can take
advantage of an idea (or not!-) just drop it because "we didn't talk
/there/ about /this/": maybe this should be made clear before letting
one submit a new issue, but, imho, one should never assume that "since
I never heard of it, it must not be relevant".
Anyway...
kfogel> Can you take this idea to dev@subversion.tigris.org?
Here I am :-)
kfogel> Or, if there *is* a mailing list thread on this, reopen
kfogel> this issue and link to it.
Uhm, *can* I actually do that?
See these messages:
http://subversion.tigris.org/servlets/ReadMsg?list=users&msgNo=9014
http://subversion.tigris.org/servlets/BrowseList?list=users&by=thread&from=173343
And browse this "focusnipped" chat on #svn, 29/03/2004 23:15:05 CET:
<lelit> hi all, reading back about autoprops... what do you think about looking them up in a ./.subversion in place/in addendum to ~/.subversion?
<sussman> why is that better?
<lelit> per project instead of per developer?
<lelit> versionable?
<sussman> better to just put the configuration in the repository in the repository itself, no?
<sussman> if you want it to be per project
<lelit> definitively much more controllable than the current situation, where most of the time I'm adding --no-auto-props
<sussman> huh?
<lelit> I do not understand what you mean... how can I put there the auto-props?
<sussman> you can't
<sussman> but most people have agreed that the "next step" for auto-props is to make it a repository configuration, rather than a client one.
<dionisos> maybe it's time to make that wishlist somewhat more explicit. Is this in the issue tracker?
<lelit> ah. ok, that's great. But couldn't my idea be a simpler approach to the same goal?
<dionisos> lelit: then it's still a per-developer thing. normally you want consistency for one repository.
<lelit> why? I can see a /trunk/projectA/.subversion, shared with all developers of projectA, doesn't it?
<dionisos> hm; that's just one way to implement it for a repository (or part thereof) I guess.
<lelit> Then whatever *below* that point, could /acquire/ those settings...
<lelit> dionisos: yes, maybe simpler :)
<dionisos> lelit: simple should not be the deciding factor. Well-thought-out can.
<lelit> I ack that, of course.
<dionisos> so it takes some more time to become available....
<lelit> I was simply proposing it...
<sussman> lelit: perhaps you should add the suggestion to the auto-props feature request. dionisos, does that enhancement issue exist already? it might.
<sussman> it might simply be blocking on having a repository config system.
<dionisos> I was in the issue tracker, but did not know what to search for :-)
<lelit> sussman: sure, given an issue # :)
<dionisos> sussman: possibly http://subversion.tigris.org/issues/show_bug.cgi?id=1002
<dionisos> though it could be stated somewhat broader...
<lelit> dionisos: yes, but the reasoning above may be adeguate for that issue too...
<sussman> dionisos: I think we need a meta-feature issue to create an "in repos" config system
<sussman> and then make a bunch of other issues block on it.
<dionisos> sussman: right
<lelit> so what? Should I comment issue 1002, open a new one, or wait for the meta-feature?
<dionisos> lelit: I think you can open a new issue. I can add the meta-issue later.
<lelit> ok
<lelit> sussman: see issue #1813, does it make sense?
<sussman> sure, makes sense
So, again, if it's a stupid idea, say that, and I'll be happy. But
before that, spend a few seconds to think about it, because even if
evidently *others* have done that before you, this should not
interfere with its goodness/badness ratio.
hth,
ciao, lele.
--
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
email: lele@seldati.it | -- Fortunato Depero, 1929.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org