How to recognize that an SVN_ERR_ASSERT() triggered Re: svn_error_purge_tracing() and clearing the errors Re: svn commit: r1051763 - in /subversion/trunk/subversion: include/private/svn_repos_private.

Daniel Shahaf wrote on Fri, Dec 24, 2010 at 10:48:24 +0200: > Blair Zajac wrote on Thu, Dec 23, 2010 at 17:09:31 -0800: > > On 12/23/10 3:01 AM, Daniel Shahaf wrote: > >> I've made a quick sketch --- looks good? > > > > The suggestions look good. > > > > We could add some more tests, checking the b

Re: svn_error_purge_tracing() and clearing the errors Re: svn commit: r1051763 - in /subversion/trunk/subversion: include/private/svn_repos_private.h libsvn_repos/commit.c mod_dav_svn/version.c

Blair Zajac wrote on Thu, Dec 23, 2010 at 17:09:31 -0800: > On 12/23/10 3:01 AM, Daniel Shahaf wrote: >> I've made a quick sketch --- looks good? > > The suggestions look good. > > We could add some more tests, checking the behavior with SVN_NO_ERROR > input and one where all errors are tracing, w

Re: [PATCH] Fix some deprecation warnings

On Wednesday 22 December 2010 06:42 PM, Daniel Shahaf wrote: Kamesh Jayachandran wrote on Wed, Dec 22, 2010 at 15:10:46 +0530: On 12/22/2010 02:02 AM, vijay wrote: Hi, I have attached a patch that fixes few deprecation warnings while compiling libsvn_client/log.c. Attached log message also. T

[PATCH] Fix a bug in dirent_uri.c:svn_uri_condense_targets()

Hi, This patch fixes the bug reported in http://svn.haxx.se/dev/archive-2010-12/0592.shtml . We need to copy the value of PCOMMON from SCRATCH_POOL to RESULT_POOL since we are exiting early when there is only one target uri to work on. Attached the patch and log message. Thanks & Regard

Re: [RFC] diff-optimizations-bytes branch: avoiding function call overhead (?)

On 23.12.2010 03:44, Gavin Beau Baumanis wrote: Hi Johan, I was intrigued by your requirement to create a large file for testing. I remember from a really long time ago when I learnt C, that we used a specific algorithm for creating "natural" and "random" text. With some help from Mr.Google fou

Re: [PATCH] Fix a bug in dirent_uri.c:svn_uri_condense_targets()

On Fri, Dec 24, 2010 at 4:33 AM, vijay wrote: > Hi, > > This patch fixes the bug reported in > http://svn.haxx.se/dev/archive-2010-12/0592.shtml   . We need to copy the > value of PCOMMON from SCRATCH_POOL to RESULT_POOL since we are exiting early > when there is only one target uri to work on. >

Re: Safe to add a field to svn_error_t?

On Fri, Dec 24, 2010 at 12:10 AM, Blair Zajac wrote: > The addition of "tracing" to svn_error_t in 1.7 currently uses a special > message string "traced call".  Instead of doing this, can we safely add an > svn_boolean_t to svn_error_t the indicates if it is a traced error? > > While svn_error_t i

Re: [RFC] diff-optimizations-bytes branch: avoiding function call overhead (?)

On 20.12.2010 02:43, Johan Corveleyn wrote: On Wed, Dec 15, 2010 at 10:58 AM, Stefan Fuhrmann wrote: On 15.12.2010 02:30, Stefan Fuhrmann wrote: On 14.12.2010 23:35, Johan Corveleyn wrote: Thoughts? Two things you might try: * introduce a local variable for afile[i] * replace the for() loop

Re: [RFC] diff-optimizations-bytes branch: avoiding function call overhead (?)

On 24.12.2010 14:25, Stefan Fuhrmann wrote: On 23.12.2010 03:44, Gavin Beau Baumanis wrote: Hi Johan, I was intrigued by your requirement to create a large file for testing. I remember from a really long time ago when I learnt C, that we used a specific algorithm for creating "natural" and "ra

Re: [PATCH] svn info - changing hard coded error message to specific one.

On 12/23/2010 07:27 AM, Julian Foad wrote: >>From IRC: > > julianf: We changed error codes in libsvn_wc all over the place. > I don't think we see strict error codes as part of the documented > behavior, unless it is in the function documentation I agree with this. Any time a specific error cod

Re: [PATCH] svn info - changing hard coded error message to specific one.

On Fri, 2010-12-24, C. Michael Pilato wrote: > On 12/23/2010 07:27 AM, Julian Foad wrote: > >>From IRC: > > > > julianf: We changed error codes in libsvn_wc all over the place. > > I don't think we see strict error codes as part of the documented > > behavior, unless it is in the function documen

Re: [PATCH] Fix some deprecation warnings

On Friday 24 December 2010 03:46 PM, vijay wrote: On Wednesday 22 December 2010 06:42 PM, Daniel Shahaf wrote: Kamesh Jayachandran wrote on Wed, Dec 22, 2010 at 15:10:46 +0530: On 12/22/2010 02:02 AM, vijay wrote: Hi, I have attached a patch that fixes few deprecation warnings while compiling

Re: Safe to add a field to svn_error_t?

On 12/24/10 6:07 AM, Hyrum K Wright wrote: On Fri, Dec 24, 2010 at 12:10 AM, Blair Zajac wrote: The addition of "tracing" to svn_error_t in 1.7 currently uses a special message string "traced call". Instead of doing this, can we safely add an svn_boolean_t to svn_error_t the indicates if it is

RE: [PATCH] Fix some deprecation warnings

Thanks Vijay. Committed in r1052547. With regards Kamesh Jayachandran -Original Message- From: Vijayaguru Guruchave Sent: Fri 12/24/2010 9:42 PM To: dev@subversion.apache.org Cc: Daniel Shahaf; Kamesh Jayachandran Subject: Re: [PATCH] Fix some deprecation warnings On Friday 24 Decemb

Re: [PATCH] Fix syntax inconsistency and update comments.

Noorul Islam K M writes: > "Hyrum K. Wright" writes: > >> On Wed, Dec 22, 2010 at 12:27 AM, Noorul Islam K M wrote: >> >>> >>> Find attached minor patch which makes 'if' syntax consistent and also >>> some comment improvements. >>> >>> Log >>> >>> [[[ >>> >>> Fix syntax inconsistency and update

Re: [PATCH] svn info - changing hard coded error message to specific one.

Julian Foad writes: > On Fri, 2010-12-24, C. Michael Pilato wrote: > >> On 12/23/2010 07:27 AM, Julian Foad wrote: >> >>From IRC: >> > >> > julianf: We changed error codes in libsvn_wc all over the place. >> > I don't think we see strict error codes as part of the documented >> > behavior, unle