Philip Martin wrote:
> I've been thinking of writing some code to populate the rep-cache from
> existing revisions. This code would parse the revision, a bit like
> verify, identify checksums in that revision and add any that are found
> to the rep-cache. This would be time consuming if run on th
Ivan Zhakov wrote:
> Please find patch that adds disk flushes to FSFS packing code in attachment.
>
> I'm currently testing it and going to commit it later. This patch
> should also slightly improve packing performance as a bonus, since we
> can avoid APR buffered IO for some cases.
Note that you
Julian Foad writes:
> Stefan Fuhrmann wrote:
>> * clear the rep-cache.db
>
> Clearing the cache and continuing operation may make subsequent
> commits much larger than they should be, and there is no easy way to
> undo that if it happens.
I've been thinking of writing some code to populate the r
On Sun, May 24, 2015 at 2:51 AM, James McCoy wrote:
> The patch is working for me as well.
>
I've dug a little deeper and think I've found a serious flaw in how the
Perl bindings handle
the Perl arguments and return values stack.
Swig generates for Perl what is known (in the Perl world) as XS c
On 27 May 2015 at 19:56, Ivan Zhakov wrote:
> On 27 May 2015 at 19:48, Philip Martin wrote:
>> Julian Foad writes:
>>
>>> Evgeny Kotkov wrote:
Philip, Julian, thank you for giving this patch a look.
As I said in my previous e-mails, I think that the committed fix is a
better
Philip Martin wrote:
> Julian Foad writes:
>> Evgeny Kotkov wrote:
>>> Philip, Julian, thank you for giving this patch a look.
>>>
>>> As I said in my previous e-mails, I think that the committed fix is a better
>>> choice here, as opposed to attempts to achieve the same behavior using the
>>> stre
On 27 May 2015 at 19:48, Philip Martin wrote:
> Julian Foad writes:
>
>> Evgeny Kotkov wrote:
>>> Philip, Julian, thank you for giving this patch a look.
>>>
>>> As I said in my previous e-mails, I think that the committed fix is a better
>>> choice here, as opposed to attempts to achieve the sam
Julian Foad writes:
> Evgeny Kotkov wrote:
>> Philip, Julian, thank you for giving this patch a look.
>>
>> As I said in my previous e-mails, I think that the committed fix is a better
>> choice here, as opposed to attempts to achieve the same behavior using the
>> stream API. [...]
>
> That soun
Stefan Fuhrmann wrote:
> Alright. I gave it a bit more thought now.
>
> Whenever we encounter this mismatch, something pretty
> bad likely happened to the repo - such as a failed restore
> attempt. In turn, we can expect those situations to be
> very rare - which means we can afford some disruption
On Wed, May 27, 2015 at 1:11 PM, Julian Foad wrote:
> Stefan Fuhrmann wrote:
> > Julian Foad wrote:
> >> @@ -2262,14 +2264,20 @@ get_shared_rep(representation_t **old_re
> >>
> >>/* A simple guard against general rep-cache induced corruption. */
> >>if ((*old_rep)->expanded_size != rep->e
Evgeny Kotkov wrote:
> Philip, Julian, thank you for giving this patch a look.
>
> As I said in my previous e-mails, I think that the committed fix is a better
> choice here, as opposed to attempts to achieve the same behavior using the
> stream API. [...]
That sounds good to me -- leaving the cod
Philip Martin writes:
> Yes, that looks good.
[...]
Julian Foad writes:
> Just a couple of comments, from a quick read of the patch.
[...]
Philip, Julian, thank you for giving this patch a look.
As I said in my previous e-mails, I think that the committed fix is a better
choice here, as op
Stefan Fuhrmann wrote:
> Julian Foad wrote:
>> Stefan Sperling wrote:
>>> Is it worth extending the comment in the code with information from
>>> this thread?
>>
>> IMO, Yes it is worth it.
>
> O.k. Done in r1681960 and r1681965.
Thanks!
- Julian
On Thu, May 21, 2015 at 2:26 PM, Ivan Zhakov wrote:
> On 20 May 2015 at 20:31, Bert Huijben wrote:
> >> -Original Message-
> >> From: Branko Čibej [mailto:br...@wandisco.com]
> >> Sent: maandag 11 mei 2015 12:31
> >> To: Subversion Development
> >> Subject: Getting ready for RC2 (was: Ap
On 27 May 2015 at 13:23, Stefan Fuhrmann wrote:
> On Wed, May 27, 2015 at 12:11 PM, Ivan Zhakov wrote:
>>
>> On 27 May 2015 at 12:49, Stefan Fuhrmann
>> wrote:
>> > On Wed, May 27, 2015 at 11:28 AM, Ivan Zhakov
>> > wrote:
>> >>
>> >> It seems directory cache checked twice in function
>> >> svn
Stefan Fuhrmann wrote:
> Julian Foad wrote:
>> + /* ### Would it be faster (and so better) to just try reading it,
>> + and handle ENOENT, instead of first checking for presence? */
>>SVN_ERR(svn_io_check_path(file_name, &kind, scratch_pool));
>>if (kind == svn_node
On Mon, May 25, 2015 at 11:26 PM, Julian Foad
wrote:
> Stefan Sperling wrote:
> > Is it worth extending the comment in the code with information from
> > this thread?
>
> IMO, Yes it is worth it.
>
O.k. Done in r1681960 and r1681965.
-- Stefan^2.
On Wed, May 27, 2015 at 12:11 PM, Ivan Zhakov wrote:
> On 27 May 2015 at 12:49, Stefan Fuhrmann
> wrote:
> > On Wed, May 27, 2015 at 11:28 AM, Ivan Zhakov
> wrote:
> >>
> >> It seems directory cache checked twice in function
> >> svn_fs_fs__rep_contents_dir_entry:
> >> [[[
> >> svn_error_t *
>
On Tue, May 26, 2015 at 11:15 PM, Julian Foad wrote:
> Index: subversion/libsvn_fs_fs/transaction.c
> ===
> --- subversion/libsvn_fs_fs/transaction.c(revision 1681856)
> +++ subversion/libsvn_fs_fs/transaction.c(working copy)
On 27 May 2015 at 12:49, Stefan Fuhrmann wrote:
> On Wed, May 27, 2015 at 11:28 AM, Ivan Zhakov wrote:
>>
>> It seems directory cache checked twice in function
>> svn_fs_fs__rep_contents_dir_entry:
>> [[[
>> svn_error_t *
>> svn_fs_fs__rep_contents_dir_entry(svn_fs_dirent_t **dirent,
>>
On Wed, May 27, 2015 at 11:28 AM, Ivan Zhakov wrote:
> It seems directory cache checked twice in function
> svn_fs_fs__rep_contents_dir_entry:
> [[[
> svn_error_t *
> svn_fs_fs__rep_contents_dir_entry(svn_fs_dirent_t **dirent,
> svn_fs_t *fs,
>
It seems directory cache checked twice in function
svn_fs_fs__rep_contents_dir_entry:
[[[
svn_error_t *
svn_fs_fs__rep_contents_dir_entry(svn_fs_dirent_t **dirent,
svn_fs_t *fs,
node_revision_t *noderev,
Hi Bert.
Bert Huijben wrote:
> On Windows opening the file is sensitive to outside interactions and may
> trigger a retry loop. [...] A filestat is +- a constant time operation that
> doesn't have these problems.
OK...
> So this really depends on how common all cases are. If not existing or
> po
23 matches
Mail list logo
