On 07.11.2017 16:15, Julian Foad wrote:
> Branko Čibej wrote:
>> On 06.11.2017 17:30, Julian Foad wrote:
>>> The key point I am making here is the "topic" we're talking about in
>>> these commands is the "changelist" rather than the "savepoint" which
>>> is merely a stored version of a changelist.
>>
>> All our current commands that use changelists use them as an alias for a
>> set of targets. [...]
>>
>> Your proposal elevates changelists to a status that they do not
>> currently have in the client, and makes their usage inconsistent with
>> the rest of the command line. You might as well propose
>>
>> svn changelist commit
>> svn changelist diff
>> svn changelist switch
>>
>> and so on. Whether that would be a good idea is not the issue here: the
>> issue is consistency, and (possibly) backwards-compatibility.
>
> I absolutely am considering elevating the status of changelists to
> that level, yes! That makes a very good model in my opinion.
>
>> And the
>> rather important detail that changelists cannot be associated with
>> directories.
>
> Yes, that's noted as a needed enhancement.
>
>> Changelists were always a sort of afterthought ...
>
> Indeed, that made me sad from their beginning. And what better
> opportunity to at last make a plan to improve them?
Noted. +1. Enjoy the corner cases. :)
>> On another note: changelists with checkpoints make no sense IMO; a
>> checkpoint should save and restore the state of the whole working copy.
>> Shelved changes are different. Their internal representation may be the
>> same, but the semantics are not.
>
> Why do you think 'checkpointing' your work should be across the whole
> WC whereas 'shelving' it should not? I can see how 'checkpoint your
> whole WC' has a utility, sure, but no more so than 'shelve your whole
> WC'. I think it makes a great deal of sense to checkpoint a unit of
> work rather than the whole WC, and to work towards elevating
> 'changelist' to fulfil that role.
I shudder to think of the interactions and side effects of partial
checkpoints. Consider our standard Greek tree and the following sequence:
1. <do stuff>
2. svn checkpoint save "#1" A/B A/D/G
3. <do more stuff>
4. svn checkpoint save "#2" A/B/F A/D
5. <do even more extremely tricky stuff>
6. svn checkpoint rollback "#1"
7. svn checkpoint rollback "#2"
Um ... is that a rebase, a reorder, or a pretzel? Or does rolling back
to the state before #1 imply rolling back #2 as well? If the latter,
then checkpoints form a stack and represent the whole WC state.
-- Brane
Received on 2017-11-08 02:16:39 CET