Branko Čibej wrote:
I shudder to think of the interactions and side effects of partial checkpoints. Consider our standard Greek tree and the following sequence:
First think about saving checkpoints the manual way, to set our initial expectations fairly low:
svn diff foo-paths > foo-4.patch svn diff bar-paths > bar-17.patch Then let's look at how we can improve on that.
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
I assume (1) these named changelists '#1' and '#2' were not defined (so not checkpointed) before step 1; and (2) you intend these 'save' commands to act with depth 'infinity' on the specified subtrees.
So you are concerned about how to handle overlapping subtrees -- in particular the case where a directory is associated with one changelist, and a subdirectory within it is (already or later) associated with another.
5. <do even more extremely tricky stuff>
I'll interpret that as 'do normal Subversion operations' rather than 'execute arbitrary SQL statements on wc.db' :-)
6. svn checkpoint rollback "#1" 7. svn checkpoint rollback "#2"
OK, now is a good time to think about possible semantics. Here is a starting point.
* A subtree is associated with a changelist either explicitly by attaching the changelist name to its root directory, or if not explicitly then implicitly by inheritance from its parent. A subtree association applies only to parts of the subtree that are not associated with a different changelist.
(Therefore a directory can be associated with only one changelist, and an explicit assignment overrides any association that would otherwise be inherited from its parents. After step 4 of your example everything in A/B is associated with '#1' *except* everything in A/B/F which is associated with '#2'.)
* 'Saving' a changelist 'NAME' records the explicit attachment of NAME to particular PATHS.
* Restoring a changelist 'NAME' restores the explicit attachment of NAME to particular PATHS. If some paths are already associated with changelist NAME, behaviour is client-defined, e.g. error, append to exiting assignments, replace existing assignments, with or without a warning. Let's say the initial CLI behaviour is error, for simplicity. (In other words the user has to revert before restoring, as I suggested a little earlier in this thread.)
* The syntax '... save NAME PATHS...' first assigns changelist NAME to PATH..., replacing any previous assignment for PATH..., and then saves all paths belonging to NAME.
With this, your step 2 would save the whole subtree at A/B (and the one at A/D/G) in a first checkpoint of '#1', while your step 4 would unassign A/B/F from changelist '#1' and assign it to changelist '#2' instead.
You can work out the 'rollbacks' from there (I haven't time right now); I acknowledge it won't do magic for you -- but I'm sure you wouldn't want it to.
How does that strike you from a pragmatic point of view? - Julian
