Andreas Gruenbacher wrote:
On Wednesday 15 June 2005 04:45, Peter Williams wrote:
I've been looking at a method to tell whether just one file in a patch
needs refreshing (to use as the last check in files_may_have_changed)
and would like to use one of the commands (filterdiff) from patchutils
<http://freshmeat.net/projects/patchutils/>
to extract the patch for the file in question from the patch file so
that it can be used to modify a copy of the file for comparison with the
next version of the file above it in the series. This would have the
consequence of making quilt dependent on patchutils. Would this be
acceptable?
No. filterdiff, interdiff etc. don't work for arbitrary patches; they use
heuristics that fail once in a while. I don't want quilt to fail like that,
particularly because it can do better.
Fair enough.
The pop cpmmand already has code to
check whether a patch can be savely removed: it that creates a temporary copy
of the files in the patch, applies the patch, and compares the result. That's
not something you want to do when querying the patch status though.
It was where I got the idea. I.e. similar strategy but just do it one
file at a time. I was thinking that if doing this in
files_may_have_changed may enable it to become files_have_changed and
this would eliminate the need for the extra checking in pop. Whether
this would actually be more efficient is not clear but I think it
probably would be if per file patches can be extracted easily.
One way to do this without the need to use something like filterdiff to
extract the patches for a particular file from the combined patch file
would be to keep the patch files separated and cat them together along
with the header when needed.
BTW It seemed to me when I read it that parse_patches was intended to do
something similar to filterdiff but has been abandoned. The only place
that I could find it referenced was in the make file.
The only
clean solution I can imagine is remembering the timestamps of all modified
files, but that would require a number of changes here and there.
An advantage of this approach is that it may allow better data about
unapplied patches to be provided. E.g. at the moment if you use "quilt
files" for an unapplied patch you get diddly squat back which is a
little on the not very helpful side.
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
