Hello guys;
Sorry to contact you about something somewhat off-topic but perhaps
someone here can give me details (in private is OK) on how the Coverity
scans are generated?
On another Apache project we want to use coverity but infra@ is not
aware about anything on their side that is required to
On 05/24/2012 01:32 AM, Greg Stein wrote:
Hey all,
I moderated this through, in order to start a discussion.
My feeling is: this is not how we want to accept patches. This
approach is completely disconnected from our community. How do we talk
to the person providing the change? How do we ask fo
Object hold their baton. Editor object also holds the editor driver (if I
am understanding the terminology correctly).
In detail:
Editor holds reference to the editor and its baton plus parent/child object
references:
const svn_delta_editor_t * m_deltaEditor;
void * m_editBaton;
SVNRa
Are you talking about maintaining the directory baton in the context
of something like an editor drive?
-Hyrum
On Fri, May 25, 2012 at 2:29 PM, Vladimir Berezniker wrote:
> The reason they are long lived is because they are reusable. E.g. directory
> can be used for any number of files/directori
The reason they are long lived is because they are reusable. E.g. directory
can be used for any number of files/directories within it. However,
regarding not needing to keep track of objects I think I see where you
are coming from. At the moment the parent and child objects are tied
because I allo
+1 to commit to trunk. Please include "Approved by: hwright" in the
log message.
Out of curiosity, why do directory objects need to live across method
invocations with the RA interface? I would have thought that even if
this is true, it won't matter, since those objects would be pure Java
object
Fixed. The corrected commit message is now:
[[[
On the javahl-ra branch:
Brought RA implementation up to date with changes merged from trunk in
r1329205
[in subversion/bindings/javahl/native]
* SVNReposAccess.cpp
(SVNReposAccess): Drop the global pool mutex as it is not necessary,
as
For the record, Vladimir committed this on the branch in r1342682, an
I merged it to trunk in r1342720.
-Hyrum
On Fri, May 25, 2012 at 12:08 PM, Vladimir Berezniker
wrote:
> Greetings,
>
> While working on enhancements for JavaHL I ran into a problem
> implementing svn_txdelta_apply call because
Greetings,
Currently SVNBase class uses a member variable jthis to hold a copy of
jobject
reference. This variable lives as long as SVNClient object lives, however,
the
reference itself is only valid during a single JNI call. To address this
mismatch
the attached patch passes the jobject referenc
Thank you. Please ignore the other email on this subject, I sent it before
I saw your reply.
Vladimir
On Fri, May 25, 2012 at 12:43 PM, Hyrum K Wright
wrote:
> Thanks for begin willing to work within the guidelines of the project.
> I understand that sometimes they may seem somewhat arbitrary,
Greetings,
While working on enhancements for JavaHL I ran into a problem
implementing svn_txdelta_apply
call because txdelta_next_window would segfault while trying to calculate
the streams checksum. I traced it down to code in the InputStream.cpp that
returns -1 when end of stream is reached. -1
Thanks for begin willing to work within the guidelines of the project.
I understand that sometimes they may seem somewhat arbitrary, but
they've grown out of a decade of experience. While they may at first
appear to increase friction, they generally work out to improve the
efficiency of the proje
As this change plus another one are beneficial for general JavaHL use, I
will send them as patches on separate threads.
Thank you for the guidance,
Vladimir
On Fri, May 25, 2012 at 12:06 PM, Hyrum K Wright
wrote:
> Is this change specific to the branch, or is is beneficial for general
> JavaHL
Hi, all.
I want to update you all on the "symmetric merge" [1] status and my plans, and
invite your thoughts and any assistance you can give.
I'll be presenting this subject at Elego's SvnDay [2] and at WANdisco events in
October, but the presentation will be aimed at users and so will concentr
Is this change specific to the branch, or is is beneficial for general
JavaHL use? If the latter, it should be committed to trunk first,
then backported to the branch.
I realize you don't (yet) have commit privileges to trunk. The way
this would usually work is that you'd post the patch, somebod
A couple stylistic nits on the log message:
On Fri, May 25, 2012 at 10:12 AM, wrote:
> Author: vmpn
> Date: Fri May 25 15:12:56 2012
> New Revision: 1342676
>
> URL: http://svn.apache.org/viewvc?rev=1342676&view=rev
> Log:
> On the javahl-ra branch:
>
> Brought RA implementation up to date with
On 25.05.2012 10:54, Philip Martin wrote:
Stefan Küng writes:
libsvn_tsvn32!svn_relpath_join+0x10
libsvn_tsvn32!svn_wc__internal_get_origin+0x1b2
libsvn_tsvn32!svn_client_commit5+0x14d3
libsvn_tsvn32!svn_client__harvest_committables+0x26a
libsvn_tsvn32!svn_client_commit5+0x2e4
here the 'statu
Stefan Küng writes:
> libsvn_tsvn32!svn_relpath_join+0x10
> libsvn_tsvn32!svn_wc__internal_get_origin+0x1b2
> libsvn_tsvn32!svn_client_commit5+0x14d3
> libsvn_tsvn32!svn_client__harvest_committables+0x26a
> libsvn_tsvn32!svn_client_commit5+0x2e4
>
> here the 'status' after svn_wc__db_scan_additio
On 24.05.2012 21:45, Hyrum K Wright wrote:
> I almost committed the change to configure.ac to require sqlite 3.7.12
> just now, but then realized that the bots would probably fail, as
> 3.7.12 is relatively new and it's likely the bots haven't been updated
> to use it. (But then I realized that it
19 matches
Mail list logo
