On Tue, Nov 6, 2012 at 11:20 AM, Julian Foad <julianfoad_at_btopenworld.com> wrote:
> C. Michael Pilato wrote:
>
>> On 11/06/2012 10:29 AM, Julian Foad wrote:
>>>>> Sorry, that section is out of date, I corrected it. The
>>>>> --no-ignores option still works for status, it's only for
>>>>> import and add that it can't be overridden.
>>>>
>>>> Perfect, thanks. I think not-overriding for add/import is fine: for
>>>> 'import' only the repository files are affected, and for 'add' files
>>>> matching the pattern can be specified explicitly in the argv targets
>>>> (and auto-props added can be modified or stripped after 'add' and
>>>> before 'commit').
>>>
>>> Am I the only one going "Eww!" on reading this?
>>>
>>> We have three ways of specifying ignores, and we have an option that
>>> disregards them, only in one cammand it disregards all of the ways and in
>>> two other commands the option only disregards two of the ways. And we
>>> say "sure, that sounds perfect". It doesn't sound fine to me, it sounds
>>> horrible.
Hi Julian,
I think you are making this out to sound worse than it is. Yes there
are three ways to specify ignores. So what? How many ways are there
to add a file to a repository? Import, copy, commit, oh my, it's so
terribly confusing! (Please take this as the light hearted jest it's
meant to be ;-)
You previously proposed trying to combine svn:global-ignores with
svn:ignore in a different thread and nobody else agreed, so if that is
still a concern for you then let's move that topic to another thread.
As to the current behavior where "in one command it disregards all of
the ways and in two other commands the option only disregards two of
the ways". All I can say is that whatever we chose to do, I can't
imagine anyone arguing that the "one command" we are taking about here
('svn status') should do anything other than report *all* ignored
paths, so that's really not up for debate IMO.
So your sole objection (I think?) is to the fact that
svn:global-ignores cannot be ignored during adds or imports, right?
If so that is a totally legitimate concern. Read on for how I ended
up with that solution...
>> I would be in favor of --no-ignores working identically across all the
>> subcommands. I understand the arguments for "add" and
>> "import" not allowing
>> the override, so I don't fault Paul for choosing the current arrangement.
>
> Oh, I don't recall such arguments. I was particularly baffled because what was written above in this thread seemed to assume that the need for inconsistency is self-evident.
The inheritable props, svn:global-ignores, and svn:auto-props work all
came about as an alternative to the Server Dictated Configuration
effort that Mike and I had toyed around with earlier this year
(http://wiki.apache.org/subversion/ServerDictatedConfiguration). The
idea of SDC was that repository administrators could set some hard and
fast rules that could only be violated by a custom hacked client
(http://wiki.apache.org/subversion/ServerDictatedConfiguration#Behavioral_specification).
So that idea carried over to the alternative solution with inherited
properties. The assumption on my part has been that if a repos admin
sets svn:global-ignores on, say the root of their repos, then it means
they are *really* serious about keeping those files out of their
repos.
Also keep in mind that if you really want to add an ignored file you
can make the file the target of the 'svn add' command. Just like with
the runtime config global-ignores and the svn:ignore property in 1.7,
if the file in question is the explicit target of an add subcommand,
it will be added, no need for . Import works the same way.
>> But I've not been a huge fan of the idea of "server-dictated
>> configuration" anyway, being more in favor of "repos-default
>> configuration" or somesuch that doesn't pretend to be the
>> final word on anything. With or without this feature in place,
>> enforcement of ignores (and auto-props, for that matter) can
>> only happen in the hook scripts, anyway, so I don't see the harm in
>> allowing a user to specify --no-ignores if his or her admin doesn't
>> care enough to enforce that the default configuration is honored.
>
> Right, +1 there.
Well the beauty is that 1.8 isn't released yet! So I can change this
easily enough. If I'm the lone voice in the wilderness on this then
I'm happy to switch it so that --no-ignore works the same for
svn:global-ignores as it does for the runtime config global-ignores
and svn:ignore.
> - Julian
Received on 2012-11-06 18:02:29 CET