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

RE: two questions (and a proposed patch) regarding svn:ignore

From: Bert Huijben <bert_at_vmoo.com>
Date: Tue, 2 Feb 2010 18:52:46 +0100

> -----Original Message-----
> From: Stefan Sperling [mailto:stsp_at_elego.de]
> Sent: dinsdag 2 februari 2010 17:16
> To: dev_at_subversion.apache.org
> Subject: two questions (and a proposed patch) regarding svn:ignore
>
> Hi,
>
> the book says:
>
> Subversion uses the ignore patterns —- both the global
> and the per-directory lists --
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^
> to determine which files should not be swept into the version
> control system as part of a larger recursive addition or import operation.
> http://svnbook.red-
> bean.com/en/1.5/svn.advanced.props.special.ignore.html
>
> When adding a recursive directory tree, we only heed the global ignores list.
> Recall that the svn:ignore property is not inherited.
> Subversion is adding the directory to version control, and immediately
> proceeds to read the global ignores list, and the (obviously non-existent)
> svn:ignore property of the new directory (see
> subversion/libsvn_client/add.c:add_dir_recursive()).
> How can a user specify a pattern using an svn:ignore property deep inside a
> directory tree which is to be added? Isn't this a chicken- and-egg problem?
> Are people supposed to use auto-props trickery for this?
> I think the book is wrong there. It should make clear that only the global
> ignores list is heeded.
>
> My second question is due to a question in #svn.
> A user noticed that svn add adds files and directories which are explicitly
> mentioned on the command line, even if they match an svn:ignore pattern
> (I've tested with 1.5.x, 1.6.x, and trunk). Why do we have an --no-ignores
> option for svn add, documented as:
>
> --no-ignore : disregard default and svn:ignore property ignores
>
> but the default behaviour of 'svn add path' is to add the path even if it is
> listed in the svn:ignore property of its parent directory?
> I am leaning towards applying the patch below to fix this problem.
>
> But I wanted to ask before committing this, in case I'm missing something.
> This bug just seems too obvious :) Maybe there is a good reason for the
> current behaviour?
>
> Thanks,
> Stefan
>
> [[[
> * subversion/libsvn_client/add.c
> (add): Don't add a path if its basename matches its dirname's
> svn:ignore list, unless the --no-ignore option was passed.
> ]]]
>
> Index: subversion/libsvn_client/add.c
> ==========================================================
> =========
> --- subversion/libsvn_client/add.c (revision 905565)
> +++ subversion/libsvn_client/add.c (working copy)
> @@ -501,6 +501,20 @@ add(const char *local_abspath,
> svn_node_kind_t kind;
> svn_error_t *err;
>
> + if (! no_ignore)
> + {
> + apr_array_header_t *ignores;
> + const char *dirname;
> + const char *basename;
> +
> + dirname = svn_dirent_dirname(local_abspath, pool);
> + basename = svn_dirent_basename(local_abspath, pool);
> + SVN_ERR(svn_wc_get_ignores2(&ignores, ctx->wc_ctx, dirname,
> + ctx->config, pool, pool));
> + if (svn_wc_match_ignore_list(basename, ignores, pool))
> + return SVN_NO_ERROR;
> + }
> +
> SVN_ERR(svn_io_check_path(local_abspath, &kind, pool));
> if (kind == svn_node_dir)
> {

See other mail for details:

-1 on applying this change without revving the apis and making the compatibility wrappers 100% compatible with the original behavior.
(Maybe the change can be in an 1.7 version of the api if the api was already converted).

This patch by itself will break many third party subversion clients and because the only way to see the change is the notification... it will most likely not be caught by many unit tests.

Changes of 'svn' specific client behavior should be coded in 'svn'... not in libsvn_client. (or the apis must be revved following our versioning guarantees)

        Bert
Received on 2010-02-02 18:53:25 CET

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.