subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Foad <julianf...@apache.org>
Subject Re: Crazy idea: changes in WC should share an API with changes in repository
Date Fri, 09 Nov 2018 11:47:15 GMT
Branko ─îibej wrote:
> The WC-NG with its multiple op-depths behaves like a
> limited-history repository. Your picture does lack the op-depth part,
> though; there are N layers between BASE and WORKING, unlike in the
> filesystem, where we always work against a single (base) revision.

I don't think that's an accurate description. The WC layers provide the repository base revisions
of nested copies, like a cache of the referenced disparate bits of the repository history.
The FS txn also supports nested copies, storing references to their bases in other revisions
where the data can be found. In each cases the "modification" layer is built by reference
to one main base plus zero or more copy-bases. In each case the relevant "base" API must support
access to both the main base (which is mixed-rev in the case of WC) and those copy-bases.

> Also note that the working copy may have switched subtrees, or
> individual files, which IIRC are represented in the BASE, so that would
> make WC replay somewhat different from repository replay.

Yes, "switched" comes under the head of "WC specifics".

> I understand these APIs could be reused for both shelving and
> driving/being driven by the RA layer. Could any of them be used by
> libsvn_client for local working copy modifications?

Absolutely! In order to prove an implementation of the "WC modifications editor" I would expect
to convert more or less *all* of the existing client commands to make their WC changes through
this editor.

> Also is this "just"
> an additional layer in svn_wc.h, or do you expect to deprecate swathes
> of the remaining public WC APIs as a result?

I would expect to deprecate swathes of the existing WC APIs.

-- 
- Julian

Mime
View raw message