From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Eric S. Raymond" Newsgroups: gmane.emacs.devel Subject: Re: Introducing 'unrecognized and 'ignored Date: Sat, 29 Dec 2007 06:45:51 -0500 Organization: Eric Conspiracy Secret Labs Message-ID: <20071229114551.GD9794@thyrsus.com> References: <20071228174512.66834830BC9@snark.thyrsus.com> <17EA38DF-BCC1-4565-8510-5DD10DD667E3@mac.com> Reply-To: esr@thyrsus.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1198928773 5102 80.91.229.12 (29 Dec 2007 11:46:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 29 Dec 2007 11:46:13 +0000 (UTC) Cc: "Eric S. Raymond" , emacs-devel@gnu.org To: Alexandru Harsanyi Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 29 12:46:28 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1J8a95-0001gR-Mo for ged-emacs-devel@m.gmane.org; Sat, 29 Dec 2007 12:46:27 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J8a8k-0008RB-Fa for ged-emacs-devel@m.gmane.org; Sat, 29 Dec 2007 06:46:06 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J8a8g-0008R3-9B for emacs-devel@gnu.org; Sat, 29 Dec 2007 06:46:02 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J8a8d-0008Qr-SM for emacs-devel@gnu.org; Sat, 29 Dec 2007 06:46:01 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J8a8d-0008Qo-M9 for emacs-devel@gnu.org; Sat, 29 Dec 2007 06:45:59 -0500 Original-Received: from static-71-162-243-5.phlapa.fios.verizon.net ([71.162.243.5] helo=snark.thyrsus.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1J8a8d-00011s-8q for emacs-devel@gnu.org; Sat, 29 Dec 2007 06:45:59 -0500 Original-Received: by snark.thyrsus.com (Postfix, from userid 23) id 630D8830B99; Sat, 29 Dec 2007 06:45:51 -0500 (EST) Content-Disposition: inline In-Reply-To: <17EA38DF-BCC1-4565-8510-5DD10DD667E3@mac.com> X-Eric-Conspiracy: There is no conspiracy User-Agent: Mutt/1.5.15+20070412 (2007-04-11) X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:85599 Archived-At: Alexandru Harsanyi : > I had a look at the problem last night and wrote the code to load a > cvsignore file and produce a regexp to match the ignored files, however the > whole mechanism required by `vc-BACKEND-ignorable-file-p' is quite tricky > to implement corectly (in a way that both Emacs and the backend agree 100% > on what files are ignored). Here are two of the problems I found when I > looked at an implementation for CVS: > > * CVS will ignore a file only if it is unregistered. For example .o files > are ignored from a CVS status listing, but if an .o file is registered than > that file will show up in the listing. That is actually sensible behavior. From CVS, surprisingly so :-) > This requires checking whether a > file is registered or not, a thing which we try to avoid. Not necessarily. See below. > * There's a 'per-repository' cvsignore file at $CVSROOT/CVSROOT/cvsignore > which Emacs cannot access directly for remote repositories. That, on the other hand, is kind of a showstopper. > With extended vc-state states I don't think there is a need for > `vc-ignorable-file-p' at all: `vc-BACKEND-dir-state' should set the state > for each registered file and for files it can register. `vc-dired-hook' > can than simply look for the vc-state property and if it is missing it can > assume that the file is ignored. Thinking about it, you're right. We should consider that what dir-state does is update the state properties for as many files as it can, which means we can call (vc-state) on every file in the dired listing and only get expensive operations for the ones dir-state didn't report a status on. Then the problem of speeding up vc-dired-hook will reduce to a simpler one -- how to make the individual directory-status commands in each VCS return information for as many files as possible? Ideally, we want them to return status on *all* files beneath the current directory. Some VCSes will make this easy. Mercurial, for example, has hg status -A, which is documented to return status flags for all files. Now that we have 'unregistered and 'ignored, this means that the individual vc-state calls will never have to do their own check. Mercurial is going to be really fast. Some make it hard; CVS, for example. I don't know any way to make its dir-state set 'ignored files, and it will set 'unregistered only if the stay-local-p test fails and dir-state goes down the path that parses vc-status output (something we want to avoid because it's dog-slow). Most are in between. There is probably a way to beat Subversion into reporting status on all files, but I don't know what it is yet. I'll tackle this for Subversion -- would you look at making the CVS dir-state better? The goal is to get it to somehow set 'ignored and 'unregistered whenever appropriate. There is also a minor can of worms near 'added. It's not really a fully-supported state yet. It should be. And 'removed, too. -- Eric S. Raymond