Re: svn commit: rev 1623 - trunk/subversion/include trunk/subversion/libsvn_client trunk/subversion/clients/cmdline

On Wed, 2002-04-03 at 15:41, Greg Stein wrote:

> Is it reasonable now to remove the before/after editor concept [from across
> the interface] ? i.e. stop composing editors and shift to a pure
> notification system?

I'm not sure why you want to remove the editor-compositon interface
across the *whole* svn_client.h interface.

In this particular case of svn_client_commit, we were forced to abandon
the trace-commit editor being passed in. Why? Because the application
layer is no longer in a position to assume where the trace-editor should
be anchored. Only the client and wc libraries can figure that out now.

Now granted, we *could* have had libsvn_client harvest the disjoint
commit targets, calculate the anchor, and then use a factory-callback
into the app-layer to request a custom trace editor. But instead, we
opted for just sending back information via our simple notification
system.

But I'm not convinced this means that we should abandon *all*
trace-editors, and all before/after editors throughout svn_client.h.
For example, I'm 90% sure that when we handle updates in disjoint
working copies, we won't need to change a thing. The app-layer can
still compute an anchor for the trace-update-editor and pass that into
svn_client_update. (The update is guaranteed to apply to whatever
target the user passed on the commandline.)

Really, I think editors are far more rich and detailed than a simple
feedback table. They receive much more information. And future
applications may want to implement rich editors.