Translation status report for trunk@r1608656
lang trans untrans fuzzy obs
--
de2722 59 226 471 +++~~~
es2230 551 791 528 ++U~~~
fr2533 248
Again reply to the list too :)
GUI's which change buttons etc. depending on whatever they like are bad...
On 07/08/14 08:02, Martin Furter wrote:
On 07/08/14 03:33, Ben Reser wrote:
On 7/6/14 5:16 AM, Martin Furter wrote:
Attached is a log message and a patch which adds the new options
'--pas
On 7/6/14 5:16 AM, Martin Furter wrote:
> Attached is a log message and a patch which adds the new options
> '--password-file' and '--password-envvar'. It also adds Julians warning to the
> '--password' help text.
I veto (-1) --password-envar (and peters follow-up suggestion of a hard-coded
enviro
[Martin Furter]
> Attached is a log message and a patch which adds the new options
> '--password-file' and '--password-envvar'.
I don't agree with --password-envvar. If we're going to support
reading a password from the environment at all, just do what everyone
always does with the environment:
On 7 July 2014 20:44, Julian Foad wrote:
> I should probably let Stefan answer this, but...
>
> C. Michael Pilato wrote:
>>> On 07.07.2014 17:07, C. Michael Pilato wrote:
On 07/07/2014 10:58 AM, Ivan Zhakov wrote:
> My technical opinion that FSFS7/log addressing is slower by design,
>
On Mon, Jul 7, 2014 at 2:44 PM, Stefan Fuhrmann <
stefan.fuhrm...@wandisco.com> wrote:
> I just started the Windows tests in a "realistic" environment
> with a 4GB RAM server managing > 50GB of repository data.
> The goal is clearly that the default config is not slower than
> before and the compu
On 07.07.2014 20:44, Stefan Fuhrmann wrote:
> ... it makes SVN parse the
> whole 64k block that the OS provides anyway ...
[off-topic]
See, this is the kind of statement that makes me uneasy. You make an
assertion about "the OS" (or about "the CPU" or "the architecture") as
if it were generally t
On Mon, Jul 7, 2014 at 5:54 PM, C. Michael Pilato wrote:
> On 07/07/2014 11:23 AM, Branko Čibej wrote:
>> On 07.07.2014 17:07, C. Michael Pilato wrote:
>>> On 07/07/2014 10:58 AM, Ivan Zhakov wrote:
My technical opinion that FSFS7/log addressing is slower by design,
because it's doing mo
On Mon, Jul 7, 2014 at 12:44 PM, Julian Foad
wrote:
>
> C-Mike, my understanding is that F7 comprehensively beats F6 speed, by
> large factors around x1.5 and more, in the kind of scenarios it's designed
> for. Caching is an assumed part of the design. I don't know how much it
> needs for what sc
I should probably let Stefan answer this, but...
C. Michael Pilato wrote:
>> On 07.07.2014 17:07, C. Michael Pilato wrote:
>>> On 07/07/2014 10:58 AM, Ivan Zhakov wrote:
My technical opinion that FSFS7/log addressing is slower by design,
because it's doing more (read index, then read dat
On 07/07/2014 11:23 AM, Branko Čibej wrote:
> On 07.07.2014 17:07, C. Michael Pilato wrote:
>> On 07/07/2014 10:58 AM, Ivan Zhakov wrote:
>>> My technical opinion that FSFS7/log addressing is slower by design,
>>> because it's doing more (read index, then read data instead of just
>>> read data) an
On 07.07.2014 17:07, C. Michael Pilato wrote:
> On 07/07/2014 10:58 AM, Ivan Zhakov wrote:
>> My technical opinion that FSFS7/log addressing is slower by design,
>> because it's doing more (read index, then read data instead of just
>> read data) and only caching makes them comparable on performanc
On 07/07/2014 10:58 AM, Ivan Zhakov wrote:
> My technical opinion that FSFS7/log addressing is slower by design,
> because it's doing more (read index, then read data instead of just
> read data) and only caching makes them comparable on performance to
> FSFS6 repositories.
I'm coming into this ki
On 07.07.2014 16:25, Ivan Zhakov wrote:
> On 27 August 2013 03:53, wrote:
>> Author: stefan2
>> Date: Mon Aug 26 23:53:19 2013
>> New Revision: 1517733
>>
>> URL: http://svn.apache.org/r1517733
>> Log:
>> Following up on a suggestion by Ivan on @dev about a month ago.
>>
>> This is an initial dra
On 1 July 2014 03:27, Johan Corveleyn wrote:
> On Mon, Jun 30, 2014 at 6:21 PM, Ivan Zhakov wrote:
>> On 30 June 2014 18:51, Stefan Fuhrmann wrote:
>>> On Mon, Jun 30, 2014 at 4:06 PM, Ivan Zhakov wrote:
On 19 June 2014 14:21, Ivan Zhakov wrote:
> Hi,
>
> I've performe
On 27 August 2013 03:53, wrote:
> Author: stefan2
> Date: Mon Aug 26 23:53:19 2013
> New Revision: 1517733
>
> URL: http://svn.apache.org/r1517733
> Log:
> Following up on a suggestion by Ivan on @dev about a month ago.
>
> This is an initial draft plus completely untested implementation
> for an
Ben Reser wrote:
> On 7/3/14 12:21 PM, Gabriela Gibson wrote:
>> Currently, the global options are displayed on many svn help topics, and
>> that's
>> an extra 16 lines at the end, which makes the actual help info that is sought
>> scroll off the screen, and it's not information that always needed
On 07.07.2014 10:51, Julian Foad wrote:
> Branko Čibej wrote:
>> On 07.07.2014 10:27, Julian Foad wrote:
>>> Aha! But Subversion already has a way to read authn creds from a file:
>>>
>>> --config-dir=x
>>>
>>> All we're lacking is a convenient way to put the required creds into
>>> the file. A
Branko Čibej wrote:
> On 07.07.2014 10:27, Julian Foad wrote:
>> Aha! But Subversion already has a way to read authn creds from a file:
>>
>> --config-dir=x
>>
>> All we're lacking is a convenient way to put the required creds into
>> the file. A user interface could be:
>>
>> svn auth auth
On 07.07.2014 10:27, Julian Foad wrote:
> Martin Furter wrote:
>
For the file solution it might be more useful to use both username and
password from that file.
>>> I guess the option should be named different then, maybe something like
>>> --auth-file or --creds-file or so.
> Aha! Bu
Martin Furter wrote:
>>> For the file solution it might be more useful to use both username and
>>> password from that file.
>>
>> I guess the option should be named different then, maybe something like
>> --auth-file or --creds-file or so.
Aha! But Subversion already has a way to read authn
On Sun, Jul 06, 2014 at 08:43:06PM +0530, Martin Furter wrote:
>
> Resending my reply to the list too...
>
> >I don't know a command which shows the environment of a process as nice
> >as 'ps' shows the process arguments.
ps -e on OpenBSD < 5.3 used to show the environment of every process
on th
22 matches
Mail list logo
