quilt-dev
[Top][All Lists]
Advanced

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

Re: [Quilt-dev] [PATCH] Enhanced decoration for "series -v" command


From: Peter Williams
Subject: Re: [Quilt-dev] [PATCH] Enhanced decoration for "series -v" command
Date: Tue, 14 Jun 2005 20:40:42 +1000
User-agent: Mozilla Thunderbird 1.0.2-1.3.3 (X11/20050513)

Andreas Gruenbacher wrote:
On Tuesday 14 June 2005 03:49, Peter Williams wrote:

Attached is a patch (on top of my previous patch) that addresses the
false positives issue.  It seems to work well with one of my playgrounds
that has quite extensive overlapping of patches.

The reason that I've provided this as a patch on top of my previous
patch is to make it easier to see the changes involved.

I'm fairly sure that this change won't have any adverse effects for the
use of files_may_have_changed() within the "pop" command but would value
the opinion of others.


Your version of files_may_have_changed is more exact than the current version, but it still is not perfect, and it is *much* slower: next_patch_for_file is slow; we definitely don't want to have it on the common path of execution of the pop command.

OK.  I'll change the code to get next_patch_for_file() off the common path.


The reason why your version of files_may_have_changed is still not exact is that all files that a pop restores get the current timestamp to play nice with tools like make, so after that, files_may_have_changed will start to give false positives. An exact version of files_may_have_changed would have to keep track of the timestamps of all files that any patch modifies.


Yes.  It looks like a "diff --brief" may be necessary as a last resort.

BTW If we can get files_may_have_changed() working properly then parts of "pop" may (possibly) be simplified which may regain some of the lost efficiency.

Peter
--
Peter Williams                                   address@hidden

"Learning, n. The kind of ignorance distinguishing the studious."
 -- Ambrose Bierce




reply via email to

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