[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: Julian Foad <julianfoad_at_apache.org>
Date: Wed, 8 Nov 2017 14:09:29 +0000

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'

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

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.