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

Re: Checkpointing v1 design -- terminology

From: Branko Čibej <brane_at_apache.org>
Date: Wed, 8 Nov 2017 02:16:34 +0100

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

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.