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
