[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: disregarding svn:global-ignores

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Tue, 6 Nov 2012 10:43:04 -0500

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.

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

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Enterprise Cloud Development

Received on 2012-11-06 16:43:41 CET

This is an archived mail posted to the Subversion Dev mailing list.