monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Monotone-devel] Re: .mt-ignore and .cvsignore files


From: Bruno Hertz
Subject: [Monotone-devel] Re: .mt-ignore and .cvsignore files
Date: Thu, 12 May 2005 15:39:20 +0200
User-agent: Gnus/5.110003 (No Gnus v0.3) Emacs/22.0.50 (gnu/linux)

Nathaniel Smith <address@hidden> writes:

> On Thu, May 12, 2005 at 12:28:37AM +0200, Bruno Hertz wrote:
>> Apropos a recent discussion, would this patch prevent monotone from
>> scanning a whole directory tree if the top level dir itself matches an
>> ignore pattern?
>
> It's orthogonal.
>
> On that point, though -- would it make sense to people that, if
> ignore_file returned 'true' when given a directory, that everything
> inside that directory should therefore be ignored?  I.e., a file would
> be ignored iff it itself was not ignored, and furthermore none of the
> directories containing it were ignored?  This should be possible to
> do, and would presumably help in this case...

As I see it, yes and yes. If you think this is counter intuitive,
especially with regard to recursiveness and consistent behavior,
another approach would be an option to limit recursiveness, although
presumably leading to more clutter in this particular case.

What we are talking about here is situations where files under
revision control are sparse in a directory tree. As an example,
consider putting your home directory under revision control for files
like ~/.profile or ~/.emacs. In such a scenario, commands like list
unknown are pretty much useless right now (18.1 in my case) since they
walk the entire home directory tree.

To tackle this, obviously there are two strategies:

(i)  include per default, and exclude on demand
(ii) exclude per default, and include on demand.

Your suggestion would fall into approach (i), and limiting recursiveness
per option either. Approach (ii) was discussed by us in another thread.

Regards, Bruno.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]