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,
changelists).
> [...]
> 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.
Agreed.
>> 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
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=3294973
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2017-08-29 07:26:21 CEST