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

RE: Re: notification system rewrite in progress (patch for review)

From: Bill Tutt <billtut_at_microsoft.com>
Date: 2002-06-12 19:20:43 CEST

> From: Greg Stein [mailto:gstein@lyra.org]
> On Tue, Jun 11, 2002 at 11:03:27PM -0700, Bill Tutt wrote:
> > Just to continue prodding this anthill called CollabNet employees, I
> > just realized that libsvn_client applications (i.e. UI apps) need
> > notification hooks that are currently handled via the "Force
> > bad things to happen" Boolean that is (for example) passed into
> > svn_client_merge(), etc...
> whatthefuh? What "Boolean" are you referring to? You're being way too
> opaque.

svn_client_merge (const svn_delta_editor_t *after_editor,
                  void *after_edit_baton,
                  svn_client_auth_baton_t *auth_baton,
                  const char *path1,
                  const svn_client_revision_t *revision1,
                  const char *path2,
                  const svn_client_revision_t *revision2,
                  const char *target_wcpath,
                  svn_boolean_t recurse,
                  svn_boolean_t force,
                  apr_pool_t *pool);

The force parameter in this function's prototype as well as

> Yes, GUIs need notification hooks. The assumption is that the
> would be changed to be able to return a boolean indicating "stop".
(but it
> won't return an error; that will make things way too complicated, and
> theoretically notification callbacks should not raise an eror)

I don't know why you think notification hooks returning an error makes
things too complicated, if it returns a Subversion error the error
context can get properly and simply propagated from the notification
hook back to the invoking location of the code that filled in the
notification hook structure.

It'd be nice if notification callbacks didn't raise an error, but how do
you know what needs to happen inside of a notification hook? It might
involve lots of operations that could fail with some useful message.
Admittedly they probably indicate bugs in the code, but not having one
makes debugging any such bugs much more annoying and time consuming.
Propagating error state as much as possible is always a good thing.

> > i.e. A GUI is probably going to want to pop up a Yes/No dialog when
> > these situations occur.
> What situations? Clarity...

Whenever svn_client_merge, or svn_client_delete is called one of the
current parameters is a svn_boolean_t called force. It's certainly
conceivable for a GUI to want to display a modal dialog when the current
executing code examines the force option and be allowed to return the
users decision back into the operation in progress.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jun 12 19:21:14 2002

This is an archived mail posted to the Subversion Dev mailing list.