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: Andreas Gruenbacher
Subject: Re: [Quilt-dev] [PATCH] Enhanced decoration for "series -v" command
Date: Wed, 15 Jun 2005 12:08:47 +0200
User-agent: KMail/1.8

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.




reply via email to

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