Translation status report for trunk@r1605003
lang trans untrans fuzzy obs
--
de2719 60 221 471 +++~~~
es2229 550 790 528 ++U~~~
fr2531 248
On Fri, Jun 20, 2014 at 12:06:22AM +, Daniel Shahaf wrote:
> One of my colleagues ran bisect but forgot to update back to HEAD after
> finishing it. Another forgot to run 'svn up' in the morning before starting
> to edit a file, and later got conflicts
Just a "dumb" question from the off... t
On Mon, Jun 23, 2014 at 11:55 PM, Stefan Sperling wrote:
> I'm still seeing 180MB of memory used by svn log -v with ruby's r11708
> over ra_local with fsfs7-unpacked (120MB with fsfs6-unpacked).
> The total output generated by svn log is only 5.5MB in size.
> That seems somewhat disproportionate.
On Mon, Jun 23, 2014 at 11:41 PM, Stefan Sperling wrote:
> The FSFS changes cache returns an array representation of changed
> path data which needs to be converted back to a hash for API reasons
> by svn_fs_fs__paths_changed(). No other function accesses the
> changes cache so returning a tempor
I'm still seeing 180MB of memory used by svn log -v with ruby's r11708
over ra_local with fsfs7-unpacked (120MB with fsfs6-unpacked).
The total output generated by svn log is only 5.5MB in size.
That seems somewhat disproportionate.
Of course, I'm happy that this invocation of svn log isn't runnin
The FSFS changes cache returns an array representation of changed
path data which needs to be converted back to a hash for API reasons
by svn_fs_fs__paths_changed(). No other function accesses the
changes cache so returning a temporary array seems odd.
Wouldn't it make sense for the cache to return
On Sat, 2014-06-21 at 13:37 +, Daniel Shahaf wrote:
> Carlos Martín Nieto wrote on Fri, Jun 20, 2014 at 17:06:53 +0200:
> > Hi,
> >
> > libgit2 v0.21.0 was just released, and there have been some changes to the
> > API.
> >
>
> Thanks!
>
> Seeing as the patch breaks compatibility with olde
I don’t know, this was added in r1496954 with message
[[
Allow 'svn cleanup' to remove unversioned items from the working copy.
This should address the feature request from issue #3549.
Add two new options to 'svn cleanup', --remove-unversioned and --no-ignore.
The former causes unversioned
On 23.06.2014 13:13, rhuij...@apache.org wrote:
> Author: rhuijben
> Date: Mon Jun 23 11:13:55 2014
> New Revision: 1604749
This comment doesn't really refer to this commit, but since it's recent ...
> @@ -4160,6 +4174,7 @@ svn_client_cleanup2(const char *dir_absp
> *
> * @deprecated Provided
On Mon, Jun 23, 2014 at 2:08 PM, Stefan Sperling wrote:
> On Mon, Jun 23, 2014 at 01:55:32PM +0200, Branko Čibej wrote:
>> There's a world of difference here. The former is an error that prevents
>> you from using the working copy. The latter case doesn't prevent anything.
>
> This discussion is a
Julian Foad wrote on Mon, Jun 23, 2014 at 09:15:15 +0100:
> Markus Schaber wrote (in thread "controversial issues in the tracker"):
> > 4154 svn add foo foo complains
> > http://subversion.tigris.org/issues/show_bug.cgi?id=4154
> >
> > This issue suggests removing duplicates in the argument list o
On Mon, Jun 23, 2014 at 01:55:32PM +0200, Branko Čibej wrote:
> There's a world of difference here. The former is an error that prevents
> you from using the working copy. The latter case doesn't prevent anything.
This discussion is about a performance issue, not a behavioural one.
> BTW, don't y
On 23.06.2014 13:34, Johan Corveleyn wrote:
> Why not? We can give them a hint, right? Exactly like "Working copy
> 'bla' locked. Run 'svn cleanup' to remove locks." we could say
> "Working copy 'bla' has 10% incorrect metadata. Run 'svn cleanup
> --sync-metadata' to optimize your working copy".
On Mon, Jun 23, 2014 at 12:03 PM, Bert Huijben wrote:
>
>
>> -Original Message-
>> From: Johan Corveleyn [mailto:jcor...@gmail.com]
>> Sent: maandag 23 juni 2014 11:41
>> To: Bert Huijben
>> Cc: Julian Foad; Markus Schaber; Subversion Dev
>> Subject: Re: Issue #4162: make svn status fix ti
> -Original Message-
> From: Johan Corveleyn [mailto:jcor...@gmail.com]
> Sent: maandag 23 juni 2014 11:41
> To: Bert Huijben
> Cc: Julian Foad; Markus Schaber; Subversion Dev
> Subject: Re: Issue #4162: make svn status fix timestamp mismatches in meta-
> data
>
> On Mon, Jun 23, 2014 at
On 23.06.2014 11:43, Julian Foad wrote:
> Branko Čibej wrote:
>> Bert Huijben wrote:
>>> Changing the recorded timestamps would require obtaining a write lock while
>>> performing a status walk... which is a breaking change for any client that
>>> wants to do things concurrently. -1 on 'just doing
Branko Čibej wrote:
> Bert Huijben wrote:
>> Changing the recorded timestamps would require obtaining a write lock while
>> performing a status walk... which is a breaking change for any client that
>> wants to do things concurrently. -1 on 'just doing it' There is a good reason
>> the current cod
On Mon, Jun 23, 2014 at 11:08 AM, Bert Huijben wrote:
>
>
>> -Original Message-
>> From: Julian Foad [mailto:julianf...@btopenworld.com]
>> Sent: maandag 23 juni 2014 10:03
>> To: Markus Schaber
>> Cc: Subversion Dev (dev@subversion.apache.org)
>> Subject: Issue #4162: make svn status fix
On 23.06.2014 10:54, Julian Foad wrote:
> Daniel Shahaf wrote:
>
>> One of my colleagues ran bisect but forgot to update back to HEAD after
>> finishing it. Another forgot to run 'svn up' in the morning before starting
>> to edit a file, and later got conflicts
>>
>> Both of these user errors migh
On 23.06.2014 11:08, Bert Huijben wrote:
>
>> -Original Message-
>> From: Julian Foad [mailto:julianf...@btopenworld.com]
>> Sent: maandag 23 juni 2014 10:03
>> To: Markus Schaber
>> Cc: Subversion Dev (dev@subversion.apache.org)
>> Subject: Issue #4162: make svn status fix timestamp mismat
> -Original Message-
> From: Julian Foad [mailto:julianf...@btopenworld.com]
> Sent: maandag 23 juni 2014 10:03
> To: Markus Schaber
> Cc: Subversion Dev (dev@subversion.apache.org)
> Subject: Issue #4162: make svn status fix timestamp mismatches in meta-
> data
>
> Markus Schaber wrote
Ivan Zhakov wrote:
> On 20 June 2014 18:38, Julian Foad wrote:
>> Index: subversion/include/svn_wc.h
>> + /** Finalizing commit.
>> + * @since New in 1.9. */
>> + svn_wc_notify_commit_finalizing
>> } svn_wc_notify_action_t;
>>
>> This is a public API. We should document what other fiel
Daniel Shahaf wrote:
> One of my colleagues ran bisect but forgot to update back to HEAD after
> finishing it. Another forgot to run 'svn up' in the morning before starting
> to edit a file, and later got conflicts
>
> Both of these user errors might have been prevented if their client had
> adv
Markus Schaber wrote (in thread "controversial issues in the tracker"):
> * 2491 Add --dry-run flag to "svn update" client command
> http://subversion.tigris.org/issues/show_bug.cgi?id=2491
>
> There already was a patch submitted by Arwin Arni 2011 and discussed on the
> list, but it was not appl
Markus Schaber wrote (in thread "controversial issues in the tracker"):
> 4154 svn add foo foo complains
> http://subversion.tigris.org/issues/show_bug.cgi?id=4154
>
> This issue suggests removing duplicates in the argument list of "svn
> add". The example was the command line
> svn add f* *o
> w
Markus Schaber wrote:
> While querying the issue tracker for bite-sized issues, I found the following
> ones which seem to be controversial.
>
> Maybe we should try to come to a consensus with each of them, either agreeing
> on
> a way of implementing them, or closing them as "won't fix".
Goo
Markus Schaber wrote (in thread "controversial issues in the tracker"):
> * 4162 make svn status fix timestamp mismatches in meta-data
> http://subversion.tigris.org/issues/show_bug.cgi?id=4162
>
> The controversial issue here is whether it is a good idea to have "svn
> status" modify the meta d
27 matches
Mail list logo
