On Sun, Aug 25, 2013 at 03:44:05PM -0700, Travis Brown wrote: > I took a brief look at the resolution code and found it to be a twisty > maze of callbacks and workqueues. There didn't appear to be any existing > infrastructure or obvious way to resolve the tree conflict on the > directory and then continue with whatever operation caused the conflict > in the first place.
I agree the layering is somewhat complex. 'svn resolve' now contains several operations similar to update and merge, and which had to be implemented from scratch where the existing update/merge code couldn't be used without modification. The callbacks are either conflict resolution callbacks that are needed to support different client implementations at the API level, or they're the editor callbacks which give the resolution code a structure similar to the update and merge code. Technically, the editor API wouldn't be needed within 'svn resolve', as it is intended to work primarily offline. However, it may need to contact a server in the future. Also, we decided to use the new resolver as a test bed for the new EditorV2 API, which hasn't seen much use otherwise (expect in JavaHL and experimental branches). You'd probably have to add a new operation within the wc_db code first and then work your way up.
