Mikael Rahbek wrote:
As part of our development we use a substituted drive (Windows 10):
E.g.:
subst r: C:\Data\Production_work_7_1_Clean
In the root of r: there is now always shown a change with status missing
If checking from C:\Data\Production_work_7_1_Clean it shows the status
correct.
Julian Foad wrote:
> Branko Čibej wrote (to dev@subversion.a.o):
>> On 26.02.2018 18:39, Julian Foad wrote:
>>> (CC'ing Subversion as Subversion's build system both uses and kind-of
>>> duplicates this.)
>>>
>>> APR's 'build/buildcheck.sh' say
Branko Čibej wrote (to dev@subversion.a.o):
> On 26.02.2018 18:39, Julian Foad wrote:
>> (CC'ing Subversion as Subversion's build system both uses and kind-of
>> duplicates this.)
>>
>> APR's 'build/buildcheck.sh' says:
>> [[[
>> # Require libtool 1.4 or newe
(CC'ing Subversion as Subversion's build system both uses and kind-of
duplicates this.)
APR's 'build/buildcheck.sh' says:
[[[
# Require libtool 1.4 or newer
libtool=`build/PrintPath glibtool1 glibtool libtool libtool15 libtool14`
...
]]]
and fails if it doesn't find a 'libtool' binary at
It came to my notice that apr_file_trunc() has some bugs which have been
worked around in Subversion.
Please see svn_io_file_trunc() in subversion/libsvn_subr/io.c :
http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_subr/io.c?view=markup=1759116#l4065
r1240752 added a
Ivan Zhakov wrote:
> On 10 December 2015 at 19:14, Julian Foad <julianf...@apache.org> wrote:
>> APR devs, Subversion devs:
>>
>> On Subversion's Mac OS buildbots it appears that apr_hash_overlay()
>> sometimes returns a hash containing duplicate keys, whi
APR devs, Subversion devs:
On Subversion's Mac OS buildbots it appears that apr_hash_overlay()
sometimes returns a hash containing duplicate keys, which (as I
understand it) should be impossible.
We had an issue where some 'svnmover' tests were failing only on Mac
OS buildbots. I added some
Dear APR devs,
Following the relatively recent addition to APR trunk [1,2,3] of these
functions:
const char * apr_hash_this_key(apr_hash_index_t *);
apr_ssize_t apr_hash_this_key_len(apr_hash_index_t *);
void * apr_hash_this_val(apr_hash_index_t *);
I offer the attached patch as a
Dear APR devs,
Please can we merge the these functions from trunk [1,2] to the next version to
be released, which I assume would mean the 1.5 branch, before it's released, as
originally discussed at [3]?
const char * apr_hash_this_key(apr_hash_index_t *);
apr_ssize_t
The attached patch adds three functions for dereferencing an APR hash
index (iterator). The usage of apr_hash_this() can look something like:
for (hi = apr_hash_first(pool, entries); hi; hi = apr_hash_next(hi))
{
const char *name;
svn_wc_entry_t *wc_entry;
const void *key;
D.J. Heap wrote:
With the new Apache 2.2 and APR 1.2, apr_stat and apr_dir_read now
return APR_INCOMPLETE which Subversion doesn't handle very well. At
least, they return it much more often that previous releases did.
(It doesn't really matter but in what way does APR return this much more
André Malo wrote:
[EMAIL PROTECTED] wrote:
Hmm. My thought is that the prefix svn commit is redundant and should
be dropped. A subject starting with r126493 -
I find the prefix is especially useful, when someone replies to such
mails to another mailinglist (like this thread).
Ah, but do you
On APR's home page (http://apr.apache.org/), the links under Docs lead
straight to Doxygen, the first page of which appears blank until you notice the
menu bar at the top - not very friendly. And what about other kinds of
documentation such as Using APR Pools (which is actually linked from the
APR's 'configure.in' was changed in r6 to preserve the time stamp of apr.h
if its content was unchanged, to try to avoid re-builds. This was done by
renaming the file to *.save and then allowing it to be recreated and then
moving the saved version back if they are identical:
/**
* Get the number of key/value pairs in the hash table.
* @param ht The hash table
* @return The number of key/value pairs in the hash table.
*/
APR_DECLARE(unsigned int) apr_hash_count(apr_hash_t *ht);
Any reason not to take a pointer to a const apr_hash_t?
If we can't fix this right away
Joe Orton wrote:
On Mon, Jan 17, 2005 at 11:40:33AM +, Julian Foad wrote:
APR_DECLARE(unsigned int) apr_hash_count(apr_hash_t *ht);
Any reason not to take a pointer to a const apr_hash_t?
If we can't fix this right away due to the possibility of binary
incompatibility on some systems, where
William A. Rowe, Jr. wrote:
Can I have a second set of eyes for a reality check before
I backport this compile-time cleanup?
It looks fine to me, if you think it is appropriate to back-port such a
clean-up.
The log message is rather difficult to understand.
- Julian
[...]
Log:
Clean up 4
Mihai Limbasan wrote:
Attached is a minor patch fixing some error strings in
misc/unix/errorcodes.c (missing periods, inconsistent language usage).
Most of the strings did NOT end in a period. It would be more consistent to
remove periods from those that do. The Subversion project extends the
André Malo wrote:
* Julian Foad wrote:
Can you fix the web page?
Done.
Thanks.
- Julian
André Malo wrote:
* Ingo Weinhold [EMAIL PROTECTED] wrote:
I unsuccessfully tried to subscribe to the SVN list. The APR site
(http://apr.apache.org/mailing-lists.html) gives
`mailto:[EMAIL PROTECTED]' as the subsciption address, but the
server replies with:
It's [EMAIL PROTECTED], this was
William A. Rowe, Jr. wrote:
This simply isn't a good idea until 2.0.
Does the project have a standard place to record proposed API changes for the
next major version so that they are not forgotten when that time comes? If
not, may I suggest putting this in the STATUS file under a heading like
Brad Nicholes wrote:
You are right, it is dead code for now. The reason why it is there
is because this file is just a stub rip-off of the Unix implementation.
It is just waiting for the day when the NetWare OS supports UID/GID for
running applications and services. On the NetWare OS
Joe Orton wrote:
On Mon, Nov 22, 2004 at 08:14:26PM -, Paul Querna wrote:
+memcpy( (void*)uuid_data, (const void *)g, sizeof( uuid_t ) );
Please watch the code style, Paul!
Not sure exactly what Joe is referring to, but note that it should never be
necessary to cast anything to const void
Joe Orton wrote:
The fact that -Wundef exposed bugs like apr_signal_block() being a noop
seems like sufficient justification to make the source -Wundef clean to
avoid future screwups, I agree with this. But any chance you could fix
them all rather than picking them off one at at time?
Joe Orton wrote:
Thanks Julian, all of these have been committed to the trunk other than
the acconfig.h change, per my other mail - let me know if I missed
anything else.
Thanks very much Joe. You missed nothing.
- Julian
Brane, you have caught me in zero-tolerance week. Please bear with me while I
rant again. :-)
Branko ibej wrote:
Julian Foad wrote:
This patch only fixes one instance, but one which is in a header file
and so is encountered frequently. There are other BEOS-related
symbols being tested badly
OK, this is a bit embarrassing: I have only just realised that APR comes with a
set of regression tests. What's worse, it seems that at least one of my recent
mini patches breaks a test or two. I'll post again when I know exactly what
breaks what.
- Julian
APR's make check fails as follows, whether I apply my patches or not.
[lots of OK tests, and then...]
Trying global mutexes with mechanism `proc_pthread'...
no problems encountered...
testatomic : SUCCESS
testdir : SUCCESS
testdso : SUCCESS
testdup
Branko ibej wrote:
If the #if was an exception WRT the BEOS symbol, then
your change is fine; but you should say so (perhaps you did in another
post and I missed it; sorry).
I did say so when I first posted the patch a few days ago, but I should say so
in the log message. The patch is
This patch contains all of the changes I have posted so far in this thread, and
more, now as a Subversion diff, with log messages.
The one bug fixed here is that the functions apr_signal_block and
apr_signal_unblock were not being implemented because they were testing for
APR_HAS_SIGACTION
This patch only fixes one instance, but one which is in a header file and so is
encountered frequently. There are other BEOS-related symbols being tested
badly in C files which I am not fixing here. I found these with gcc -Wundef.
- Julian
Test whether BEOS is defined, not whether it is
[EMAIL PROTECTED] wrote:
I think it would be mildly better for them to be four separate commits.
Quite right. Seprate submissions coming up.
- Julian
See subject line and log message withiin patch.
- Julian
Avoid casting away const. No functional change.
* apr/file_io/unix/tempdir.c
(test_tempdir): Remove const to avoid casting it away.
Index: apr/file_io/unix/tempdir.c
===
See subject line and log message within patch.
- Julian
Remove a spurious carriage return from the middle of a line.
No functional change.
* apr/network_io/unix/sendrecv.c
(apr_socket_sendfile): Remove a spurious carriage return.
Index: apr/network_io/unix/sendrecv.c
Wrong symbol being tested presumably caused these never to be compiled?
- Julian
Fix enabling of signal blocking and unblocking code.
* apr/threadproc/unix/signals.c
(apr_signal_block, apr_signal_unblock): Test the correct symbol, so that
these functions will actually be implemented on
See subject line and log message within patch.
- Julian
Remove unnecessary type casts that were casting away const.
No functional change.
* apr-util/crypto/apr_md5.c
(apr_md5_encode): Remove some type casts.
Index: apr-util/crypto/apr_md5.c
See subject line and log message within patch. Found with gcc -Wundef.
- Julian
Avoid testing undefined symbols. No functional change.
* apr-util/misc/apr_queue.c
Include the header that defines the symbols we are testing.
Index: apr-util/misc/apr_queue.c
Cliff Woolley wrote:
We've taken the plunge. The APR CVS repositories are now converted and closed.
Woo-hoo! Most excellent.
- Julian
[EMAIL PROTECTED] wrote:
[...]
|11122|Opn| |2002-07-24|unresolved reference to db_create and db_strerror |
|13037|New| |2002-09-26|Alloca configure test fails |
|14589|New| |2002-11-15|apr_ipsubnet_create causes unaligned access erro|
[...]
What's going on? Is somebody
Julian Foad wrote:
Prevent unbounded memory use during repeated operations on a hash table.
Sander Striker wrote:
+1.
Branko ibej wrote:
This looks good. I vote we apply it on both HEAD and the 0.9.x branch.
Can I do anything further to get this applied?
- Julian
I get this warning frequently when building Subversion against APR. This patch
appears to be the correct fix (rather than ensuring that BEOS is always
defined) because the symbol is always tested in this way elsewhere in APR.
I have just subscribed to this mailing list. Please let me know if
Julian Foad wrote:
I get this warning frequently when building Subversion against APR.
To be accurate, I meant when building APR, which I do as part of a Subversion
build.
- Julian
I also get the following warnings from similar inconsistencies in other APR
files:
apr/file_io/unix/pipe.c:27:5: warning: BEOS is not defined
apr/file_io/unix/pipe.c:37:6: warning: BEOS_BLOCKING is not defined
apr/file_io/unix/pipe.c:73:6: warning: BEOS_BLOCKING is not defined
Is there an archive for this mailing list?
- Julian
Judging by usage elsewhere in the same and other files, the wrong symbol was
being tested.
Index: threadproc/unix/signals.c
===
RCS file: /home/cvspublic/apr/threadproc/unix/signals.c,v
retrieving revision 1.59
diff -u -3 -p -d
Julian Foad wrote:
apr-util/misc/apr_queue.c:15:5: warning: APR_HAVE_STDIO_H is not defined
apr-util/misc/apr_queue.c:18:5: warning: APR_HAVE_STDLIB_H is not defined
apr-util/misc/apr_queue.c:21:5: warning: APR_HAVE_UNISTD_H is not defined
Judgind by another file in the same directory, this needs
Branko ibej wrote:
Julian Foad wrote:
Prevent unbounded memory use during repeated operations on a hash table.
[...]
This looks good. I vote we apply it on both HEAD and the 0.9.x branch.
Thanks. I have now checked that it passes Subversion's make check, and, in a
debugger, that the new code
The Subversion project encountered a usage pattern of APR hash tables that
caused many megabytes of memory to be occupied by a small hash table after a
sequence of many thousands of (insert, delete) pairs. They have subsequently
changed the usage pattern to avoid this.
The cause of the
In apr/Makefile.in and apr-util/Makefile.in, the three files
exports.c
export_vars.h
apr[util].exp
are not specified as being in a particular directory (${srcdir} or whatever),
and so the build does not work properly outside the source tree:
~/build/subversion/apr-util make
[...]
make[1]:
49 matches
Mail list logo
