[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Crazy idea: changes in WC should share an API with changes in repository

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Sat, 10 Nov 2018 00:53:01 +0000

Julian Foad wrote on Fri, 09 Nov 2018 10:56 +0000:
> It is really quite important for the feasibility of writing higher level
> code such as shelving, that WC modifications can be read and written by
> a common, abstract, interface. That is, an interface definition which
> enables a 'copy' function to plug an input interface to an output
> interface and push all the changes through the pipe.
> To better support these needs, changes in the WC should share an API
> with changes in the repository.
> * WC mods API := (basic changes API) + (lots of WC-specific API)
> * FS txn API := (basic changes API) + (some FS-specific API)
> Is this such a crazy idea?
> [ image:
> http://blog.foad.me.uk/wp-content/uploads/2018/11/20181108-SvnWcAPIs.png ]
> There are two levels at which we can perform this API refactoring.
> First, streamy changes via the delta editor API. The repository side
> already has a commit editor for input and a 'replay' edit-driver for
> output of the changes in one revision. The WC already has a commit edit-
> driver for output, but no editor for receiving modifications. It needs
> one.

I assume you mean here an editor for receiving modification to the
WORKING layer, since the update editor exists but modifies the BASE
layer, correct? That would also square with your clarification
elsethread that you'd make svn subcommands use that editor.

That sounds interesting. The editor interface has strict ordering
constraints, and if a sequence of 'svn' subcommands is to be
equivalent to a sequence of editor drives, that are then committed in
a *single* editor drive... that implies some sort of editor-drive-combiner
algebra. (From this point of view, 'svn commit foo' when both foo and
bar are modified is an editor-drive-splitter, reordering commits would
be commutativity¹, etc.)

The immediate implication is that wc commit logic could, in
principle, be generalized into a logic for combining successive
revisions in a dumpfile.

While we're looking at these two things, do we really need both the
reporter and the commit editor? Aren't they logically doing exactly the
same job (up to the reporter not uploading text and property deltas)?



¹ #ifdef MATHEMATICIAN \n and associativity \n #endif
Received on 2018-11-10 01:53:15 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.