On 11/10/14 4:28 AM, br...@apache.org wrote:
ltpath=`dirname $libtoolize`
-ltfile=${LIBTOOL_M4-`cd $ltpath/../share/aclocal ; pwd`/libtool.m4}
+ltfile=${LIBTOOL_M4-`cd $ltpath/../share/aclocal ; pwd`}/libtool.m4
if [ ! -f $ltfile ]; then
echo $ltfile not found (try setting the
This is downright horrible for code maintainability. We have a type for
revision numbers.
It's bad enough we don't have a stable type for revision numbers across
platforms. But now you're abusing it and using 32-bit integers in some places
for them and 64-bit values in others.
Now that you're
On 3/7/14, 3:11 PM, Stefan Fuhrmann wrote:
Two comments:
* The keys are being used one-way, i.e. any type input type will do
*nod* I realize it's safe. But the problem is that we know we have a type that
isn't stable for revnum's across platforms. Say we do Subversion 2.0 and we
want to
On 12/2/13, 6:46 AM, stef...@apache.org wrote:
Author: stefan2
Date: Mon Dec 2 14:46:11 2013
New Revision: 1547035
URL: http://svn.apache.org/r1547035
Log:
* subversion/tests/svn_test_main.c
(main): Allow for testing compatibility with 1.7 and 1.8.
Modified:
On 1/20/14, 1:05 PM, Ben Reser wrote:
On 12/2/13, 6:46 AM, stef...@apache.org wrote:
Author: stefan2
Date: Mon Dec 2 14:46:11 2013
New Revision: 1547035
URL: http://svn.apache.org/r1547035
Log:
* subversion/tests/svn_test_main.c
(main): Allow for testing compatibility with 1.7 and 1.8
On 1/20/14, 3:27 PM, Bert Huijben wrote:
I don't think locks.c was removed with this commit. Only some code was removed
from it.
$ svn-trunk log -c 1551910 -v -q
r1551910 | rhuijben | 2013-12-18 03:07:32 -0800 (Wed, 18 Dec
On 11/21/13, 9:42 AM, br...@apache.org wrote:
Author: brane
Date: Thu Nov 21 17:42:41 2013
New Revision: 1544259
URL: http://svn.apache.org/r1544259
Log:
Return the correct error from mod_dav_svn if the repository path does not
exist.
* subversion/mod_dav_svn/repos.c (get_resource):
On Thu, Jul 25, 2013 at 11:42 PM, Roderich Schupp
roderich.sch...@gmail.com wrote:
Thanks for catching this, but with Ben's r1507155 (Fix possible duplication
of work when using svn_hash_sets() macro)
there's no change required here, right?
Right, this is a bigger problem than just your
On Fri, Jul 26, 2013 at 12:22 AM, Ben Reser b...@reser.org wrote:
I haven't nominated it for backport yet because I wanted to figure out
what to do about svn_hash_gets(). But I ended up realizing that there
isn't a good solution there.
Just realized there's no reason to backport this. 1.8.x
On Thu, Jul 25, 2013 at 1:39 PM, Bert Huijben b...@qqmail.nl wrote:
This patch will allocate the string twice, because hash puts evaluates
its argument twice.
This should use a tempvar or the Apr hash function directly
Well looks like we've got quite a bit of cleanup to do then...
On Thu, Jul 25, 2013 at 2:37 PM, Ben Reser b...@reser.org wrote:
Well looks like we've got quite a bit of cleanup to do then...
[breser@fmri subversion]$ ack 'svn_hash_sets.*apr_' --noheading --nobreak
svn/notify.c:95: svn_hash_sets(hash,
apr_pstrdup(nb-conflict_stats-stats_pool, path
On Thu, Jul 25, 2013 at 3:37 PM, Bert Huijben b...@qqmail.nl wrote:
If svn_hash_sets doesn't have a return value we could redefine it with
a temporary variable (and catch some type warnings too)
Yup, apr_hash_set() has a void return. So we could still fix this
with the macro.
Does this look
On Thu, Jul 25, 2013 at 3:45 PM, Ben Reser b...@reser.org wrote:
On Thu, Jul 25, 2013 at 3:37 PM, Bert Huijben b...@qqmail.nl wrote:
If svn_hash_sets doesn't have a return value we could redefine it with
a temporary variable (and catch some type warnings too)
Yup, apr_hash_set() has a void
On Thu, Jul 25, 2013 at 4:39 PM, Ben Reser b...@reser.org wrote:
svn_hash_gets() has a similar issue but can't be fixed with a macro
since it has a return value.
There are far fewer cases where svn_hash_gets() results in extra work.
At first I thought it might not be worth fixing it since you
On Thu, Jul 25, 2013 at 5:26 PM, Ben Reser b...@reser.org wrote:
There are far fewer cases where svn_hash_gets() results in extra work.
At first I thought it might not be worth fixing it since you have to
turn it into a function. But then I ran into the cases in libsvn_wc
and libsvn_delta
On Thu, Jul 11, 2013 at 6:42 PM, Greg Stein gst...@gmail.com wrote:
Ugh. Why the rename? I spent a bunch of effort bringing the name in
line with dev@ thinking. This option primarily controls if/when we
detect for chunked request capability on the connection.
I appreciate your effort and I
On Fri, Jul 12, 2013 at 12:59 PM, Greg Stein gst...@gmail.com wrote:
On Fri, Jul 12, 2013 at 2:53 AM, bre...@apache.org wrote:
...
+++
subversion/branches/1.8.x-tristate-chunked-request/subversion/libsvn_ra_serf/serf.c
Fri Jul 12 06:53:40 2013
...
@@ -293,12 +293,11 @@
On Fri, Jul 12, 2013 at 12:59 PM, Greg Stein gst...@gmail.com wrote:
On Fri, Jul 12, 2013 at 2:53 AM, bre...@apache.org wrote:
...
+++
subversion/branches/1.8.x-tristate-chunked-request/subversion/libsvn_ra_serf/serf.c
Fri Jul 12 06:53:40 2013
...
@@ -293,12 +293,11 @@
Kinda wish we hadn't merged this into 1.8.x. Unless we revert this
means there will be changes to the 1.8.0 tarball from rc3. I'm fine
with that, but I'm not sure I would have done it for just this change
since it increases the testing that has to be done (at least one
Windows) for the final
On Wed, Jun 12, 2013 at 3:26 PM, Branko Čibej br...@wandisco.com wrote:
Messing with a release candidate for the sake of a couple minor test
suite tweaks is not my idea of sane release management.
In other words, -1 to putting this in 1.8.0. Instead, I propose we
revert that change and
On Wed, Jun 12, 2013 at 3:35 PM, Daniel Shahaf danie...@elego.de wrote:
Note that if you revert it, the mergebot will just merge it _again_ the
following night (your time), unless you also move the entry out of the
(second) Approved section.
Thanks for the reminder.
On Mon, Jun 10, 2013 at 9:35 AM, Daniel Shahaf d...@daniel.shahaf.name wrote:
Perhaps leave it in? It's little overhead to maintain and might make
somebody's life easier.
If you want to put it in that's fine. But at this point I don't think
it'll be in 1.8.0 since I merged the change removing
On Fri, Jun 7, 2013 at 4:52 PM, Ben Reser b...@reser.org wrote:
I really don't understand why this change is necessary at all since as
you can see above the source tree is added to the load path with -I.
So I think I understand the logic here. Windows doesn't seem to have
any wrapper
This change breaks the Ruby test suite with out of tree builds:
[[[
[breser@kong svn-trunk]$ make check-swig-rb
if [ DYLD_LIBRARY_PATH = DYLD_LIBRARY_PATH ]; then for d in
/Users/breser/wandisco/builds/svn-trunk/subversion/bindings/swig/python/libsvn_swig_rb
I tend to think the absolute URL syntax is better for our
documentation since the only way the relative URL works is if you run
it while your CWD is in a working copy in that repo.
On Fri, Apr 12, 2013 at 6:32 AM, danie...@apache.org wrote:
Author: danielsh
Date: Fri Apr 12 13:32:31 2013
New
On Sat, Apr 6, 2013 at 3:55 AM, Branko Čibej br...@wandisco.com wrote:
In many ways your change is better than mine. So if you don't mind, I'll
merge the two (and adjust the test infrastructure accordingly).
Go for it.
On Fri, Apr 5, 2013 at 7:11 AM, br...@apache.org wrote:
Author: brane
Date: Fri Apr 5 14:11:49 2013
New Revision: 1464985
URL: http://svn.apache.org/r1464985
Log:
Make svnadmin create --fs-type=bdb warn about the BDB back-end deprecation.
* subversion/svnadmin/svnadmin.c
On Thu, Mar 28, 2013 at 1:11 PM, Daniel Shahaf d...@daniel.shahaf.name wrote:
This is normally done on trunk then merged to the branch...
Whoops, forgot what branch I was on. Fixed in r1462293 and r1462294.
On Tue, Jan 29, 2013 at 10:40 AM, Bert Huijben b...@qqmail.nl wrote:
I think there might be third party implementations (CollabNet, WANdisco,
VisualSvn) that might rely on these values?
So maybe somebody wants to respond?
Personally I would prefer to see an error somewhere in SVN_ERR_AUTHZ
On Sat, Jan 5, 2013 at 12:36 AM, bre...@apache.org wrote:
Author: breser
Date: Sat Jan 5 08:36:14 2013
New Revision: 1429235
URL: http://svn.apache.org/viewvc?rev=1429235view=rev
Log:
Add validate-files.py, a python pre-commit hook-script that runs commands and
rejects commits if the
On Sat, Jan 5, 2013 at 11:17 AM, Daniel Shahaf d...@daniel.shahaf.name wrote:
This quoting is insufficient, it's still prone to SQL injections. Since
this is a problem every user of this script would have to solve, how
about having the script ensure that $FILE doesn't contain '?
Perhaps make
On Sat, Jan 5, 2013 at 1:00 AM, Ben Reser bre...@apache.org wrote:
Before someone else points it out there are further Python 3
incompatibilities in the script. I'll clean these up soon.
Fixed in r1429453. I've tested succesfully with Python 2.7.1 and 3.3.0.
On Thu, Jan 3, 2013 at 12:17 PM, Daniel Shahaf danie...@elego.de wrote:
What's the benefit of this? Destroying the pool at process exit ---
it's not to reclaim memory. Is it to ensure some pool cleanup callback
fires?
It's mostly just a correctness thing. I noticed it when I noticed
that
On Thu, Jan 3, 2013 at 2:46 PM, Daniel Shahaf danie...@elego.de wrote:
Use a relative target for the symlink?
For svnmucc I couldn't do this because bindir != toolsdir, but that
consideration doesn't kick in for svnauthz.
Done in r1428712.
On Sat, Dec 22, 2012 at 3:38 PM, rhuij...@apache.org wrote:
Author: rhuijben
Date: Sat Dec 22 23:38:08 2012
New Revision: 1425371
URL: http://svn.apache.org/viewvc?rev=1425371view=rev
Log:
* STATUS: Update r1425368 justification
Modified:
subversion/branches/1.7.x/STATUS
Modified:
On Fri, Dec 14, 2012 at 1:39 PM, Daniel Shahaf danie...@elego.de wrote:
-maxdepth please? So it doesn't recurse into svn-test-work.
It might be better to be explicit:
$ABS_BUILDDIR/subversion/*/.libs/
Yeah my find was overzealous.
Committed your last suggestion in r1422141
On Wed, Nov 21, 2012 at 2:07 AM, Daniel Shahaf d...@daniel.shahaf.name wrote:
Not destroying iterpool would cause rep_write_cleanup() (pool cleanup
handler) not to fire [according to breser], hence not call
unlock_proto_rev(), hence not clear the being_written flag in the txn
object. That
He did indeed move it the wrong way and fixed it in r1403983.
On Wed, Oct 31, 2012 at 2:33 AM, Bert Huijben b...@qqmail.nl wrote:
-Original Message-
From: danie...@apache.org [mailto:danie...@apache.org]
Sent: woensdag 31 oktober 2012 05:50
To: commits@subversion.apache.org
38 matches
Mail list logo
