On 12.02.2015 22:21, kay wrote:
> Brane,
>
> Thanks for your kind support. I really appreciate it. The systems does not
> have internet service so I am not sure if that get-deps.sh script will work.
> Please advise.
Just use the SQLite amalgamation version that the script would download
if you ha
On 13.02.2015 01:30, Bert Huijben wrote:
>
>> -Original Message-
>> From: br...@apache.org [mailto:br...@apache.org]
>> Sent: donderdag 12 februari 2015 21:55
>> To: comm...@subversion.apache.org
>> Subject: svn commit: r1659397 - in /subversion/trunk: TODO build/ac-
>> macros/swig.m4
>>
>>
Planning to roll these sometime late next week. So please wrap up any
nomination/voting for things that you'd like included.
> -Original Message-
> From: br...@apache.org [mailto:br...@apache.org]
> Sent: donderdag 12 februari 2015 21:55
> To: comm...@subversion.apache.org
> Subject: svn commit: r1659397 - in /subversion/trunk: TODO build/ac-
> macros/swig.m4
>
> Author: brane
> Date: Thu Feb 12 20:55:13 2015
Brane,
Thanks for your kind support. I really appreciate it. The systems does not
have internet service so I am not sure if that get-deps.sh script will work.
Please advise.
--
View this message in context:
http://subversion.1072662.n5.nabble.com/Configuring-Subversion-with-Berkeley-DB-Error-
On 12.02.2015 21:55, br...@apache.org wrote:
> Author: brane
> Date: Thu Feb 12 20:55:13 2015
> New Revision: 1659397
>
> URL: http://svn.apache.org/r1659397
> Log:
> Do not attempt to build bindings with Swig 3.0+. Current versions
> break the Python bindings.
Heads up for the above; should be in
On 12.02.2015 21:12, kay wrote:
> I have just done what you suggested as in unzipping the SQLite-amalgamation
> zip file in the source directory of the subversion and rename the directory
> the SQLite-amalgamation. I am now getting below error:
>
> /bin/bash /dhhs1t/3rdparty/tools/svn/subversion-1.
I have just done what you suggested as in unzipping the SQLite-amalgamation
zip file in the source directory of the subversion and rename the directory
the SQLite-amalgamation. I am now getting below error:
e-keyring-1 -I/usr/local/include/serf-1
-I/dhhs1t/3rdparty/tools/svn/subversion-1.8.1
On 12.02.2015 20:48, kay wrote:
> I downloaded sqlite-amalgamation-3080802.zip and unzipped into a totally
> different directory. I make a directory named SQLite amalgamation as
> follows: /stptest/tools/svn/subversion-1.8.11/sqlite-amalgamation dand
> copied the sqlite3.c from the unzipped files t
I downloaded sqlite-amalgamation-3080802.zip and unzipped into a totally
different directory. I make a directory named SQLite amalgamation as
follows: /stptest/tools/svn/subversion-1.8.11/sqlite-amalgamation dand
copied the sqlite3.c from the unzipped files to it
--
View this message in context:
On 12.02.2015 20:17, kay wrote:
> particular
> Just an update:
> I was able to move past the issue (SVN_PATH_LOCAL_SEPERATOR). It is somewhat
> related to the following error that I got as the last line of my ./configure
> output:
>
> "sed: command garbled: s/@SVN_DB_HEADER@/#include
> /"
>
> I i
Hi kay,
On Thu, Feb 12, 2015 at 5:48 PM, kay wrote:
> Just to clarify the "support security" was a typo. I meant they thought BDB
> will have better features for user authentication, privacy, permission and
> security issues.
Well, then I think your customer, or you, don't get Branko's "There'
particular
Just an update:
I was able to move past the issue (SVN_PATH_LOCAL_SEPERATOR). It is somewhat
related to the following error that I got as the last line of my ./configure
output:
"sed: command garbled: s/@SVN_DB_HEADER@/#include
/"
I ignored the error previously, thinking ./configure
Ivan Zhakov writes:
> As far I understand out testsuite still may fail in some rare
> circumstances with --parallel option, until we add
> svn_dso_initialize2(). It's bad when tests are failing sometimes.
I just seen a failure and it revealed the current bug. I think the
tests explicitly clear
On 12 February 2015 at 20:51, Philip Martin wrote:
> Ivan Zhakov writes:
>
>> Sorry, but I've lost what problem we're trying to solve now? Why just
>> do not add call to svn_dso_initialize2() (or svn_cmdline_init()) in
>> our testsuite and move forward?
>
> What do we gain? We already have progr
Ivan Zhakov writes:
> Sorry, but I've lost what problem we're trying to solve now? Why just
> do not add call to svn_dso_initialize2() (or svn_cmdline_init()) in
> our testsuite and move forward?
What do we gain? We already have programs that that call
svn_dso_initialize2: svn, svnserve, ... I
On 12.02.2015 17:41, kay wrote:
> Brane,
> Which include are you referring to here. Below is what I used for the
> ./configure step:
>
> ./configure --prefix=/dhhs1t/3rdparty/tools/svn --with-apr=/usr/local/apr/
> --with-apr-util=/usr/local/apr/
> --with-berkeley-db=/usr/local/BerkeleyDB.5.3/inclu
On 12 February 2015 at 20:27, Philip Martin wrote:
> Ivan Zhakov writes:
>
>> Please understand my correctly: I'll be glad see Subversion doesn't
>> require single-thread initialize functions, but I don't see how is it
>> possible in reliable way. Currently the only reliable solution is to
>> cal
I noticed the below at the end of the ./configure step. I have been ignoring
it as not an issue. Just wanted to be sure that is really not an issue:
sed: command garbled: s/@SVN_DB_HEADER@/#include
/
--
View this message in context:
http://subversion.1072662.n5.nabble.com/Configuring-Subversio
> -Original Message-
> From: Ivan Zhakov [mailto:i...@visualsvn.com]
> Sent: donderdag 12 februari 2015 16:59
> To: Subversion Development
> Cc: Philip Martin
> Subject: Re: svn commit: r1659013 -
> /subversion/trunk/subversion/libsvn_subr/dso.c
>
> On 11 February 2015 at 20:48, wrote:
Ivan Zhakov writes:
> Please understand my correctly: I'll be glad see Subversion doesn't
> require single-thread initialize functions, but I don't see how is it
> possible in reliable way. Currently the only reliable solution is to
> call svn_dso_initialize2() as first call after apr_initialize(
On 12 February 2015 at 19:05, Branko Čibej wrote:
> On 12.02.2015 16:50, i...@apache.org wrote:
>> Author: ivan
>> Date: Thu Feb 12 15:50:47 2015
>> New Revision: 1659291
>>
>> URL: http://svn.apache.org/r1659291
>> Log:
>> On the remove-log-addressing branch: Merge changes from trunk.
>
> What is
Ivan Zhakov writes:
> Why you didn't make svn_atomic__init_once() internal implementation
> details of svn_dso_initialize2()?
That would be better, so r1659315.
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Just to clarify the "support security" was a typo. I meant they thought BDB
will have better features for user authentication, privacy, permission and
security issues. I brought up the issue of deprecation and lack of future
support for BDB.
--
View this message in context:
http://subversion
Brane,
Which include are you referring to here. Below is what I used for the
./configure step:
./configure --prefix=/dhhs1t/3rdparty/tools/svn --with-apr=/usr/local/apr/
--with-apr-util=/usr/local/apr/
--with-berkeley-db=/usr/local/BerkeleyDB.5.3/include/db.h:/usr/local/BerkeleyDB.5.3/include:/us
On 12.02.2015 16:58, Ivan Zhakov wrote:
> On 11 February 2015 at 20:48, wrote:
>> Author: philip
>> Date: Wed Feb 11 17:48:06 2015
>> New Revision: 1659013
>>
>> URL: http://svn.apache.org/r1659013
>> Log:
>> Wrap svn_dso_initialize2 call with svn_atomic__init_once, this
>> fixes a crash in the D
On 12.02.2015 16:50, i...@apache.org wrote:
> Author: ivan
> Date: Thu Feb 12 15:50:47 2015
> New Revision: 1659291
>
> URL: http://svn.apache.org/r1659291
> Log:
> On the remove-log-addressing branch: Merge changes from trunk.
What is the remaining purpose of this branch? I thought we'd agreed to
I've been looking at the ctypes-based Python bindings. They're barely
maintained; the only changes in the last two years seem to have been
minor tweaks to make the tests run. I'm also not aware of anyone using
them, or any packager bundling them.
This was an interesting experiment, but I think it'
On 11 February 2015 at 20:48, wrote:
> Author: philip
> Date: Wed Feb 11 17:48:06 2015
> New Revision: 1659013
>
> URL: http://svn.apache.org/r1659013
> Log:
> Wrap svn_dso_initialize2 call with svn_atomic__init_once, this
> fixes a crash in the DSO hash code when running the C tests in
> paralle
On 12 February 2015 at 16:48, Branko Čibej wrote:
> On 12.02.2015 14:17, Philip Martin wrote:
>> Ivan Zhakov writes:
>>
>>> Multi-threaded application that didn't call svn_dso_initialize2()
>>> before creating any other pools will fail anyway under some
>>> circumstances. The problem with cleanup
> I think info->path is already in the correct pool, it's the result of
> processing the the input path through svn_fspath__canonicalize using
> result_pool.
Yes, INFO->PATH is alocated in correct pool already. I've attached a new
version of my patch (log message remains the same).
Index: subvers
On 12.02.2015 14:12, rhuij...@apache.org wrote:
> Author: rhuijben
> Date: Thu Feb 12 13:12:40 2015
> New Revision: 1659244
> @@ -506,6 +508,19 @@ print_info(void *baton,
>APR_ARRAY_IDX(info->wc_info->conflicts, 0,
> const svn_wc_conflict_descrip
On 12.02.2015 14:17, Philip Martin wrote:
> Ivan Zhakov writes:
>
>> Multi-threaded application that didn't call svn_dso_initialize2()
>> before creating any other pools will fail anyway under some
>> circumstances. The problem with cleanup handles, not with concurrent
>> initialization.
> Perhaps
Sergey Raevskiy writes:
> Index: subversion/libsvn_fs_fs/lock.c
> ===
> --- subversion/libsvn_fs_fs/lock.c(revision 1659239)
> +++ subversion/libsvn_fs_fs/lock.c(working copy)
> @@ -900,14 +900,15 @@ lock_body(void *baton, ap
Hi!
I've noticed an improper pool usage in FSFS code. The svn_lock_t * object is
created in RESULT_POOL, but its fiels are not gettting pstrdup'ed.
The patch with fix is attached.
Log message:
[[[
* subversion/libsvn_fs_fs/lock.c
(lock_body): Fix pool usage. Call apr_pstrdup() when initializi
Ivan Zhakov writes:
> Multi-threaded application that didn't call svn_dso_initialize2()
> before creating any other pools will fail anyway under some
> circumstances. The problem with cleanup handles, not with concurrent
> initialization.
Perhaps we could fix the problem (for recent APR) by usin
Branko Čibej writes:
> On 12.02.2015 13:26, Evgeny Kotkov wrote:
>> Philip Martin writes:
>>
>>> Wrap svn_dso_initialize2 call with svn_atomic__init_once, this
>>> fixes a crash in the DSO hash code when running the C tests in
>>> parallel.
>>>
>>> * subversion/libsvn_subr/dso.c
>>> (atomic_in
On 12 February 2015 at 15:42, Branko Čibej wrote:
> On 12.02.2015 13:26, Evgeny Kotkov wrote:
>> Philip Martin writes:
>>
>>> Wrap svn_dso_initialize2 call with svn_atomic__init_once, this
>>> fixes a crash in the DSO hash code when running the C tests in
>>> parallel.
>>>
>>> * subversion/libsvn
On 12.02.2015 13:26, Evgeny Kotkov wrote:
> Philip Martin writes:
>
>> Wrap svn_dso_initialize2 call with svn_atomic__init_once, this
>> fixes a crash in the DSO hash code when running the C tests in
>> parallel.
>>
>> * subversion/libsvn_subr/dso.c
>> (atomic_init_func): New.
>> (svn_dso_load
Philip Martin writes:
> Wrap svn_dso_initialize2 call with svn_atomic__init_once, this
> fixes a crash in the DSO hash code when running the C tests in
> parallel.
>
> * subversion/libsvn_subr/dso.c
> (atomic_init_func): New.
> (svn_dso_load): Use svn_atomic__init_once.
I think we should als
On 11.02.2015 18:50, kay wrote:
> Brane, To answer your question about why I am installing svn with BerkelyDB,
> the client wants the BDB as their backend. In the past, they had svn
> installed with fsfs and support user authentication, permissions and
> security.
Please tell your customer that t
On 12.02.2015 12:12, kay wrote:
> These are the three config's files that I found.
>
> -rw-r--r-- 1 sptest1 sptest17856 Feb 11 11:40 svn_private_config.h
> -rw-r--r-- 1 sptest1 sptest17263 Dec 8 19:26 svn_private_config.h.in
> -rw-r--r-- 1 sptest1 sptest1 3195 Nov 23 2012 svn_pr
These are the three config's files that I found.
-rw-r--r-- 1 sptest1 sptest17856 Feb 11 11:40 svn_private_config.h
-rw-r--r-- 1 sptest1 sptest17263 Dec 8 19:26 svn_private_config.h.in
-rw-r--r-- 1 sptest1 sptest1 3195 Nov 23 2012 svn_private_config.hw
--
View this message
Sergey Raevskiy writes:
> Yes, the behaviour is *not* exactly the same -- the index files is updated in
> different order. Furthermore, I've realized that current version of algorithm
> will set some locks even if update of some index files is failed.
I think that is OK. What matters is that t
Sergey Raevskiy writes:
> Follow-up to r1658482: Refactor walk_locks() function: remove the redundant
> complexity of walk_digest_files() / walk_digests_callback_t.
Committed in r1659217. Thanks!
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
On 16.01.2015 11:06, Branko Čibej wrote:
> A couple months down the line, and I'd like to make another call for
> creating the 1.9 release branch. AFAICS the x509 branch still needs
> merging if we want it in 1.9 (which I think we do, since IIUC trunk
> currently does not handle all certs correctly
On Wed, Feb 11, 2015 at 11:01 PM, Branko Čibej wrote:
> On 11.02.2015 20:07, Branko Čibej wrote:
> > On 11.02.2015 20:03, Philip Martin wrote:
> >> Branko Čibej writes:
> >>
> >>> I'm seeing this in the logs on the svn-x64-macosx-bdb builder on trunk:
> >>>
> >>> $ cat fails.log
> >>> [[[
> >>>
47 matches
Mail list logo
