I (Julian Foad) wrote:
> On Tue, 2010-02-02 at 19:20 +0100, Stefan Sperling wrote:
> > On Tue, Feb 02, 2010 at 06:46:46PM +0100, Bert Huijben wrote:
> > > 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)
> > Right now, the no_ignore parameter only disables global ignores,
> > and svn:ignore ignores are always ignored.
> No, that's not right. I just tried it with a trunk build. I set
> 'svn:ignore' to ignore the file named 'F', and then I try an 'svn add
> --force' that encounters a file named 'F', without and then with
> $ svn add --force a
> $ svn add --force --no-ignore a
> A a/F
I think the rule is (not just for 'svn add', but for all svn commands
that do this kind of ignoring):
a file is ignored iff
(it matches the svn:ignore property or the global-ignores setting)
(it is unversioned)
(it is encountered in recursion, rather than specified explicitly)
(--no-ignores is not specified)
> So it looks like your new "no_svn_ignores" parameter is not needed.
Or rather, I think the original change you were considering was
controlling whether to ignore files that are specified explicitly as
well as files that are encountered in recursion. That extension could be
introduced in svn_client_addN(), but as that is a single-target API the
caller could implement the behaviour instead by choosing whether or not
to call it.
The svn subcommand, which takes multiple targets, could be extended to
control this behaviour. However, this behaviour (of not ignoring an
explicit target) was designed that way on purpose. It's not necessarily
the perfect UI, but it's fairly sensible and easy to describe. Are you
sure it is important to change the UI?
> If you find it does what you said in a different scenario (e.g. if the
> svn:ignore property is committed versus uncommitted) then clearly that
> would be a bug.
> - Julian
Received on 2010-02-03 01:53:06 CET