On Wednesday 15 June 2005 09:17, Peter Williams wrote: > Peter Williams wrote: > > 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. > > Attached is a patch for files_may_have_changed that takes > next_patch_for_files off the common path. Is its speed acceptable?
No. It's still on the common path for very many patches after the first pop. > BTW I think that similar enhanced decoration for the "files -v" command > would also be useful for indicating to the user which files in a > particular patch are the cause of the need for an update. To this end I > will spend some time coming up with something that can be used for both. It would be nice, agreed. One possible design would be to keep a second tree of zero-length files below .pc/.timestamp/ for example, and remember the timestamps there. Updating those timestamps should be really fast for push and pop; bash might be too slow for that. Refresh is much less time critical. -- Andreas. _______________________________________________ Quilt-dev mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/quilt-dev
