> -----Original Message-----
> From: C. Michael Pilato [mailto:cmpilato_at_collab.net]
> Sent: dinsdag 2 februari 2010 17:37
> To: Stefan Sperling
> Cc: dev_at_subversion.apache.org
> Subject: Re: two questions (and a proposed patch) regarding svn:ignore
>
> Stefan Sperling wrote:
> > 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.h
> > tml
> >
> > When adding a recursive directory tree, we only heed the global
> > ignores list.
>
> I wonder if, when documenting that bit, I was thinking about the scenario
> where you are running 'svn add -R --force' atop an already versioned
> directory tree, just trying to pick up any unversioned stuff in that tree.
>
> > 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?
>
> The --no-ignore option aside, I'd argue that the current behavior is more
> obvious than silently not honoring a user's request to 'svn add' something.
>
> $ svn add foo.o
> $
>
> Of course, I realize that most folks wouldn't do the above. They'd instead do
> something like:
>
> $ svn add *
>
> and would reasonably expect that stuff configured to be ignored would be
> ignored (and it isn't, right, because the wildcard is expanded by the shell).
>
> So maybe we could benefit from a pair of changes here: the one you
> included, but also some notification for 'svn add' (and 'svn import') that
> reports either explicitly-named or reached-through-recursion ignored items.
>
> $ svn add foo.o
> Ignoring 'foo.o'. ### or maybe just: "I foo.c"
> $ svn add foo.c --no-ignore
> A (bin) foo.c
> $ svn add some-dir
> A some-dir
> A some-dir/foo.c
> A some-dir/foo.h
> Ignoring 'some-dir/foo.o'
> A some-dir/lib.c
> ...
>
> Whaddaya say?
I like this change for my uses of 'svn' as '*' is handled by the shell, but I don't think the new functionality is logical at the svn_client_add() layer. In most gui clients I use, I see some svn status output containing the not added files and then these clients allow adding all or some of the files via the explicit variant.
Just notifying that you skipped a few files that would have been added before, would make it very hard for api users to replicate the old behavior via the new api. (Using the notify handler to check for error conditions is not so easy for most api users)
Not sure if the same applies for scripts that use svn internally... but I would guess most batch files have a hard time making sense of the changing svn status output for warning conditions. (Would this break svnmerge.py like wrapper scripts?)
I always thought the old behavior was taken from older/similar systems like CVS.
Bert
>
> --
> C. Michael Pilato <cmpilato_at_collab.net>
> CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2010-02-02 18:47:24 CET