On 24.08.2017 16:10, Julian Foad wrote:
> Dear TortoiseSVN developers,
>
> We are developing Shelving and Checkpointing features in Subversion core
> [1]. This is a proposal to add UI to TSVN to support those features.
>
> We wish to make these features available early. At present the core
> features are being developed on branches [2]. As previously discussed,
> it is probably appropriate to develop the TSVN UI on a branch.
As long as shelving is on an svn branch, TSVN will use a branch as well.
Otherwise it would get very messy...
> These are entirely client-side features.
>
> It is expected that the core library will provide all the required
> feature functionality, so the implementation in TSVN will be entirely UI.
>
> It is expected that the WC format will not change and that all the
> functionality will be built on top of the existing WC format. The data
> storage will be within new subdirectories in the WC's '.svn' directory,
> in the form of patch files and/or embedded svn repositories.
>
> Below is a draft of the UI design.
>
>
> == Shelving ==
>
> Shelving is closely equivalent to 'hg shelve' and 'bzr shelve', and a
> subset of the capabilities of 'git stash'. It must work offline.
>
> UI for Shelving involves:
> * user selects the whole or part of the WC;
Haven't checked the API yet, but I assume that the shelve API will take
a list of paths/files and a recursive flag if only one path is specified?
> * user chooses a name or TSVN generates a name automatically;
> * user optionally supplies a description;
> * TSVN tells SVN to 'shelve': SVN saves a diff of the selection as a
> patch file in the WC directory '.svn/shelves/' and reverts that diff
> from the WC.
Simple concept. And it should work for independent changes. But there
will be trouble if changes in the shelve and the main wc are not
independent - from my experience the "apply patch" functionality in svn
is not very good and produces a lot of rejects.
> UI for Unshelving involves:
> * TSVN shows the list of shelved patches and user chooses one;
> * TSVN tells Subversion to 'unshelve': SVN applies the patch to the
> WC and deletes the patch (if no conflicts);
> * TSVN presents any resulting patch conflicts as for 'svn patch'.
If possible, the 'svn patch' should (automatically or via interaction)
fetch the conflicted file from the base revision (base of the patch) and
then try a three-way-merge with that before producing a reject.
Because as I mentioned above, applying a patch is not very good.
Before the svn lib implemented its own patch feature, TortoiseMerge did
exactly that: it applied a patch and if it failed to do so, fetched the
file from the patch base-rev (from the repository) and then did a
three-way-merge. That was successful in much more situations so that
only very few situations were left with a real conflict.
And even then: resolving a three-way merge conflict of a file is much
easier to do than resolving one with a reject-file.
> == Checkpointing ==
>
> Checkpointing allows the user to save the WC state from time to time,
> and roll back to a previous WC state. It must work offline.
>
> UI for 'checkpoint save' involves:
> * user selects the whole or part of the WC;
> * user optionally supplies a description;
> * TSVN tells SVN to 'checkpoint save'
>
> UI for 'checkpoint rollback' involves:
> * (?) user selects the whole or part of the WC;
> * TSVN shows list of checkpoints and user selects one;
> * TSVN tells SVN to 'checkpoint rollback'
>
> Those are the basic checkpointing operations; others may be added.
And what about "commit checkpoints"?
* user selects "commit checkpoints"
* UI presents all checkpoints
* user selects the checkpoints for which a separate commit should be done
* svn then commits each checkpoint as a separate revision, each with its
own commit message (the description of the checkpoint).
That way, multiple changes still result in multiple revisions - makes it
easier to review and also easier for later since there's not one single
commit with multiple changes.
>
> Checkpointing design options are currently being explored, especially
> regarding the WC base state. Saving a checkpoint may leave the WC base
> as it is, or it may update the base like commit does so the WC shows as
> unmodified. It may or may not save the WC base state and allow updating
> the WC base between checkpoints. It may support checkpointing only when
> the WC state is committable, or it may support saving an uncommittable
> state such as unresolved conflicts.
Another thing to consider: showing diffs against the wc base. If the WC
base is left as is, then we would need another API to get a file from
not just the WC base as we have now, but also to get a file from the
last checkpoint state.
> == Integration into TortoiseSVN ==
>
> The attached images suggest a basic starting point for the UI.
>
> Shelving is conceptually so close to patching that 'Shelve' and
> 'Unshelve' should be adjacent to or integrated with 'Create patch' and
> 'Apply patch'. The UI could be modeled on the patching UI. The attached
> 'Shelve-Commit-Dialog-1.png' shows an alternative, modeled on the Commit
> dialog to which it is also conceptually close.
I think "commit" would be better - from my point of view it's more like
a 'local commit' than a patch: users are not interested in how it is
done internally but only what it does. Meaning they don't care that it's
done via patch files.
> Checkpoint rollback functionality might most logically be incorporated
> inside the 'Revert' function. The Revert dialogue should be extended if
> any checkpoints exist to offer a selection of which checkpoint to revert
> to. 'Checkpoint save' should then be adjacent to Revert.
For this a whole new dialog is required. The 'Revert' dialog is not
suitable for this.
> We welcome your thoughts on how best to design the UI for these
> features. We are willing to do the implementation work needed, and look
> forward to working with you.
I'm currently busy with some other project, but I can get some time to
get started.
> Please let us know if we should start by sending you patches against
> TSVN trunk or if there is something else we need to do to get started.
Just be aware that if you create a patch that the resource files (*.rc
and the resource.h files) are encoded in utf-16, which means svn treats
them as binary and changes there won't be in a patch.
If you want commit access to our repo, send me your sourceforge username(s).
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest interface to (Sub)version control
/_/ \_\ http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=3293478
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2017-08-25 21:20:24 CEST