Peter Williams wrote:
Peter Williams wrote:
Peter Williams wrote:
Peter Williams wrote:
Andreas Gruenbacher wrote:
On Friday 10 June 2005 08:21, Peter Williams wrote:
I am the author of a PyGTK GUI wrapper ( see
<http://freshmeat.net/projects/gquilt/>) for quilt and it has been
suggested to me that the panel containing the display of the patch
series could be enhanced by having it display (for applied patches)
whether each patch needs refreshing or not.
Looks nice. It seems the Push and Pop icons point in the wrong
direction wrt. the series file (which has its top at the bottom)?
You're the second person to say that and I don't understand as the
push arrow pushes up onto the bottom of the series and the pop arrow
pops down off the bottom of the series (at least in the latest
versions). Older versions used stock icons with unpredictable
results depending on how they were represented on each system so
I've gone to gquilt specific icons for later versions. Can you
confirm that you've got version 0.4?
The attached patch modifies quilt's "series -v" command to add this
information to the output.
files_may_have_changed may return false positives, so the resulting
status information isn't worth much. Also it doesn't take care of
shadowed files, so modifying a file in a patch further down in the
series file will mark all previous patches that include that file
as modified.
Yes, I've discovered that :-( and will try to come up with a fix in
a day or two. Basically, when a file is newer than the patch's
timestamp I'll look at applied patches above the patch until I find
one that shares the same file and make the comparison with the
"cached" file for that patch.
As for other false positives I'm not sure that they're worth hunting
down as they should only be caused (I think) by rare occurrences
such as a change being made to a file and then removed without a
refresh being done. I'm reluctant to go to all the trouble of doing
diffs to confirm that there is indeed a difference in the file (due
to the overhead) but will do that if necessary.
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.
Well it doesn't seem to have any bad effects on "pop" but,
unfortunately, "pop" has a bad effect on files_may_have_changed()
causing it to have false positives for patches that it had previously
considered not in need of a refresh. Calling refresh on these patches
gets rid of the false positives but (it should be noted) report that
the patches are unchanged.
Perusal of pop.in doesn't reveal any obvious easy way that this
problem could be fixed. Does anybody have any ideas?
Can backup-files be (easily) made to set the modification times on the
restored files to the same as the cached file being restored? I think
that this would solve the problem.
I withdraw this question and consign the concept to the "bad idea" tray.
If implemented this would cause havoc with "make". :-(
Peter
--
Peter Williams [EMAIL PROTECTED]
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
_______________________________________________
Quilt-dev mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/quilt-dev
