You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "Peter N. Lundblad" <pe...@famlundblad.se> on 2004/05/19 19:47:52 UTC
Issue 780 and status and notify functions
Hi,
While solving issue #780 I came across the little problem that the return
value of svn_wc_notify_func_t and svn_wc_status_func_t is void, so they
can't report failure. So, in the current interface, we have to ignore any
printf errors there and continue.
Do we want to change the interfaces for these functions (implying new
APIs, deprecating the old and all that) or is it sufficient to just print
a warning to stderr (once!), ingore the error and continue?
Thanks,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: API cleanups for 2.0 (was Re: Issue 780 and status and notify functions)
Posted by kf...@collab.net.
Branko Čibej <br...@xbc.nu> writes:
> I'd prefer a 2.0 API meta-issue that lists all the specific API
> changes as dependencies. That lets you create nice dependency trees,
> jump back and forth between dependent/depending issues, etc.
Done. The meta-issue is #1880, and 1881-1886 are the dependencies.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: API cleanups for 2.0 (was Re: Issue 780 and status and notify
functions)
Posted by Branko Čibej <br...@xbc.nu>.
Greg Hudson wrote:
>On Mon, 2004-05-24 at 09:39, kfogel@collab.net wrote:
>
>
>>No reason for that list to be private, yah. Should we file one issue
>>for general API cleanups, or N issues, one per cleanup?
>>
>>
>
>The main problem with using one issue for N tasks is that it's hard to
>keep track of what's finished and what's not. We could make a keyword,
>perhaps.
>
>
I'd prefer a 2.0 API meta-issue that lists all the specific API changes
as dependencies. That lets you create nice dependency trees, jump back
and forth between dependent/depending issues, etc.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: API cleanups for 2.0 (was Re: Issue 780 and status and notify functions)
Posted by "C. Michael Pilato" <cm...@collab.net>.
Greg Hudson <gh...@MIT.EDU> writes:
> 1. Callbacks should always have pool arguments. Otherwise we wind up
> creating and destroying subpools in the callbacks, which is
> anachronistic and less efficient than the usual iteration-pool
> approach. Specific places I have noticed lack of callbacks include the
> svn_stream callbacks and svn_txdelta_window_handler_t.
Also, all callbacks should return svn_error_t's.
> 3. svn_fs_unparse_id should return a C string.
+1
> 4. The relationship between svn_fs_abort_txn and svn_fs_purge_txn feels
> strange and implementation-dependent. Perhaps the easiest answer is to
> ditch svn_fs_abort_txn() and make svn_fs_purge_txn() work on live
> transactions.
If we do this, then "abort" is probably the right unified function
name to use.
> 6. Notification callbacks should have an error return, not a void
> return.
See previous comment re: callbacks.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
API cleanups for 2.0 (was Re: Issue 780 and status and notify
functions)
Posted by Greg Hudson <gh...@MIT.EDU>.
On Mon, 2004-05-24 at 09:39, kfogel@collab.net wrote:
> No reason for that list to be private, yah. Should we file one issue
> for general API cleanups, or N issues, one per cleanup?
The main problem with using one issue for N tasks is that it's hard to
keep track of what's finished and what's not. We could make a keyword,
perhaps.
> Maybe start by posting your list, then we'll go from there...
Sure. Some of these could be "fixed" in 1.x by adding new APIs and
deprecating old ones, but it mostly doesn't seem worthwhile since we
wouldn't be getting any user-visible functionality out of it.
1. Callbacks should always have pool arguments. Otherwise we wind up
creating and destroying subpools in the callbacks, which is
anachronistic and less efficient than the usual iteration-pool
approach. Specific places I have noticed lack of callbacks include the
svn_stream callbacks and svn_txdelta_window_handler_t.
2. Right now, the svn_txdelta interface has this little side-feature
tacked on where it will, in addition to computing a delta, calculate the
MD5 sum of the target data passed in. This is totally out of scope for
the delta interface; we should take out that functionality and replace
it with a meta-stream which computes MD5 sums while reading or writing
data from an underlying stream.
3. svn_fs_unparse_id should return a C string.
4. The relationship between svn_fs_abort_txn and svn_fs_purge_txn feels
strange and implementation-dependent. Perhaps the easiest answer is to
ditch svn_fs_abort_txn() and make svn_fs_purge_txn() work on live
transactions.
5. Our timestamp parser should eliminate support for the deprecated
format.
6. Notification callbacks should have an error return, not a void
return.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Issue 780 and status and notify functions
Posted by kf...@collab.net.
Greg Hudson <gh...@MIT.EDU> writes:
> (I have a private list of API issues to fix come 2.0 time, but maybe the
> project should have a central one as well.)
No reason for that list to be private, yah. Should we file one issue
for general API cleanups, or N issues, one per cleanup?
Maybe start by posting your list, then we'll go from there...
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Issue 780 and status and notify functions
Posted by kf...@collab.net.
"Peter N. Lundblad" <pe...@famlundblad.se> writes:
> > On Wed, 2004-05-19 at 15:47, Peter N. Lundblad wrote:
> > > Do we want to change the interfaces for these functions (implying new
> > > APIs, deprecating the old and all that) or is it sufficient to just print
> > > a warning to stderr (once!), ingore the error and continue?
> >
> > I think we should mark this as something to fix in 2.0, and take the
> > warning approach you outlined for now.
> >
> Did so.
Peter, did you mark this in an issue somewhere? I don't see it in any
of the (uh, "either of the") 2.0 issues...
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Issue 780 and status and notify functions
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Fri, 21 May 2004, Greg Hudson wrote:
> On Wed, 2004-05-19 at 15:47, Peter N. Lundblad wrote:
> > Do we want to change the interfaces for these functions (implying new
> > APIs, deprecating the old and all that) or is it sufficient to just print
> > a warning to stderr (once!), ingore the error and continue?
>
> I think we should mark this as something to fix in 2.0, and take the
> warning approach you outlined for now.
>
Did so.
> (I have a private list of API issues to fix come 2.0 time, but maybe the
> project should have a central one as well.)
>
Would probably be good.
Thanks,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Issue 780 and status and notify functions
Posted by Greg Hudson <gh...@MIT.EDU>.
On Wed, 2004-05-19 at 15:47, Peter N. Lundblad wrote:
> Do we want to change the interfaces for these functions (implying new
> APIs, deprecating the old and all that) or is it sufficient to just print
> a warning to stderr (once!), ingore the error and continue?
I think we should mark this as something to fix in 2.0, and take the
warning approach you outlined for now.
(I have a private list of API issues to fix come 2.0 time, but maybe the
project should have a central one as well.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org