Re: disregarding svn:global-ignores

Paul Burba wrote:

> On Tue, Nov 6, 2012 at 11:20 AM, Julian Foad 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 ...
>>>>
>>>> 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?  [...]

I didn't mean here to emphasize that there are three ways.  The same applies if there are only two.

> 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.

I accept the majority decision on that point -- that's no longer my concern.

> 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.

Well, on this preliminary point, 'svn status --no-ignore' should certainly report all ignored paths *if* other commands do too.  If they don't, I might well feel that consistency among commands should trump the assumption that 'svn status --no-ignore' should report all paths.  But we're not at that point yet.

> 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...

Yes, that's my my main concern.

>>> 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.

That original intent is just one of several use cases for inherited props.  The current design is not strongly tied to achieving that particular goal: it doesn't have any features that specifically relate to that use case, except these proposed exceptions to the --no-ignores option.

What we're ending up with is a feature that grants people an easier way to configure the very same kind of functionality that they already had (with respect to ignores).  Once this is rolled out, people will set svn:global-ignores wherever they have file patterns they don't want to be versioned in a directory tree, not just when they're "really serious".

> 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.

Well, quite!  That's consistent among all ways of specifying ignores.  Doesn't that tell us that the inherited property is not considered so special after all.  If we wanted it to be so special, we'd want to make the property override this rule as well.

Here's another perspective.  Picture a user with a fairly simple project, not much need for ignores at all to begin with.  Then they want to ignore '*.log' in their project-root directory.  Faced with the option of putting this in 'svn:ignore' or in 'svn:global-ignores', which do they choose.  Reality, they choose one or the other on a whim, unless we make it really clear that one is somehow different from the other.  And how are we going to do that?  It's not enough to describe the differences subcommand-by-subcommand; to make a clear statement we would need a system-level statement that says something like "We have a two-tier system for ignoring unwanted files; svn:ignore specifies user preferences, while svn:global-ignores specifies mandatory exclusions and of course overrides svn:ignore and is enforced by the server".  Or something.

So basically I'm saying our two sensible design options are:

  * the difference between svn:ignore and svn:global-ignores is that the latter is inherited;

or

  * there is a major distinction between svn:ignore and svn:global-ignores (which is: ... something).

No middle ground.

If we try to make it mean two things at once -- meaning "inheritable" and "specially enforced" -- then we're unnecessarily conflating two independent needs.  Instead those two meanings should be orthogonal.  If we want a "specially enforced" option, it should not be tied to "inheritable".

>>> 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.

Great.  I hope my argument makes more sense to you and others now I've used a few more words (did someone say 'rant'?).

- Julian
Received on 2012-11-06 19:16:46 CET