Julian Foad wrote:
> What works now?
>
> * files recognized as 'binary' (by our svn:mime-type rules) are
> handled by storing the whole working file; other files still use diff
> and patch
>
> * unshelving a 'binary' file reports a conflict if the WC file is
> already locally modified (it doesn't check the base version is the same
> as it was);
>
> * unshelving a 'binary' file copies it into the WC (and adds it to
> version control if not already)
>
> * properties of a 'binary' file are still stored in the patch file
> and handled by patch application
One bit of the existing functionality isn't updated to handle the
storage of 'binary' files: 'svn shelf-diff' still just copies the
shelf's patch file to standard output, and doesn't do anything with the
new 'binary' files storage. For human-readable usage that's no big deal;
as a data export facility it would be a problem. As it's low priority
for a UI feature I don't propose to hack something in there at this stage.
Instead I would rather re-implement this export feature once we have put
in place a better architecture. It should be structured like:
* fetch the shelf changes, by providing an implementation of our
existing svn_diff_tree_processor_t API around the storage,
* plug that into our existing diff output formatting code
Two issues need solving first. Patch file semantics don't match
svn_diff_tree_processor_t: we need complete 'before' and 'after' files,
so we need to move away from patch file storage, which is better for
other reasons too. Then our existing diff output code is not quite as
decoupled as it needs to be. I made a start -- see get_diff_processor()
in libsvn_client/diff.c -- but a bit of coupling still remains in the
"diff_driver_info_t" parameter.
- Julian
Received on 2018-05-14 15:06:15 CEST