[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Shelve & checkpoint - next steps

From: Julian Foad <julianfoad_at_apache.org>
Date: Mon, 14 May 2018 14:06:11 +0100

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.