Branko Čibej wrote:
> [...] I've often wished we'd
> made our argument parser slightly more flexible in that respect, so that
> [...] we could write
>
> svn [topic] command [options args]
> FWIW, the reason I'm slightly in favour of "savepoint" vs. "checkpoint"
> has been discussed before: the abbreviation "sp" is not taken yet, [...]
Ack.
>> I am thinking for example that we might want to 'send' this change to
>> a review system or 'commit' it to the svn server (ok we'd use 'svn
>> commit <something>' for that) or export it to a patch or email (git
>> format-patch). The main actions on a Perforce changelist are done by
>> first-class commands 'p4 submit', 'p4 shelve', etc. while the 'p4
>> change[list]' command has (option-letter) verbs for 'input' and
>> 'output' actions.
>>
>> Any suggestions for the 'shelve' terminology problem? Change to
>> 'stash' and incur false expectations based on git stash? Is there
>> something else that, like 'stash', can be used as a noun and a verb
>> and sounds good?
>
> IIUC the shelving prototype is a lot closer to Perforce's than Git's,
> right? Then thinking about shelves is better than about stashes. Why not
> do the same as with (save|check)points: the [topic] should be a noun,
> the [command] a verb, so:
>
> svn shelf save ...
> svn shelf restore ...
Next observation: 'shelves' and 'checkpoints' are not two alternative
kinds of thing; rather savepoints/checkpoints are versions of a
(shelved) change.
So 'save this point' and 'roll back to a saved point' need not be in
grouped in their own 'savepoint' topic namespace but would perhaps be
better described as actions on a (potentially shelved) change.
'Roll back' means retrieving an old version of a shelved change and
could be named like one or a permutation of these:
svn unshelve --checkpoint=3 foo
svn shelf restore foo_at_3
svn revert --savepoint=3 --cl=foo
svn changelist restore -v3 foo
(I am deliberately bringing 'changelist' into the mix, as I believe
integration with 'changelist' is where we need to take this.)
I was particularly looking at the case where we have some local
modifications already and we want to 'roll back' to an earlier version
of the files. I had been thinking about how Subversion should decide
which modifications in the WC it should revert before restoring the old
version. E.g. revert(union(files in requested old version, files in
most-recently-restored version)). That seems prone to unintended
consequences as the 'most recently restored version isn't necessarily
known at all, or correctly known in cases where the user restored
something and then manually reverted and applied some other change. Also
the set of files that was previously recorded may not be the same as the
set of files currently undergoing editing, as it is common to start
affecting other files. (To handle this sort of case, we need the
'changelist' mechanism augmented by the notion of assigning new changes
to a 'default changelist'.)
Instead of all that uncertainty, let the user be responsible for
reverting the current modifications currently in progress, and then roll
back using a simple form of 'unshelve' that does not attempt to revert
anything first. For added safety, 'unshelve' should warn (e.g. require
'force' to override) if it attempts to modify any already-modified
files. (This was already a suggested enhancement.)
- Julian
Received on 2017-11-06 15:47:34 CET