Re: disregarding svn:global-ignores
From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Tue, 6 Nov 2012 18:16:08 +0000 (GMT)
Paul Burba wrote:
> On Tue, Nov 6, 2012 at 11:20 AM, Julian Foad wrote:
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
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
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
Yes, that's my my main concern.
>>> I would be in favor of --no-ignores working identically across
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
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;
* 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
Great. I hope my argument makes more sense to you and others now I've used a few more words (did someone say 'rant'?).
This is an archived mail posted to the Subversion Dev mailing list.