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
