Do you think the attached patch looks reasonable, e.g. it does not
interfer with the overall design of 'svn patch'? It's not fun to review
a patch that touches on so many parts. Sorry 'bout that. Find below some
The patch code consist of four steps:
1) match text in streams
2) apply text to target stream (or reject stream)
3) install tmp files by copying them to the target path
4) send notifications on what we've done.
text_info_t is the datatype that will be passed around in step 1 and 2.
Is the name ok? I tried target_info_t first but it sounded too vague. On
the other hand, the doc strings for scan_for_match() and friends will
Scan lines of TEXT_INFO for a match of the original text of HUNK...
In step 3, we're passing both patch_target_t and text_info_t as
parameters to apply_hunk() and reject_hunk() since we might need
target->path and target->had_rejects. Is it ok to pass both?
Create text_info_t for storing text related parts of patch_target_t.
This is a step towards handling properties in the patch code. The idea
is that text_info_t should be able to describe any text, be it from a
file or a property. But for now we're only dealing with texts from a
(patch_target_t): Fields related to the text have been moved to the
(init_patch_target): Initialize 'text_info'.
(scan_for_match): Replace 'target->' with 'text_info->' for fields
that have moved.
(match_existing_file): Use 'target->text_info' for accessing the
streams. We still need other fields from the target and text_info
can only refer to text_info of the file in this case.
(get_hunk_info): Add 'text_info' parameter. We still need target for
(copy_lines_to_target): Add 'text_info' parameter.
(apply_hunk): Add 'text_info' parameter. We still need target for
marking a target as having rejects.
(send_patch_notification): Uses text_info->hunks
(apply_one_patch): Pass around target->text_info to the match and
Received on 2010-07-16 20:56:18 CEST