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

Re: [RFC] Add Shelve and Checkpoint UI

From: Julian Foad <julian+tigris_at_assembla.com>
Date: Mon, 28 Aug 2017 22:22:13 +0100

On 28/08/17 21:35, Stefan Küng wrote:
> On 24.08.2017 16:10, Julian Foad wrote:
>> [...]
>> == 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?

It would take the usual path selection arguments: (paths, depth,

> [...]
> 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.

Yes, the design is being discussed on the dev_at_subversion list, and
patching vs. merging is a current topic.

> [...]
> 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.
> [...]
> Before the svn lib implemented its own patch feature, TortoiseMerge did
> exactly that: [...]

Noted. Thanks.

>> == 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).

I'm aware that's a possible use case. For the time being, we aren't
going there, for various reasons as discussed on dev_at_subversion.a.o.

> 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.

For the time being, we'll just support diffing WC working against WC base.

>> == Integration into TortoiseSVN ==
>> [...]
>> 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.

Excellent -- we'd appreciate a bit of hand-holding at this stage!

>> 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.

Thanks for the tip!

- Julian


To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2017-08-29 07:26:21 CEST

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