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
Received on 2017-11-08 15:09:35 CET