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

Re: Ignored vs. Unversioned

From: Jon Trowbridge <trow_at_ximian.com>
Date: 2002-08-25 22:59:58 CEST

On Sun, 2002-08-25 at 13:47, Philip Martin wrote:
> Jon Trowbridge <trow@ximian.com> writes:
> >
> > (1) Unversioned files that we are explicitly ignoring because they match
> > a pattern in svn:ignore (or one of the default patterns).
> > For example, foo.c~
> When no_ignore is TRUE there are *no* files that we are explicitly
> ignoring, svn:ignore is not used. That's what no_ignore means.

Yes, I understand that. What I'm saying is that it would be useful if,
while not ignoring any files, there was some indicatation of which of
the files would have been ignored if no_ignore had been FALSE.

The comments in svn_wc.h (unless I've misinterpreted them) say that this
should happen, by setting the text status of files that would have been
ignored to svn_wc_status_none. However, it isn't happening.

(One alternative might be to create a new status type,
svn_wc_status_ignored. That might have a bit less of a hacky, "magic
number"ish feeling, if that is something that you are concerned about.)

> > A bit of background might be helpful: I'm working on a Gtk+ Subversion
> > client (which lives in /clients/gsvn), and I want to have a "hide
> > ignored files" option so that you can look at a directory and not see
> > all of the foo~, foo.o, foo.lo, #foo#, etc. files.
> That sounds like all the files not returned by svn_client_status when
> get_all is TRUE and no_ignore is FALSE.
> call svn_client_status to get status hash
> get list of all files
> for each file in list of all files
> if file is not in status hash
> file is ignored so don't display it
> else
> display file
> which is the same as
> call svn_client_status to get status hash
> display all files in status hash

To do what I want to do using the current svn_client_status (get a list
of all files, and know which ones would be ignored due to matching a
svn:ignore or default pattern) requires that I either:

 (1) Call svn_client_status twice, once w/ no_ignore TRUE and once with
     no_ignore FALSE, and compare the two returned status hashes to
     figure out which files are ignored due to svn:ignore/default

 (2) Call svn_client_status w/ no_ignore TRUE, then walk across the
     directory manually and inspect every file. I can then conclude
     that any "extra" files I find, files that aren't mentioned in
     status hash, were ignored due to svn:ignore/default patterns.

Both of these require that we do some relatively expensive disk I/O
(walking across the directory looking at the files) twice, when it
really could just be done once by the original call to

Another alternative would be to call svn_client_status every time the
show/hide ignored files flag is toggled... which would also be a
reasonable solution, but again it shouldn't really be necessary. If the
call to svn_client_status w/ no_ignore=TRUE simply flagged the
would-have-been-ignored files in some way (like setting the
text_status), then there is no need to extra calls to svn_client_status,
manual walking the directory, etc. etc. I can just svn_client_status
once, and then I have all of the information I need... all I have to do
is toggle how that information is displayed.

Obviously this isn't that big a deal. As Philip correctly points out,
there are plenty of ways to work around this issue. But I think it
would be worthwhile do change svn_client_status to behave in the way
I've propsed because:

  * It is more efficient, and allows one call to svn_client_status to
    do all of the work.

  * This change would actually produce the behavior promised in the
    comments in svn_wc.h. If things don't get changed so that the
    text_status of ignored files gets set to svn_wc_status_none, then at
    least the comments in svn_wc.h should be changed to not promise
    that behavior.

> > Obviously I could work around this problem by just looking at the
> > svn:ignore property...
> > Ben Sussman told me that was totally wrong,
> > and that I should just let Subversion do it for me. :)
> Doing it yourself means that your client may not behave the same way
> as the command line client:

Yes. IMO, that would be bad. I can't think of any good reason why a GUI
client should ignore a different set of files than the cmd-line client.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Aug 25 23:07:06 2002

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.