Re: Do we expect default ignores when no ignores are defined

On Fri, Jan 11, 2013 at 3:46 PM, Bert Huijben <bert_at_vmoo.com> wrote:
> anywhere?
> MIME-Version: 1.0
> Content-Type: text/plain; charset="utf-8"
> Content-Transfer-Encoding: 7bit
>
> We inherit from per machine settings that may or may not exist. This
> allows overriding in all layers (2 on UNIX, 4 on Windows) while still
> having some default.

Hey Bert,

The override behavior and the default behavior are separate concepts.
I'm not sure what this has to do with overriding the various layers of
config. I'm not suggesting a change to that behavior or that there is
anything wrong with it!

I'm merely pointing out that the current behavior regarding the
*default* is bizarre IMO. I could have the global-ignores option
*purposefully* commented out/not-present in all four Windows configs
because I don't want to ignore anything, but Subversion tries to
outwit me and assumes the default. Seems completely
wrong/counter-intuitive to me.

Look at it this way: Assume we only have the per-user config present.
You don't find it odd that these two config files behave differently?

[[[
[miscellany]
# Hey, I don't want to ignore anything, so comment out the default!
# global-ignores = *.o *.lo *.la *.al .libs *.so *.so.[0-9]* *.a *.pyc
*.pyo __pycache__ *.rej *~ #*# .#* .*.swp .DS_Store
]]]

[[[
[miscellany]
# Hey, I don't want to ignore anything, so set global-ignores to an empty val!
global-ignores =
]]]

Probably the only reason this has probably never come up is because
our default ignores list is very conservative. And that's also why
I'm not to worried about this either way, it just burnt me today while
testing ignore stuffs -- but I've learned my lesson :-)

--
Paul T. Burba
CollabNet, Inc. -- www.collab.net -- Enterprise Cloud Development
Skype: ptburba
> I don't think we can really change that for 1.x.
>
> Bert Huijben (Cell phone)
> From: Paul Burba
> Sent: 11-1-2013 21:36
> To: Subversion Development
> Subject: Do we expect default ignores when no ignores are defined
> anywhere?
> I was a bit surprised to learn today that if one has no global-ignore
> options defined in any of the run-time configs, then Subversion
> assumes a default value of "*.o *.lo *.la *.al .libs *.so *.so.[0-9]*
> *.a *.pyc *.pyo __pycache__ *.rej *~ #*# .#* .*.swp .DS_Store":
>
> svn_error_t *
> svn_wc_get_default_ignores(apr_array_header_t **patterns,
>                            apr_hash_t *config,
>                            apr_pool_t *pool)
> {
>   svn_config_t *cfg = config ? apr_hash_get(config,
>                                             SVN_CONFIG_CATEGORY_CONFIG,
>                                             APR_HASH_KEY_STRING) : NULL;
>   const char *val;
>
> VVVVVVVVVV
>   /* Check the Subversion run-time configuration for global ignores.
>      If no configuration value exists, we fall back to our defaults. */
>   svn_config_get(cfg, &val, SVN_CONFIG_SECTION_MISCELLANY,
>                  SVN_CONFIG_OPTION_GLOBAL_IGNORES,
>                  SVN_CONFIG_DEFAULT_GLOBAL_IGNORES);
> ^^^^^^^^^^
>
>   *patterns = apr_array_make(pool, 16, sizeof(const char *));
>
>   /* Split the patterns on whitespace, and stuff them into *PATTERNS. */
>   svn_cstring_split_append(*patterns, val, "\n\r\t\v ", FALSE, pool);
>   return SVN_NO_ERROR;
> }
>
> #define SVN_CONFIG__DEFAULT_GLOBAL_IGNORES_LINE_1 \
>   "*.o *.lo *.la *.al .libs *.so *.so.[0-9]* *.a *.pyc *.pyo __pycache__"
> #define SVN_CONFIG__DEFAULT_GLOBAL_IGNORES_LINE_2 \
>   "*.rej *~ #*# .#* .*.swp .DS_Store"
> #define SVN_CONFIG_DEFAULT_GLOBAL_IGNORES \
>   SVN_CONFIG__DEFAULT_GLOBAL_IGNORES_LINE_1 " " \
>   SVN_CONFIG__DEFAULT_GLOBAL_IGNORES_LINE_2
>
> This seems wrong to me.  I'd expect that if I have no global-ignores
> defined in any of my runtimes that nothing will be ignored.  If we
> feel so strongly that these default ignores should be used, why do we
> create a default user config with them commented out?  This code is
> very old however so I wonder if there is not some good reason for this
> behavior.  Thoughts?
>
> --
> Paul T. Burba
> CollabNet, Inc. -- www.collab.net -- Enterprise Cloud Development
> Skype: ptburba