[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 21:12:42 +0100

> -----Original Message-----
> From: Stefan Sperling [mailto:stsp_at_elego.de]
> Sent: dinsdag 2 februari 2010 19:21
> To: Bert Huijben
> Cc: 'C. Michael Pilato'; dev_at_subversion.apache.org
> Subject: Re: two questions (and a proposed patch) regarding svn:ignore
>
> 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.
>
> Could a gui client not get the ignore list for the directory, and let the
user
> toggle no_ignore for any particular file in the list, and then call
> svn_client_add4() with the appropriate value for the no_ignore parameter?

Yes..

It can also skip libsvn_client and use libsvn_wc or (for what it's worth)
edit the entries file directly, but that is not the point here.. We have a
versioning policy on our api and hundreds of existing libsvn_client api
users.

An application compiled against Subversion 1.0 should still work when the
library it is linked to is upgraded to 1.7.0... We expect the same for apr
and all the libraries we use.

If you want to break these users we have to go to Subversion 2.0.

I know about 3 documented cases where we had to break compatibility for
specific corner cases with libsvn_wc, but if possible we try to avoid
breaking existing public apis at all cost.

In this libsvn_client_addX() case it would be adding an extra boolean to
pass to the new svn_client_addX() function... And passing the right value
from the wrapper in deprecated.c.

        Bert
Received on 2010-02-02 21:13:21 CET

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