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 'buil
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:
>> [[[
>> # Re
(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 versio
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&pathrev=1759116#l4065
r1240752 added a wor
Ivan Zhakov wrote:
> On 10 December 2015 at 19:14, Julian Foad wrote:
>> 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)
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 debug
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 apr_hash_this_key_len(
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
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
o
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 yo
Reid Spencer wrote:
This is a bit of a silly request, but could we get the APR commits list
to use the prefix "apr commits" instead of "svn commits" in the subject
line? I'm on the mailing list for both Subversion and APR and I get
confused every time APR sends me an "svn commit" because I think it
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
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:
-AC_OUTPUT($MAKE
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
/**
* 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
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 se
Colm MacCarthaigh wrote:
Patch also contains some whitespace/style cleanups my editor applied
(uggh) [...]
When you do a significant amount of whitespace cleanup, like in this patch, it
is better to send the cleanup and the functional change as two separate
patches. (e.g. Load the original file,
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 extraniou
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 cha
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 "F
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 applicat
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 voi
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
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?
file_io/unix
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 re-attac
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
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
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
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
===
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
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 appro
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
===
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
===
[EMAIL PROTECTED] wrote:
I think it would be mildly better for them to be four separate commits.
Quite right. Seprate submissions coming up.
- Julian
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 no
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 inst
[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 somebod
Cliff Woolley wrote:
We've taken the plunge. The APR CVS repositories are now converted and closed.
Woo-hoo! Most excellent.
- Julian
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 fi
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 -r1.5
Is there an archive for this mailing list?
- 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
apr/file_io/un
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 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 t
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
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, th
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 problem
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]: Enterin
51 matches
Mail list logo