> >   (2) Better capture of base state.

[Summarizing from IRC.]

Today I'm trying to figure out how to get Shelving v3 from last week's initial 
demo state (email "Shelving v3 started", branch "shelving-v3") to something 
that could be considered experimentally usable in a v1.12 release. My overall 
approach is to aim for high level APIs to do the required functional blocks; 
I'm not going to hack the wc-db.

The current state is to make a shelf we:
  - copy the whole (user's) WC to somewhere else where it will become the shelf 
storage for this shelf-version;
  - revert all the modifications in that copy so it is now a copy of the base 
state of the user's WC;
  - to shelve the *requested* changes we use the new high-level wc-copy-mods 
API to copy the requested local modifications from the user's WC to this shelf 
storage WC;
  - Finally, if requested ("shelve" versus "shelf-save"), we revert the 
requested mods from the user's WC.

The bit that needs work next is making a copy of the base state of the user's 
WC.

Here's the plan for that bit:

(1) Create the WC base checkout by using existing "checkout" code, initially 
driven from the repository, using URLs and revnums read from the user's WC (as 
in "svn info --x-viewspec").
(1a) For the whole WC; (1b) trimmed down to a given path specification.

(2) Create the WC base reading API (limited to a given path-spec) and think of 
a way to test/exercise it in isolation.

(3) Wire up (1) and (2) together.


For (1): The existing high level API to create a WC with a given base state 
(and no local modifications) is the client side of "checkout". Of course we 
only need to copy the base of locally modified nodes in the requested portions 
of the user's WC, not the whole WC. So we need an API that creates (a bit like 
checkout) a new WC that includes just those paths. I wonder if we could do that 
by using the "checkout" client-side machinery, unmodified, to create the WC, 
being driven from a "pretend Repository Access API" driver that feeds "real" 
data for the given paths and sets all other paths to depth-exclude.

For (2) the base-reading API: The existing high level API to read the base 
state of a WC is ... seems to be missing. "export" is but a small subset of it, 
lacking properties and repository URLs and revisions metadata. I can 
investigate starting from existing "diff -r0:BASE" code and see if that's 
useful. However, it writes directly to the diff-tree-processor API and I'm not 
sure if that's convertible to editor API.

Moving the shelf-storage-WCs location back inside .svn/experimental/... will be 
trivial after step (1a).

-- 
- Julian

Reply via email to