On Mon, Dec 6, 2010 at 8:09 AM, Stefan Sperling wrote:
> On Mon, Dec 06, 2010 at 07:18:56AM +1000, Daniel Becroft wrote:
> > On Fri, Dec 3, 2010 at 9:22 AM, Peter Samuelson wrote:
> >
> > >
> > > [Daniel Becroft]
> > > > I've just managed to build/install trunk on my ubuntu box at home
> (first
Instead of guessing which function causes the lstat() calls, could we
have a tool tell?
I've looked at 'ltrace -S', but it seems to me that will only tell us
which public svn_wc_* API is responsible for the calls. Perhaps there
is another tool that can help us follow the entire call chain down to
Stefan Fuhrmann wrote on Sun, Dec 05, 2010 at 23:45:50 +0100:
> On 01.12.2010 14:16, Daniel Shahaf wrote:
>> Julian Foad wrote on Wed, Dec 01, 2010 at 12:32:45 +:
>>> On Wed, 2010-12-01, stef...@apache.org wrote:
Port (not merge) a fix for a FSFS packing race condition from the
perfor
On 06.12.2010 08:48, Takács András wrote:
>> Here you are printing 64-bits, so some part of your system thinks that
>> apr_off_t is 64-bits. How are apr_off_t and APR_HAS_LARGE_FILES defined
>> in apr.h?
> #define APR_HAS_LARGE_FILES 0
> typedef off_t apr_off_t;
>
> I think this i
Hi Tim,
I am the patch manager - but am not an SVN developer.
So excuse me if this is a "silly" question.
This is the second email from you with the same subject line - and the patch
file has the same title too.
So is this a second version of the original patch - or an additional one at
this UR
Takács András writes:
>> Here you are printing 64-bits, so some part of your system thinks that
>> apr_off_t is 64-bits. How are apr_off_t and APR_HAS_LARGE_FILES defined
>> in apr.h?
>
> #define APR_HAS_LARGE_FILES 0
> typedef off_t apr_off_t;
>
> I think this is OK, isn't it?
Branko Čibej writes:
> On 06.12.2010 08:48, Takács András wrote:
>>> Here you are printing 64-bits, so some part of your system thinks that
>>> apr_off_t is 64-bits. How are apr_off_t and APR_HAS_LARGE_FILES defined
>>> in apr.h?
>> #define APR_HAS_LARGE_FILES 0
>> typedef off_t
On Mon, Dec 6, 2010 at 7:13 PM, Daniel Shahaf wrote:
> Instead of guessing which function causes the lstat() calls, could we
> have a tool tell?
>
> I've looked at 'ltrace -S', but it seems to me that will only tell us
> which public svn_wc_* API is responsible for the calls. Perhaps there
> is
[ crypto student hat on ]
Stefan Sperling wrote on Sun, Oct 17, 2010 at 16:03:13 +0200:
> Retreiving a password:
> Step 1: svn contacts the gpg-agent to find out the passphrase for the
> private pgp key the agent is managing. If the agent cannot be
> contacted svn asks the user for t
Stefan Sperling wrote on Sun, Oct 17, 2010 at 16:03:13 +0200:
> The GPGME library will probably help with these steps:
> http://www.gnupg.org/gpgme.html
By the way, the GPGME library supports symmetric (password-keyed, as
with 'gpg -c') encryptions [1], in addition to PGP assymetric
encryptions.
On Sun, 2010-12-05, Stefan Fuhrmann wrote:
> On 02.12.2010 12:18, Julian Foad wrote:
> > A good test for whether it's worth making an API accept NULL as an input
> > is: what proportion of the callers would find that useful? I see there
> > are about 40 callers in the code base. Would you mind sc
On Mon, 2010-12-06 at 07:30 -0500, Daniel Shahaf wrote:
> Ideally, Subversion won't know the PGP passphrase. (If it does, then
> a malicious libsvn_subr can compromise a private key.)
I think you're trying to solve a different problem here. The goal is to
minimize typing of passwords without sto
On 12/04/2010 04:08 AM, Noorul Islam K M wrote:
> * subversion/libsvn_client/copy.c
> (try_copy): Combine redundant 'if' block.
>
> Patch by: Noorul Islam K M
Sendingtrunk/subversion/libsvn_client/copy.c
Transmitting file data .
Committed revision 1042679.
Thanks!
--
C. Mic
On Sun, 2010-12-05, Stefan Fuhrmann wrote:
> On 02.12.2010 07:57, Blair Zajac wrote:
> > On 12/1/10 4:38 PM, stef...@apache.org wrote:
> >> Author: stefan2
> >> Date: Thu Dec 2 00:38:17 2010
> >> New Revision: 1041230
> >>
> >> URL: http://svn.apache.org/viewvc?rev=1041230&view=rev
> >> Log:
> >>
On Sat, 2010-12-04 at 13:01 +0530, Noorul Islam K M wrote:
> Julian Foad writes:
>
> > Noorul Islam K M wrote:
> >
> >> Julian Foad writes:
> >> > * "svn mkdir ^/ a" -> "Illegal repository URL 'a'"; should say "can't
> >> > mix URL and local targets"?
> > [...]
> >> Make 'svn mkdir' verify tha
On Sat, 2010-12-04, Noorul Islam K M wrote:
> Julian Foad writes:
> > Noorul Islam K M wrote:
> >> Julian Foad writes:
> >> > * "svn info ^/b" -> "Not a valid URL"; should be "path '/b' not found
> >> > in revision REV"?
[...]
> >> - SVN_ERR(svn_cmdline_fprintf
> >> -
I'm going to drop this "Remove the re-try logic from
svn_fs_fs__path_rev_absolute()" follow-up patch, as I don't want to get
into checking or messing with the txn-correctness of FSFS now. If
Daniel or anyone else wants to pursue it, I'd be glad to help.
- Julian
On Thu, 2010-12-02, Daniel Shaha
On Tue, 2010-11-30, Danny Trebbien wrote:
> Attached is version 4 of the patch and corresponding log message that
> address Daniel Shahaf's feedback from November 9.
>
> Per a message from Julian
> (http://article.gmane.org/gmane.comp.version-control.subversion.devel/124073)
> and Daniel Shahaf
>
Julian Foad writes:
> I'm going to drop this "Remove the re-try logic from
> svn_fs_fs__path_rev_absolute()" follow-up patch, as I don't want to get
> into checking or messing with the txn-correctness of FSFS now. If
> Daniel or anyone else wants to pursue it, I'd be glad to help.
I thought the
Greg Hudson wrote on Mon, Dec 06, 2010 at 10:31:05 -0500:
> On Mon, 2010-12-06 at 07:30 -0500, Daniel Shahaf wrote:
> > Ideally, Subversion won't know the PGP passphrase. (If it does, then
> > a malicious libsvn_subr can compromise a private key.)
>
> I think you're trying to solve a different pr
On Mon, Dec 6, 2010 at 8:50 PM, Daniel Becroft wrote:
> On Mon, Dec 6, 2010 at 7:13 PM, Daniel Shahaf wrote:
>
>> Instead of guessing which function causes the lstat() calls, could we
>> have a tool tell?
>>
>> I've looked at 'ltrace -S', but it seems to me that will only tell us
>> which public
On Mon, Dec 6, 2010 at 3:15 PM, Daniel Becroft wrote:
> On Mon, Dec 6, 2010 at 8:50 PM, Daniel Becroft wrote:
>
>> On Mon, Dec 6, 2010 at 7:13 PM, Daniel Shahaf wrote:
>>
>>> Instead of guessing which function causes the lstat() calls, could we
>>> have a tool tell?
>>>
>>> I've looked at 'ltrace
> Just about to commit this ... FAIL: autoprop_tests.py 15, blame_tests.py
> 7, commit_tests.py 40, ...
>
> subst.c' line 668: assertion failed (STRING_IS_EOL(eol_str,
> eol_str_len))
>
> Whassup? Attaching my version, as I'm out of time tonight. Hope I
> didn't mess it up. I was testing tr...@1
On Mon, Dec 6, 2010 at 4:28 PM, Hyrum K. Wright
wrote:
> On Mon, Dec 6, 2010 at 3:15 PM, Daniel Becroft wrote:
>> On Mon, Dec 6, 2010 at 8:50 PM, Daniel Becroft wrote:
>>
>>> On Mon, Dec 6, 2010 at 7:13 PM, Daniel Shahaf
>>> wrote:
>>>
Instead of guessing which function causes the lstat()
I'm working with a client and they have a large source source code checkout that
takes over 10 minutes do to an svn update. Their 1.6.x working copy size is 3.6
GB with 74,000 files and 19,230 directories. The amount of IO to do all the
locking and reading entries files is taking a significant
On 12/6/10 7:47 AM, Julian Foad wrote:
On Sun, 2010-12-05, Stefan Fuhrmann wrote:
I've felt kind of uneasy about that issue as well.
However, it would have been difficult to implement
a deprecated svn_checksum_to_cstring() in terms
of svn_checksum_to_cstring2().
I don't think Blair was concern
On Tue, Dec 7, 2010 at 2:01 PM, Blair Zajac wrote:
> I'm working with a client and they have a large source source code checkout
> that takes over 10 minutes do to an svn update. Their 1.6.x working copy
> size is 3.6 GB with 74,000 files and 19,230 directories. The amount of IO
> to do all th
27 matches
Mail list logo
