Re: svn commit: r1003211 - /subversion/trunk/tools/dev/unix-build/Makefile.svn

> +	 <at> echo "perl:       `perl -version | grep ^This | cut -d' ' -f4 | sed -e 's/^v//'`"

Simpler: perl -V:version

Re: svn commit: r1003227 - /subversion/site/publish/docs/community-guide/releasing.part.html

stsp <at> apache.org wrote on Thu, Sep 30, 2010 at 20:05:54 -0000:
> +++ subversion/site/publish/docs/community-guide/releasing.part.html Thu Sep 30 20:05:53 2010
>  <at>  <at>  -1096,7 +1096,7  <at>  <at>  manager.)</p>
> -<div class="h3" id="releasing-not">
> +<div class="h2" id="releasing-not">
>  <h2>How <em>not</em> to make a Subversion release

What is the effect of this change?  I don't see any reference in the
CSS, etc, to an "h2" or "h3" class?

trunk failing tests on Windows XP (32 bit): prop-tests.py 33, stat-tests.py 5, upgrade-tests.py 11

Hi devs,

The following tests fail on my machine (Windows XP 32-bit, built with
VCE 2008, ra_local):

- prop-tests.py 33: test properties of obstructed subdirectories
svn: Can't open directory
'C:\research\svn\client_build\svn_trunk\Release\subversion\tests\cmdline\svn-test-work\working_copies\prop_tests-33\A\C':
The directory name is invalid.

- stat-tests.py 5: status on versioned items whose type has changed
svn: Can't open directory
'C:\research\svn\client_build\svn_trunk\Release\subversion\tests\cmdline\svn-test-work\working_copies\stat_tests-5\A':
The directory name is invalid.

- upgrade_tests.py 11: missing directories and obstructing files
svn: Can't open directory
'C:\research\svn\client_build\svn_trunk\Release\subversion\tests\cmdline\svn-test-work\working_copies\upgrade_tests-11\A\D':
The directory name is invalid.

They all seem to try to open some path as a directory, but it isn't a
directory (but an empty file or something).

Am I the only one seeing this? Is this known/normal?

Please find the fail log files in attachment.

Cheers,
--

-- 
Johan

RE: trunk failing tests on Windows XP (32 bit): prop-tests.py 33, stat-tests.py 5, upgrade-tests.py 11

> -----Original Message-----
> From: Johan Corveleyn [mailto:jcorvel <at> gmail.com]
> Sent: vrijdag 1 oktober 2010 1:51
> To: Subversion Development
> Subject: trunk failing tests on Windows XP (32 bit): prop-tests.py 33,
> stat-tests.py 5, upgrade-tests.py 11
> 
> Hi devs,
> 
> The following tests fail on my machine (Windows XP 32-bit, built with
> VCE 2008, ra_local):
> 
> - prop-tests.py 33: test properties of obstructed subdirectories
> svn: Can't open directory
> 'C:\research\svn\client_build\svn_trunk\Release\subversion\tests\cmdlin
> e\svn-test-work\working_copies\prop_tests-33\A\C':
> The directory name is invalid.
> 
> - stat-tests.py 5: status on versioned items whose type has changed
> svn: Can't open directory
> 'C:\research\svn\client_build\svn_trunk\Release\subversion\tests\cmdlin
> e\svn-test-work\working_copies\stat_tests-5\A':
> The directory name is invalid.
> 
> - upgrade_tests.py 11: missing directories and obstructing files
> svn: Can't open directory
> 'C:\research\svn\client_build\svn_trunk\Release\subversion\tests\cmdlin
> e\svn-test-work\working_copies\upgrade_tests-11\A\D':
> The directory name is invalid.
> 

[PATCH] extend svn_subst_translate_string() to record whether re-encoding and/or line ending translation were performed

Following Daniel Shahaf's suggestion of splitting the "allow svnsync
to translate non-UTF-8 log messages to UTF-8" work into two patches, I
have revised my changes, prepared one of the two patches, and have
attached the one patch and suggested log message to this e-mail.

