On 25.08.2017 18:23, Julian Foad wrote:
> It seems Shelving in the current form is working out quite nicely. I'm
> thinking about what more we need so that any of us or our friends would
> be comfortable testing it on non-trivial data and calling the feature
> set a "minimum viable product". I thought of:
>
>
> Hardening before being safe to use:
>
> * Help text should contain a short introduction to how to use; set the
> user's expectations; state the limitations (see "Extensions / Not
> Supported Initially" section [1] in design doc.).
>
> * Output should be verbose and clear about what is happening.
>
> * The prototype should not delete patch files when unshelving, in case
> it goes wrong; instead rename/move them.
On the topic of storing patches, I'd like to propose an alternative
implementation.
Instead of saving a set of patches, save two sets of (untranslated
pristine) files:
* All currently modified files
* Their pristine, unmodified versions (these are of course already in
the pristine store and would only need an extra reference in the WC
DB so that 'svn cleanup' doesn't delete them).
The idea is that 'unshelve' could, instead of applying patches to the
current working copy, invoke our built-in diff3 algorithm with whole
(untranslated!) files. This is likely to produce much better results and
saner conflict info than applying patches, which have limited context
information.
Additionally, the existing pristine store can be used to track the files.
-- Brane
Received on 2017-08-26 15:39:15 CEST