Jon Trowbridge <trow@ximian.com> writes:
> I'm sorry for being unclear. When no_ignore is TRUE, I would like to be
> able to distinguish between:
>
> (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.
> (2) All other unversioned files.
>
> My interpretation of the comments in svn_wc.h is that files of type (1)
> should have their text_status set to svn_wc_status_none, and while type
> (2) files should have a text_status of svn_wc_status_unversioned.
>
> 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
> Obviously I could work around this problem by just looking at the
> svn:ignore property on the directory and matching the patterns to the
> filenames in the GUI... but when I did exactly that in an earlier
> incarnation of this client, 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: the command line client gets an optional
default ignore pattern from ~/.subversion/config and if your client
doesn't then it would be different. However different is only wrong
if you are aiming to be the same :-) You could quite legitimately
produce a client that was different.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Aug 25 20:47:44 2002