Adds a public API function, svn_subst_translate_string2(), an extension of
svn_subst_translate_string(), that has two, additional output parameters for
determining whether re-encoding and/or line ending translation were performed.


As discussed at:
  http://thread.gmane.org/gmane.comp.version-control.subversion.user/100020

  http://thread.gmane.org/gmane.comp.version-control.subversion.devel/122518

  http://thread.gmane.org/gmane.comp.version-control.subversion.devel/122550



* subversion/include/svn_subst.h
  (svn_subst_translate_string2): New function.
  (svn_subst_translate_string): Deprecated in favor of
    svn_subst_translate_string2().

* subversion/libsvn_subr/subst.c
  (translate_newline): Added the new parameter EOL_TRANSLATED, the value at
    which is set to TRUE if translate_newline() wrote out the line ending in
    NEWLINE_BUF with a different line ending in EOL_STR.
  (translation_baton): Added the TRANSLATED_EOL field.
  (create_translation_baton): Added a new parameter TRANSLATED_EOL that is
    passed to the resulting translation_baton.
  (translate_chunk): Modified the three calls to translate_newline() to pass

Re: svn commit: r1002898 - in /subversion/trunk: ./ subversion/include/svn_string.h subversion/libsvn_subr/svn_string.c

  On 30.09.2010 02:12, Blair Zajac wrote:
> On 09/29/2010 05:01 PM, stefan2 <at> apache.org wrote:
>> Author: stefan2
>> Date: Thu Sep 30 00:01:45 2010
>> New Revision: 1002898
>>
>> URL: http://svn.apache.org/viewvc?rev=1002898&view=rev
>> Log:
>> Merge r1001413 from the performance branch.
>>
>> Improve documentation on svn_stringbuf_appendbyte.
>>
>> Approved by: Hyrum K. Wright<hyrum_wright_at_mail.utexas.edu>
>>
>
>>   /** Append a single character  <at> a byte onto  <at> a targetstr.
>> + * This is an optimized version of  <at> ref svn_stringbuf_appendbytes
>> + * that is much faster to call and execute. Gains vary with the ABI.
>
> When you say ABI, you actually mean the C calling convention ABI, not 
> the Subversion ABI?  I think this would be a good distinction to 
> document here, since Subversion has its own ABI that we strictly 
> maintain.

I mean calling convention. Where is the Subversion ABI defined?

-- Stefan^2.

Re: Some tips on profiling

  On 30.09.2010 04:28, Ramkumar Ramachandra wrote:
> Hi Stefan,
>
> Stefan Fuhrmann writes:
>> My measurements seem to support what Philip wrote:
>> The expensive part is run on the server. Even with my
>> optimized server, the svnrdump CPU usage is less than
>> the time taken by the server. Some numbers (hot file
>> cache):
>>
>> svnadmin dump
>>      1.7 trunk 70s real  66s user 4s system
>>      perf-branch 30s real 28s user 2s system
>>
>> 1.7 trunk svnrdump
>>      ra-local 88s real 81s user 7s system
>>      svn: (1.7 trunk) 99s real 6s user 4s system
>>      svn: (perf-branch, cold)  72s real 5s user 6s system
>>      svn: (perf-branch, hot)  17s real 5s user 5s system
>>
>> Thus, svnrdump is slower only for ra-local where it is
>> of no particular use in the first place. To really speed
>> things up, the caching infrastructure from the performance
>> branch should be merged into /trunk.
> Wow, that looks awesome. Yeah, Daniel suggested that I run svnrdump
> against your perf branch yesterday, but I wasn't able to get your
> branch to build:
> subversion/libsvn_subr/svn_file_handle_cache.c:890: error: 'svn_file_handle_cache_t' has no
member named 'mutex'

Re: [PATCH] extend svn_subst_translate_string() to record whether re-encoding and/or line ending translation were performed

Daniel Trebbien wrote:
> Following Daniel Shahaf's suggestion of splitting the "allow svnsync
> to translate non-UTF-8 log messages to UTF-8" work into two patches, I
> have revised my changes, prepared one of the two patches, and have
> attached the one patch and suggested log message to this e-mail.

[[[

> Adds a public API function, svn_subst_translate_string2(), an extension of
> svn_subst_translate_string(), that has two, additional output parameters for
> determining whether re-encoding and/or line ending translation were performed.

If we're going to add this functionality to _translate_string(),
shouldn't we also add it to the other variants - _detranslate_string,
_translate_cstring2, _stream_translated, _copy_and_translate4?

I see you're adding the infrastructure into the (new) bodies of
_translate_cstring2 and _stream_translated, just not (yey) exposing it
in their APIs.

I'm not sure.  The set of 'translation' functions is already messy and
it's not clear to me how useful this new functionality will be.

I wonder if any of the current users of these functions need to know
whether any change was made, and currently find out by executing a full
text comparison of the result.  If so, then this enhancement should
allow us to simplify those callers.

> As discussed at:
>   http://thread.gmane.org/gmane.comp.version-control.subversion.user/100020

RE: [PATCH] extend svn_subst_translate_string() to record whether re-encoding and/or line ending translation were performed

> -----Original Message-----
> From: Julian Foad [mailto:julian.foad <at> wandisco.com]
> Sent: vrijdag 1 oktober 2010 12:58
> To: Daniel Trebbien
> Cc: Subversion Development; Daniel Shahaf; Gavin Beau Baumanis
> Subject: Re: [PATCH] extend svn_subst_translate_string() to record
> whether re-encoding and/or line ending translation were performed

[Copying from this mail, as it already quotes the sources that are separate attachments for me]

> Please update the doc string of this function to mention the new
> parameter, or write a partial doc string if it doesn't have one.  (Hmm,
> I see it does have one but it's quite inaccurate.  I will update the
> current version now.)
> 
> >  <at>  <at>  -650,7 +651,13  <at>  <at>  translate_newline(const char *eol_str,
> >        *src_format_len = newline_len;
> >      }
> >    /* Translate the newline */
> > -  return translate_write(dst, eol_str, eol_str_len);
> > +  svn_error_t *err = translate_write(dst, eol_str, eol_str_len);
> 
> No declarations mixed in with statements - we stick to C'89 rules.  But
> I don't think there is any need to insert this new code *after* the
> write - it can just as well go before the write, leaving the 'return'
> how it was.

