[PATCH] Fix typo in Italian translation
Hi, the attached patch fixes a trivial typo in the Italian translation when using "svn propedit". If you have any comments, please CC me: I am not subscribed to the list. [[[ Fix typo in Italian translation (volore). ]]] Regards, Andrea. Index: subversion/po/it.po === --- subversion/po/it.po (revisione 1702314) +++ subversion/po/it.po (copia locale) @@ -10134,7 +10134,7 @@ msgstr "" #: ../svn/propedit-cmd.c:158 #, c-format msgid "Set new value for property '%s' on revision %ld\n" -msgstr "Impostazione di un nuovo volore per la proprietà '%s' nella revisione %ld\n" +msgstr "Impostazione di un nuovo valore per la proprietà '%s' nella revisione %ld\n" #: ../svn/propedit-cmd.c:164 #, c-format
Re: svn commit: r1702305 - /subversion/trunk/subversion/libsvn_subr/stream.c
Stefan Fuhrmann writes: + * Special files like STDIN will have no flags set at all. In that case, + * we can't filter and must allow any operation - which may then fail at + * the APR level further down the stack. + */ + apr_uint32_t flags = apr_file_flags_get(file); + svn_boolean_t supports_read = (flags == 0) || (flags & APR_READ); + svn_boolean_t supports_write = (flags == 0) || (flags & APR_WRITE); Files corresponding to the standard I/O streams actually have the appropriate APR_READ / APR_WRITE flags set starting from APR 1.3 — see, for example, apr_file_open_flags_stderr() in [1]. Hence, the (flags == 0) check is going to return false for them. > Note that this check is not perfect for arbitrary APR file handles > (may enable more functions than the handle actually supports) but > works correctly for our STD* streams and the files opened through > our svn_io_* API. The actual problem, to my mind, is that relying on flags to determine if the file allows reading or writing, is fragile. There are examples of apr_file_t's that don't have the corresponding flags, but still allow reading and writing, and svn_stream_from_aprfile2() is going to break for them. One example would be apr_file_pipe_create() on Unix that sets APR_INHERIT flag on the created pipe [2]. Another example is creating a pipe on Windows that currently initializes flags to zero [3]. [1] https://svn.apache.org/repos/asf/apr/apr/branches/1.3.x/file_io/unix/open.c [2] https://svn.apache.org/repos/asf/apr/apr/trunk/file_io/unix/pipe.c [3] https://svn.apache.org/repos/asf/apr/apr/trunk/file_io/win32/pipe.c Regards, Evgeny Kotkov
Re: svn commit: r1702305 - /subversion/trunk/subversion/libsvn_subr/stream.c
On 10.09.2015 21:40, Branko Čibej wrote: > On 10.09.2015 21:06, Stefan Fuhrmann wrote: >> On Thu, Sep 10, 2015 at 9:00 PM, Bert Huijben wrote: >> -Original Message- From: stef...@apache.org [mailto:stef...@apache.org] Sent: donderdag 10 september 2015 20:14 To: comm...@subversion.apache.org Subject: svn commit: r1702305 - /subversion/trunk/subversion/libsvn_subr/stream.c Author: stefan2 Date: Thu Sep 10 18:13:52 2015 New Revision: 1702305 URL: http://svn.apache.org/r1702305 Log: APR file based streams shall not superficially support read or write functions when we know that the APR file itself does not. Instead, they will now return a "not supported" stream error. Note that this check is not perfect for arbitrary APR file handles (may enable more functions than the handle actually supports) but works correctly for our STD* streams and the files opened through our svn_io_* API. >>> This patch breaks JavaHL's tunnel tests on at least one buildbot. >>> >>> >>> https://ci.apache.org/builders/svn-x64-centos-gcc/builds/277/steps/Test%20bindings%20fsfs%2Bra_serf/logs/stdio >>> >>> (The JavaHL tests PASS on Windows) >>> >> Ok. I'll wait for Brane to maybe have a look at it. Could well be >> that we uncovered an inconsistency in the bindings. > I noticed the failure; I'll take a look in the morning. The > "inconsistency" is probably in APR, since AFAIK it uses anonymous pipes > on Windows but just plain file handles on Unix in this particular case. > > I'm surprised the test passed on OSX but failed on CentOS/Linux, though. Ah, it did not pass on OSX, I just didn't wait long enough. That's good (I think ...) -- Brane
Re: svn commit: r1702305 - /subversion/trunk/subversion/libsvn_subr/stream.c
On 10.09.2015 21:06, Stefan Fuhrmann wrote: > On Thu, Sep 10, 2015 at 9:00 PM, Bert Huijben wrote: > >> >>> -Original Message- >>> From: stef...@apache.org [mailto:stef...@apache.org] >>> Sent: donderdag 10 september 2015 20:14 >>> To: comm...@subversion.apache.org >>> Subject: svn commit: r1702305 - >>> /subversion/trunk/subversion/libsvn_subr/stream.c >>> >>> Author: stefan2 >>> Date: Thu Sep 10 18:13:52 2015 >>> New Revision: 1702305 >>> >>> URL: http://svn.apache.org/r1702305 >>> Log: >>> APR file based streams shall not superficially support read or write >>> functions when we know that the APR file itself does not. Instead, >>> they will now return a "not supported" stream error. >>> >>> Note that this check is not perfect for arbitrary APR file handles >>> (may enable more functions than the handle actually supports) but >>> works correctly for our STD* streams and the files opened through >>> our svn_io_* API. >> This patch breaks JavaHL's tunnel tests on at least one buildbot. >> >> >> https://ci.apache.org/builders/svn-x64-centos-gcc/builds/277/steps/Test%20bindings%20fsfs%2Bra_serf/logs/stdio >> >> (The JavaHL tests PASS on Windows) >> > Ok. I'll wait for Brane to maybe have a look at it. Could well be > that we uncovered an inconsistency in the bindings. I noticed the failure; I'll take a look in the morning. The "inconsistency" is probably in APR, since AFAIK it uses anonymous pipes on Windows but just plain file handles on Unix in this particular case. I'm surprised the test passed on OSX but failed on CentOS/Linux, though. -- Brane
Re: Unsubscribe
Simply pop a mail off to dev-unsubscr...@subversion.apache.org, Katherine. On Thu, Sep 10, 2015 at 3:07 PM, Katherine Sheehan wrote: > I'd like to unsubscribe to this mailing list please. > > Kind regards, > Katherine >
Unsubscribe
I'd like to unsubscribe to this mailing list please. Kind regards, Katherine
Re: svn commit: r1702305 - /subversion/trunk/subversion/libsvn_subr/stream.c
On Thu, Sep 10, 2015 at 9:00 PM, Bert Huijben wrote: > > > > -Original Message- > > From: stef...@apache.org [mailto:stef...@apache.org] > > Sent: donderdag 10 september 2015 20:14 > > To: comm...@subversion.apache.org > > Subject: svn commit: r1702305 - > > /subversion/trunk/subversion/libsvn_subr/stream.c > > > > Author: stefan2 > > Date: Thu Sep 10 18:13:52 2015 > > New Revision: 1702305 > > > > URL: http://svn.apache.org/r1702305 > > Log: > > APR file based streams shall not superficially support read or write > > functions when we know that the APR file itself does not. Instead, > > they will now return a "not supported" stream error. > > > > Note that this check is not perfect for arbitrary APR file handles > > (may enable more functions than the handle actually supports) but > > works correctly for our STD* streams and the files opened through > > our svn_io_* API. > > This patch breaks JavaHL's tunnel tests on at least one buildbot. > > > https://ci.apache.org/builders/svn-x64-centos-gcc/builds/277/steps/Test%20bindings%20fsfs%2Bra_serf/logs/stdio > > (The JavaHL tests PASS on Windows) > Ok. I'll wait for Brane to maybe have a look at it. Could well be that we uncovered an inconsistency in the bindings. Otherwise, I'm happy to revert that change. It simply felt like it belonged with similar changes that were made recently. -- Stefan^2.
RE: svn commit: r1702305 - /subversion/trunk/subversion/libsvn_subr/stream.c
> -Original Message- > From: stef...@apache.org [mailto:stef...@apache.org] > Sent: donderdag 10 september 2015 20:14 > To: comm...@subversion.apache.org > Subject: svn commit: r1702305 - > /subversion/trunk/subversion/libsvn_subr/stream.c > > Author: stefan2 > Date: Thu Sep 10 18:13:52 2015 > New Revision: 1702305 > > URL: http://svn.apache.org/r1702305 > Log: > APR file based streams shall not superficially support read or write > functions when we know that the APR file itself does not. Instead, > they will now return a "not supported" stream error. > > Note that this check is not perfect for arbitrary APR file handles > (may enable more functions than the handle actually supports) but > works correctly for our STD* streams and the files opened through > our svn_io_* API. This patch breaks JavaHL's tunnel tests on at least one buildbot. https://ci.apache.org/builders/svn-x64-centos-gcc/builds/277/steps/Test%20bindings%20fsfs%2Bra_serf/logs/stdio (The JavaHL tests PASS on Windows) Bert
Re: svnfsfs stats division by zero on empty repository
On Tue, Sep 8, 2015 at 12:56 PM, Philip Martin
wrote:
> $ svnadmin create repo
> $ svnfsfs stats repo
> ...
> Extensions by number of representations:
> Floating point exception
>
> Program received signal SIGFPE, Arithmetic exception.
> 0x0040311c in print_extensions_by_changes (stats=0x61bf10,
> pool=0x60c450) at ../src/subversion/svnfsfs/stats-cmd.c:249
> 249 (int)((stats->file_histogram.total.count - sum) * 100 /
> (gdb) l
> 244 }
> 245
> 246 printf(_("%11s %20s (%2d%%) representations\n"),
> 247 "(others)",
> 248 svn__ui64toa_sep(stats->file_histogram.total.count - sum,
> ',', pool),
> 249 (int)((stats->file_histogram.total.count - sum) * 100 /
> 250stats->file_histogram.total.count));
> 251 }
> 252
> 253 /* Print the (up to) 16 extensions in STATS with the largest total
> size of
> (gdb) p stats->file_histogram.total.count
> $1 = 0
>
Thanks for the report, Philip. Fixed in r1702310.
-- Stefan^2.
Re: JavaHL: Hard crash in libsvn_subr-1.dll
Sergey, Thank you for this valuable information. -- Thomas Singer On 10.09.2015 17:46, Sergey Raevskiy wrote: After digging in some disassembly, I've guessed the [libsvn_subr-1.dll+0xc4c20] as svn_relpath_join() which is called with BASE == NULL. So, the crash might be caused by the same issue as in [1] which was already fixed in r1702198 [2]. [1] http://svn.haxx.se/dev/archive-2015-09/0070.shtml [2] http://svn.apache.org/r1702198 On Wed, Sep 9, 2015 at 5:47 PM, Ivan Zhakov wrote: On 9 September 2015 at 16:58, Thomas Singer wrote: What further information do you need for this crash? Stack trace with symbols information at least. -- Ivan Zhakov
Re: JavaHL: Hard crash in libsvn_subr-1.dll
After digging in some disassembly, I've guessed the [libsvn_subr-1.dll+0xc4c20] as svn_relpath_join() which is called with BASE == NULL. So, the crash might be caused by the same issue as in [1] which was already fixed in r1702198 [2]. [1] http://svn.haxx.se/dev/archive-2015-09/0070.shtml [2] http://svn.apache.org/r1702198 On Wed, Sep 9, 2015 at 5:47 PM, Ivan Zhakov wrote: > On 9 September 2015 at 16:58, Thomas Singer wrote: >> What further information do you need for this crash? >> > Stack trace with symbols information at least. > > > -- > Ivan Zhakov
RE: Crash in make_copy_txn()
> -Original Message-
> From: Ivan Zhakov [mailto:i...@visualsvn.com]
> Sent: donderdag 10 september 2015 14:58
> To: dev@subversion.apache.org
> Subject: Crash in make_copy_txn()
>
> TortoiseSVN crash reporter service has several crashes in
> libsvn_wc/wc_db.c:make_copy_txn():
> [[[
> SVN_ERR(svn_wc__db_base_get_info_internal(NULL, &kind, &revision,
> &repos_relpath, &repos_id, NULL,
> NULL, NULL, NULL, NULL, NULL,
> NULL,
> NULL, NULL, NULL,
> wcroot, local_relpath,
> scratch_pool, scratch_pool));
>
> if (last_repos_relpath
> && repos_id == last_repos_id
> && revision == last_revision)
> {
> const char *name = svn_relpath_skip_ancestor(last_repos_relpath,
>repos_relpath);
>
> if (strcmp(name, svn_relpath_basename(local_relpath, NULL)) == 0)
>^^ crash here.
> op_depth = last_op_depth;
> }
> ]]]
Reproduced and fixed with r1702247.
Bert
Re: svn commit: r1700799 - in /subversion/trunk/subversion: include/svn_io.h libsvn_subr/stream.c svnadmin/svnadmin.c svnfsfs/load-index-cmd.c tests/libsvn_subr/stream-test.c
On Wed, Sep 9, 2015 at 12:31 PM, Evgeny Kotkov wrote: > Stefan Fuhrmann writes: > > >> The original commit begins using svn_stream_wrap_buffered_read() during > >> svnadmin load-revprops and svnfsfs load-index. This patch, however, > does > >> something entirely different and adds buffering to *every* stdin. > > > > Sorry for the confusion. I did not intend to actually change the > > implementation of svn_stream_for_stdin this way but simply tried to > > demonstrate a problem with APR buffer reads for "streamy" file handles. > > Thank you for the explanation. > After some debugging I found the reason for the ra-test hang. Once I knew it, it's been kind of obvious from the code: For buffered files, apr_file_read() is more or less equivalent to apr_file_write_full(). Changing that in APR might break APR internals (buffer may be half-filled but not be at EOF) as well as user code (read_full required where a normal read used to be sufficient). > > The underlying problem is still present: If stdin can't deliver data fast > > enough (e.g. some hick-up / long latency on the producer side of a dump | > > load), a buffered APR file will error out while a non-buffered one will > > simply wait & retry. > > > > However, I have yet to try and provoke the error specifically for the > > dump | load scenario. > > I think that this problem is nonexistent. > > A program doesn't need to handle EAGAIN during read() unless it puts the > file > into the non-blocking mode with O_NONBLOCK [1]. We don't do that for > STDIN, > and, irrespectively of what happens with the data on the other side of the > pipe, read() is going to block until the requested data is available. > > [1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/read.html > You are right. I tried various methods to delay the producer side and it never caused the consumer to error out. The ra-test hang mislead me into believing that the EAGAIN handling was the problem. So, you are absolutely right about APR buffering being enough for our non-interactive "read stdin as a single large file" usage in load & friends. My last concern is as follows. We need an alternative implementation for svn_stream_for_stdin. I see 3 options: 1. svn_stream_for_stdin2 with buffered option. 2. Always enable buffering in svn_stream_for_stdin. 3. Some private API. The problem with 1. is that if we use APR_BUFFERED for it, the new API will be add leakage to the abstraction: the user has to know when it is safe to enable buffering. This problem does not occur if the wrapper stream is being used instead. Thus, variant 2 is impossible with APR_BUFFERED but quite possible using the buffering wrapper. The only way it could cause a problem is if some code was to rely on the actual size of a read request from stdin. Since the latter is managed by the OS + C runtime, it is hard to think of a way to make this happen - but still. Having a fall-back would be nice, i.e. variant 1 is safer than 2. Option 3 is basically saying "the public API is not good enough but we don't want to give you a better one". It is, however, the only variant where I would be fully comfortable just using APR buffering. Your thoughts? -- Stefan^2.
Crash in make_copy_txn()
TortoiseSVN crash reporter service has several crashes in
libsvn_wc/wc_db.c:make_copy_txn():
[[[
SVN_ERR(svn_wc__db_base_get_info_internal(NULL, &kind, &revision,
&repos_relpath, &repos_id, NULL,
NULL, NULL, NULL, NULL, NULL, NULL,
NULL, NULL, NULL,
wcroot, local_relpath,
scratch_pool, scratch_pool));
if (last_repos_relpath
&& repos_id == last_repos_id
&& revision == last_revision)
{
const char *name = svn_relpath_skip_ancestor(last_repos_relpath,
repos_relpath);
if (strcmp(name, svn_relpath_basename(local_relpath, NULL)) == 0)
^^ crash here.
op_depth = last_op_depth;
}
]]]
Stack trace is:
[[[
>libsvn_tsvn.dll!make_copy_txn(svn_wc__db_wcroot_t * wcroot, const char *
> local_relpath, __int64 last_repos_id, const char * last_repos_relpath, long
> last_revision, int last_op_depth, int shadowed, int root_shadow_depth,
> apr_pool_t * scratch_pool) Line 15120C
libsvn_tsvn.dll!make_copy_txn(svn_wc__db_wcroot_t * wcroot, const
char * local_relpath, __int64 last_repos_id, const char *
last_repos_relpath, long last_revision, int last_op_depth, int
shadowed, int root_shadow_depth, apr_pool_t * scratch_pool) Line 15158
C
libsvn_tsvn.dll!svn_wc__db_op_make_copy_internal(svn_wc__db_wcroot_t
* wcroot, const char * local_relpath, int move_move_info, const
svn_skel_t * conflicts, const svn_skel_t * work_items, apr_pool_t *
scratch_pool) Line 15285C
libsvn_tsvn.dll!db_base_remove(svn_wc__db_wcroot_t * wcroot,
const char * local_relpath, svn_wc__db_t * db, int keep_as_working,
int mark_not_present, int mark_excluded, long marker_revision,
svn_skel_t * conflict, svn_skel_t * scratch_pool, apr_pool_t *) Line
2175C
libsvn_tsvn.dll!svn_wc__db_base_remove(svn_wc__db_t * db, const
char * local_abspath, int keep_as_working, int mark_not_present, int
mark_excluded, long marker_revision, svn_skel_t * conflict, svn_skel_t
* scratch_pool, apr_pool_t *) Line 2459C
libsvn_tsvn.dll!delete_entry(const char * path, long revision,
void * parent_baton, apr_pool_t * pool) Line 1791C
libsvn_tsvn.dll!delete_entry(const char * path, long
base_revision, void * parent_baton, apr_pool_t * pool) Line 99C
libsvn_tsvn.dll!ra_svn_handle_delete_entry(svn_ra_svn_conn_st *
conn, apr_pool_t * pool, const apr_array_header_t * params,
ra_svn_driver_state_t * ds) Line 543C
libsvn_tsvn.dll!svn_ra_svn_drive_editor2(svn_ra_svn_conn_st *
conn, apr_pool_t * pool, const svn_delta_editor_t * editor, void *
edit_baton, int * aborted, int for_replay) Line 959C
libsvn_tsvn.dll!ra_svn_finish_report(void * baton, apr_pool_t *
pool) Line 299C
libsvn_tsvn.dll!svn_wc_crawl_revisions5(svn_wc_context_t *
wc_ctx, const char * local_abspath, const svn_ra_reporter3_t *
reporter, void * report_baton, int restore_files, svn_depth_t depth,
int honor_depth_exclude, int depth_compatibility_trick, int
use_commit_times, svn_error_t * (void *) * cancel_func, void *
cancel_baton, void (void *, const svn_wc_notify_t *, apr_pool_t *) *
notify_func, void * notify_baton, apr_pool_t * scratch_pool) Line 695
C
libsvn_tsvn.dll!update_internal(long * result_rev, int *
timestamp_sleep, apr_hash_t * conflicted_paths, svn_ra_session_t * *
ra_session_p, const char * local_abspath, const char * anchor_abspath,
const svn_opt_revision_t * revision, svn_depth_t depth, int
depth_is_sticky, int ignore_externals, int allow_unver_obstructions,
int adds_as_modification, int notify_summary, svn_client_ctx_t * ctx,
apr_pool_t * result_pool, apr_pool_t * scratch_pool) Line 501C
libsvn_tsvn.dll!svn_client__update_internal(long * result_rev,
int * timestamp_sleep, const char * local_abspath, const
svn_opt_revision_t * revision, svn_depth_t depth, int depth_is_sticky,
int ignore_externals, int allow_unver_obstructions, int
adds_as_modification, int make_parents, int innerupdate,
svn_ra_session_t * ra_session, svn_client_ctx_t * ctx, apr_pool_t *
pool) Line 648C
]]]
Local variables are not available because there is no full dumps for this crash.
--
Ivan Zhakov
RE: Crash in calculate_repos_relpath()
> -Original Message-
> From: Ivan Zhakov [mailto:i...@visualsvn.com]
> Sent: woensdag 9 september 2015 17:23
> To: Bert Huijben ; dev@subversion.apache.org
> Subject: Crash in calculate_repos_relpath()
>
> I was looking to the most reported TortoiseSVN crash reports and found
> many crash in libsvn_wc/update_editor.c:551 in function
> calculate_repos_relpath() due calling to svn_relpath_join() with BASE
> == NULL:
> [[[
> if (old_repos_relpath == NULL)
> {
> SVN_ERR_ASSERT(pb != NULL);
> *new_repos_relpath = svn_relpath_join(pb->new_repos_relpath, name,
> result_pool);
> }
> ]]]
> Bert, do you have any ideas why PB->NEW_REPOS_RELPATH could be NULL?
This error was possible in case an ancestor of the path was skipped, and then a
file or directory was added.
Added fix and testcase in r1702198.
Bert
