[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 20:05:46 CEST

On Sun, 2002-08-25 at 10:26, Philip Martin wrote:
> I am confused by your comments. If you have no_ignore set TRUE then
> that means that there are no ignored files. From that it follows that
> all files on disk are either versioned or unversioned. Why do you
> expect there to be any ignored files if no_ignore is set TRUE?

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~

(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.

However, this is pretty useless if I can't distinguish between ignored
files and files that just aren't (yet) under version control. It is a
pretty safe assumption that nobody will want to use a GUI to put their
emacs backup files or .o files under version control, so it is nice to
be able to keep them from cluttering up the directory listing... but the
GUI should always show other unversioned files and give the user an
option of adding them.

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. :)


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:12:46 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.