The code can just use SVN_ERR() here, as you can't be sure the output is available in error conditions
anyway, so the extra check can be avoided on errors.
> 

Re: disallow merges into mixed-rev WCs by default?

Stefan Sperling wrote:
> I'd like to propose that we disallow merges into mixed-revision working
> copies by default for 1.7, and only allow such merges if a special command
> line option has been passed.
> 
> The reason for this is that merges into mixed-rev WCs can easily create
> conflicts which are tedious to resolve. Even if you know about the problem
> and try to run "svn update" before every merge, it's quite easy to forget
> about running "svn update".
> 
> Also, we've been advertising this as best practice for some time.
> Quoting the book on the matter:
>   Never merge into working copies with a mixture of working revision
>   numbers, or with “switched” subdirectories (as described next in the
>   section called “Traversing Branches”). A merge target should be a
>   working copy which represents a single location in the repository at a
>   single point in time.
> 
> Note that while the book recommends not to merge into working copies
> with switched subtrees, I don't intend to enforce this by default.
> 
> I've talked about this with Paul on IRC and he had no objections.
> See http://colabti.org/irclogger/irclogger_log/svn-dev?date=2010-09-30#l468
> for the full discussion.
> 
> Below is a work-in-progress diff that starts making this change.
> Tests fail with it. I've only checked the merge tests for now.
> 
> Before continuing with this, fixing up tests, bumping APIs, and eventually
> adding the command line option that allows merges into mixed-rev WCs,