Eric Gillespie wrote:
Philip Martin philip@codematters.co.uk writes:
On second thoughts, it's not that simple. I agree that the extra
recursive targets should obey the global-ignores, but what about an
explict target? Should 'svn add foo.o' add the file despite the
global-ignores? I think it should.
Maybe, if the user has explicitly specified one file name. But what
about a wildcard like * that expands to lots of file names with some
of them matching global-ignores, or a list of file name arguments that
has been generated by find or the like? In particular, if I have ...
bar/foo.c
bar/foo.h
bar/foo.o
... I think I would want svn add bar/ to do the same as svn add
bar/*. In either case I might want it to tell me that it was ignoring
bar/foo.o.
Does 'svn add' now need a --no-ignore flag?
No, the change i am planning won't affect svn add foo.o. I'm
only changing add_recursive, which svn_client_add only calls if
path is a directory. And i think it is only this implicit,
recursive add that should honor ignores.
I am uncomfortable with the behaviour differing between implicit and
explicit lists of files to add.
So, for consistency, I feel the ignore list should apply to explicit
as well as implicit file names. Yes, it needs a --no-ignore flag like
the other commands that obey global-ignores (svn status and, maybe
soon, svn import).
cmpilato's suggestion to notify the user of skipped (ignored) files is
pretty much necessary. The notifications could be overridden with
--quiet. (Oh ... Eric disagrees.)
I have just played with svn status; it ignores files in implicitly
expanded directories but does not ignore explicit file name arguments.
Therefore I see an argument for making svn add consistent with the
current behaviour of svn status, but I'm not sure it's the right thing
to do.
- Julian
[I'm new here; please forgive me my trespasses.]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 14 02:16:30 2006