Hi Daniel,
Stefan Hett wrote on Tue, Apr 05, 2016 at 11:23:52 +0200:
Hi Stefan,
On Mon, Apr 04, 2016 at 11:28:41PM +0200, Stefan wrote:
Should this be also nominated for backporting to the 1.8 branch, since the
issue has been reported in 1.8.11
(https://issues.apache.org/jira/browse/SVN-4624
Hi Stefan,
On Mon, Apr 04, 2016 at 11:28:41PM +0200, Stefan wrote:
Should this be also nominated for backporting to the 1.8 branch, since the
issue has been reported in 1.8.11
(https://issues.apache.org/jira/browse/SVN-4624)?
Officially, no. Because 1.8.x only receives fixes for security or
On Mon, Apr 04, 2016 at 11:28:41PM +0200, Stefan wrote:
> Should this be also nominated for backporting to the 1.8 branch, since the
> issue has been reported in 1.8.11
> (https://issues.apache.org/jira/browse/SVN-4624)?
Officially, no. Because 1.8.x only receives fixes for securit
Votes:
+ +1: danielsh
+
Veto-blocked changes:
=
Should this be also nominated for backporting to the 1.8 branch, since
the issue has been reported in 1.8.11
(https://issues.apache.org/jira/browse/SVN-4624)?
Regards,
Stefan
On Fri, Apr 01, 2016 at 04:38:00AM -0500, Greg Stein wrote:
> no no no ... we've always said that OUT parameters are not dependable when
> an error occurs.
Do our API docs mention this anywhere?
Or was this information only passed around among SVN devs?
I don't disagree. But we should clearly com
*may_save_plaintext = FALSE;
> > - return SVN_NO_ERROR;
> > + return err;
> Daniel, do you know what was the original idea behind ignoring the
> SVN_ERR_CANCELLED error? I see stsp committed the original code in
> r870804, so there's probably some rationale behin
On Mon, Mar 14, 2016 at 11:35:32AM +0100, Raphael Kubo da Costa wrote:
> [[[
> At the moment the kde4-config script is used only to determine KDE4's
> prefix, and then its header and library locations are derived manually.
>
> This is not optimal, as it assumes the libraries are always installed
>
On Mon, Feb 29, 2016 at 07:30:14PM +0100, Vincent Lefevre wrote:
> For "svn st", I do not try to access the file. A file with an invalid
> name cannot be a versioned file anyway. So, it could also just be
> ignored, and outputting a non-fatal warning would be sufficient, IMHO.
> Note that even "svn
Hi all,
The first section of that file looks like a keeper
but most of the status info is horribly outdated
and can probably be removed.
Could someone with in-depth ra_serf knowledge please
update the file?
-- Stefan^2.
inside it as
the first sub-element). I tried to hint at that in the comment
just above that block. The svn:// protocol is quite lisp-y
in its use of parentheses ...
But still, thanks for reviewing the changes!
-- Stefan^2.
Enumate -> Emulate
Hi James,
Belated thanks for fixing this!
-- Stefan^2.
On Sun, Feb 21, 2016 at 02:22:45PM +0100, Branko Čibej wrote:
> Personally I'd much prefer the svn_utf__casefold() you propose (i.e.,
> normalize plus casefold) as a separate API. Internally, it can be
> implemented with that extra flag, but even for a private API, I think
> it's better to make eac
On 15.02.2016 23:45, Bert Huijben wrote:
Are you sure the pool arguments are in the right order here?
The usual order is result_pool, scratch_pool while most of the calls here appear
to use the opposite order.
The pool usage is correct but somewhat confusing.
r1731160 fixes that.
-- Stefan^2
On 16.02.2016 11:30, Ivan Zhakov wrote:
On 16 February 2016 at 08:47, Stefan Fuhrmann wrote:
On 15.02.2016 09:39, Ivan Zhakov wrote:
On 14 February 2016 at 22:25, wrote:
Author: stefan2
Date: Sun Feb 14 19:25:12 2016
New Revision: 1730389
URL: http://svn.apache.org/viewvc?rev=1730389
s solutions in mind, but maybe you also know something
about this.
The only reasonable alternative is to pick option
(2) and hope that the performance regression in
real-life is acceptable.
[1] http://svn.haxx.se/users/archive-2015-12/0060.shtml
-- Stefan^2.
On Wed, Feb 17, 2016 at 05:33:21PM +0300, Ivan Zhakov wrote:
> As we are adding more and more of such code, more and more users
> become faced with the significant performance regression (see [1] and
> other cases).
>
> Do you intend to resolve this problem in the future commits? I have
> some obv
On Wed, Feb 17, 2016 at 04:55:45PM +0100, Bert Huijben wrote:
> The new variable incoming_change is used uninitialized here, breaking the
> build on the Windows bots.
>
> See https://ci.apache.org/builders/svn-windows-local/builds/1046
Thanks for the heads up! Fixed in r1730943.
ocumented svn_repos__get_logs5() API it's almost
impossible to get idea of all following commits in log.c
The API definition / migration is complete now and the next
step is publish it. It'll then get a proper docstring.
-- Stefan^2.
On Mon, Feb 15, 2016 at 05:30:55PM +0100, Bert Huijben wrote:
> Why would you need to wait for timestamps here?
>
> Can this change the working copy file?
>
> If it can the wc function should probably return a boolean to notify the case
> where it does, and only when it does we should wait for t
On 03.02.2016 13:36, Ivan Zhakov wrote:
On 31 January 2016 at 14:03, Stefan Fuhrmann wrote:
Hi there,
When the server needs to transmit the list of changed paths
in a revision, its memory usage is O(#changes), i.e. practically
unbound. The problems are:
* FS and repos API require a full
ke it you wanted to forward that to the subclipse developer mailing
list as Eric suggested. However, you ended up sending it to the
subversion developer mailing list instead...
The subclipse dev list is d...@subclipse.tigris.org
Regards,
Stefan
On 2/9/2016 04:22, Daniel Shahaf wrote:
Stefan wrote on Sun, Feb 07, 2016 at 20:51:08 +0100:
On 2/7/2016 01:22, Daniel Shahaf wrote:
Stefan wrote on Mon, Feb 01, 2016 at 00:34:32 +0100:
+++ fs-loader.c (working copy)
@@ -461,7 +461,8 @@
if (! svn_utf__cstring_is_valid(path
On 2/7/2016 01:22, Daniel Shahaf wrote:
Stefan wrote on Mon, Feb 01, 2016 at 00:34:32 +0100:
+++ fs-loader.c (working copy)
@@ -461,7 +461,8 @@
if (! svn_utf__cstring_is_valid(path))
{
return svn_error_createf(SVN_ERR_FS_PATH_SYNTAX, NULL
1.8 branch? The issue suggests the
bug exists on the 1.8 branch as well.
Regards,
Stefan
On Thu, Feb 04, 2016 at 01:00:38PM +0100, Vincenzo Reale wrote:
> Hi guys,
> I would share and submit a complete revision
> (spellchecked and with new strings) of the Italian
> translation for subversion.
>
> https://drive.google.com/file/d/
> 0B9FgaTlI6p0ybGFhWjk1X3E3SDA/view?usp=sharing
>
> B
On Thu, Feb 04, 2016 at 12:38:54PM +0100, Bert Huijben wrote:
>
>
> > -Original Message-
> > From: phi...@apache.org [mailto:phi...@apache.org]
> > Sent: woensdag 3 februari 2016 15:27
> > To: comm...@subversion.apache.org
> > Subject: svn commit: r1728324 -
> > /subversion/trunk/subversi
On Tue, Feb 02, 2016 at 07:48:53PM -0600, Greg Stein wrote:
> On Tue, Feb 2, 2016 at 7:45 PM, Eric S. Raymond wrote:
> > Because of the difference between Subversion and DVCS branching models,
> > this kind of situation is better handled by using svncutter to extract
> > the components into separa
On Mon, Feb 01, 2016 at 12:44:38PM +0100, Andreas Scherer wrote:
> Am Montag, 1. Februar 2016, 10:51:39 schrieb Stefan Sperling:
> > So we could consider extending svn patch to run without a path argument
> > and read the patch from stdin.
> >
> > [...] this feature fa
On Sun, Jan 31, 2016 at 11:48:26AM +0100, Andreas Scherer wrote:
> I suggest to extend 'svn patch' so that it supports usage in a pipe like
>
> gzip -dc patch-0042.gz | svn patch -P patch-0042 -
>
> This would permit using 'svn patch' directly as a drop-in replacement for
>
>gzip -dc pat
rivate.h) or so.
I won't be online today until later tonight.
-- Stefan^2.
log message.
Nope, wrong file. Got reverted & fixed.
I tried to update the commit message
yesterday but it told me that I'm
not allowed to. I'll try to fix it
tonight.
-- Stefan^2.
state.me.us%3E
Reported by: James Patten
* libsvn_wc/conflicts.c:
(build_text_conflict_resolve_items): check mine_abspath for null before
using it and return an error
instead.
]]
Regard
he message, in case
it actually is null.
]]
Regards,
Stefan
Index: fs-loader.c
===
--- fs-loader.c (revision 1727868)
+++ fs-loader.c (working copy)
@@ -461,7 +461,8 @@
if (! svn_utf__cstring_is_
n weekends. There will be two-way conversion between
old and new APIs to facilitate regression testing. The old API will
get deprecated once all users have migrated.
-- Stefan^2.
On 28.01.2016 01:10, Johan Corveleyn wrote:
On Wed, Jan 27, 2016 at 1:54 PM, Stefan Fuhrmann wrote:
On 27.01.2016 13:08, Johan Corveleyn wrote:
Does this require a format bump (and another dump/load)? Or do you
plan on providing a way to "repack" (or simply unpack and pack
On 29.01.2016 22:35, Evgeny Kotkov wrote:
Stefan Fuhrmann writes:
This branch adds support for HTTP2-style transactions to all backends.
The feature is opt-in and supported in all 3 FS implementations.
I'd like to merge this to /trunk next weekend, so that e.g. Bert can
continue the wo
operty
handling only or all the remainder as well) and how much
code would that add to mod_dav_svn (50%?, more?, less?).
If the total addition is significantly smaller than mod_dav_svn,
maintaining it should be feasible after the first couple of
years of stabilization.
-- Stefan^2.
On Thu, Jan 28, 2016 at 12:01:07PM +0100, Bert Huijben wrote:
> > + /* Add postpone option. */
> > + option = apr_pcalloc(result_pool, sizeof(*option));
> > + option->id = svn_client_conflict_option_postpone;
> > + option->description = N_("skip this conflict and leave it unresolved");
>
> I t
On Wed, Jan 27, 2016 at 10:40:06PM -0600, William A Rowe Jr wrote:
> If you are new to the conversation, include/apr_cstr.h has absorbed much of
> the efforts of svn_cstring_* API's into apr_cstr_* functions.
I'm very happy to see our strtol()-wrappers in APR. These wrap the POSIX
functions with s
now.
(compare_is_dir): No longer needed.
(sort_reps): No longer distinguish between file and dir reps but only
paths and delta chains when determining reprentation order.
Hi Stefan,
In this post-1.9.x-branch commit (and a couple of subsequent
pack-related commits) you changed the
n
branch was created from) can be visible in the “Show Log” dialog
without dropping “Stop on copy/rename” checkbox and marked as normal
font color (unmerged revisions).
Thanks.
I take it you wanted to send this one to the tortoiseSVN mailing list
instead?
--
Regards,
Stefan Hett
On 25.01.2016 22:30, Stefan wrote:
Hi,
looking through the code, I'm wondering that there's some inconsistent
behavior/handling with regards to calling certain svn_utf-functions with a
nullptr.
svn_utf__cstring_is_valid() for instance does a nullptr check against the
provided data a
handling there.
Regards,
Stefan
sufficient to restore the originally intended
behavior?).
Regards,
Stefan
On 24.01.2016 00:53, Daniel Shahaf wrote:
Stefan Fuhrmann wrote on Sat, Jan 23, 2016 at 13:53:08 +0100:
Hi there,
This branch adds support for HTTP2-style transactions
to all backends. The feature is opt-in and supported
in all 3 FS implementations.
I'd like to merge this to /trunk
g the feature later should
be simple - in case we find a major problem with it.
Any objections?
-- Stefan^2.
be localized
id the user / admin cannot reasonable act on them.
Specifically, I suggest that all "data corrupted" error
messages become non-localized. If there is something
that a user can do about it (transient network failure),
higher levels should wrap the error appropriately.
-- Stefan^2.
On Thu, Jan 21, 2016 at 05:46:20PM +, Philip Martin wrote:
> Stefan Sperling writes:
>
> > Not objecting to this change, but I believe we do have a few
> > batons on the stack in several places and I don't think this
> > is a problem in general.
>
> It&#x
On Thu, Jan 21, 2016 at 02:18:43PM -, kot...@apache.org wrote:
> Author: kotkov
> Date: Thu Jan 21 14:18:43 2016
> New Revision: 1725957
>
> URL: http://svn.apache.org/viewvc?rev=1725957&view=rev
> Log:
> Allocate the baton for 'svn merge --accept' conflict callback in the pool,
> instead of u
On Thu, Jan 21, 2016 at 01:59:41PM +0100, Stefan Fuhrmann wrote:
> In real world applications this means people just
> hitting the old limit aren't likely to ever hit
> the new limit while those already far beyond it
> have fixed their config by now.
One would hope they'
On 21.01.2016 13:32, Stefan Sperling wrote:
On Thu, Jan 21, 2016 at 01:20:56PM +0100, Stefan Fuhrmann wrote:
TL;DR: Change is effective as per attached test case.
No crashes should ever result from it. Some 20% portion
of cache memory is guaranteed to work as before which
limits potential side
On Thu, Jan 21, 2016 at 01:20:56PM +0100, Stefan Fuhrmann wrote:
> TL;DR: Change is effective as per attached test case.
> No crashes should ever result from it. Some 20% portion
> of cache memory is guaranteed to work as before which
> limits potential side effects.
Sounds like thi
n
of cache memory is guaranteed to work as before which
limits potential side effects.
If you have specific questions, I'll be here to answer them.
-- Stefan^2.
What the patch does and doesn't do
--
The caching priority for directory objects is bein
enSSL 1.0.2e
- sqlite 3.9.2
Please note that MaxSVN is a development distribution and not intended
for production use!
MaxSVN homepage: http://www.luke1410.de/typo3/index.php?id=97
MaxSVN bugtracker: http://www.luke1410.de:8090/browse/MAXSVN
Regards,
Stefan
On Fri, Jan 15, 2016 at 04:48:28PM -, s...@apache.org wrote:
> Author: stsp
> Date: Fri Jan 15 16:48:27 2016
> New Revision: 1724855
>
> URL: http://svn.apache.org/viewvc?rev=1724855&view=rev
> Log:
> * subversion/libsvn_wc/conflicts.c
> (svn_wc_create_conflict_result): Initialise 'merged_va
On 13.01.2016 15:33, Evgeny Kotkov wrote:
Stefan Fuhrmann writes:
If I replace apr_palloc() with malloc() / free() and patch mod_dav to avoid
creating the propdb->p subpools, I still see inadequate memory consumption.
The environment is close to the one reported by the user, and preparin
On 30.12.2015 16:49, Evgeny Kotkov wrote:
Evgeny Kotkov writes:
Stefan Fuhrmann writes:
Thanks, it would be nice if could do something within Subversion because
httpd and apr patches may take a while to trickle down into releases.
Meanwhile, I posted a patch for mod_dav on the httpd dev
On 04.01.2016 17:20, Philip Martin wrote:
Stefan Fuhrmann writes:
On 04.01.2016 14:25, Philip Martin wrote:
- The number of system calls made by Apache goes down
68822 to 50664 for hot FSFS cache
Do you have quick way to find out which files
we are reading in that case? My
On 09.01.2016 14:39, Ivan Zhakov wrote:
On 9 January 2016 at 03:48, Stefan Fuhrmann wrote:
Hi Ivan & interested parties,
Hi Stefan!
See my response inline.
* BRANCH-README: "The branch is NOT going to be merged to
trunk; I'm going to re-implement everything in trunk
s.
Below there is a list of questions that I had when
reviewing the first few commits. There are also sections
on what I have in mind and partly in code for the new API.
-- Stefan^2.
Questions / Feedback to fs-node-api as of r1723819
--
[Not comm
On 05.01.2016 15:56, Julian Foad wrote:
Ping!... Stefan H or Stefan F, is there anything further to report on
this issue?
I guess what you are asking is: Can this tool be used
on production data? My answer is: Yes, but it is and
will always be an expert tool.
The 'analyse'
On 1/5/2016 15:56, Julian Foad wrote:
Ping!... Stefan H or Stefan F, is there anything further to report on
this issue?
I'll have to retest the current trunk against the test case to check out
the current state. Quite busy atm though, so donno if I can squeeze it
in this week. Will do t
quick way to find out which files
we are reading in that case? My guess would
be a fair bit of revprops during the report
phase but for the GETs, its less obvious.
178885 to 161722 for cold FSFS cache
-- Stefan^2.
ring literal.
Yep, you are right.
Turns out that the whole code path was (almost) a duplication
of a function that does not have this problem. Fixed in r1722860.
A related problem was then found by our SOLARIS build bot and
got fixed in r1722879 and r1722887.
Thanks for the detailed report!
-- Stefan^2.
On 21.12.2015 15:54, Evgeny Kotkov wrote:
Stefan Fuhrmann writes:
[...]
... in that order. The root problem is that
^/httpd/httpd/trunk/modules/dav/main/props.c: dav_close_propdb
does not destroy the pool created in dav_open_propdb.
Since that is being called for every directory
On 11.12.2015 15:04, Stefan Sperling wrote:
On Thu, Dec 10, 2015 at 01:41:40PM +0100, Stefan Fuhrmann wrote:
0x4015 is basically an "abort". We do this when we need
more memory but can't get it.
9000 directory entries is around the capacity of the default
cache configuratio
On Thu, Dec 17, 2015 at 02:28:44PM +, Julian Foad wrote:
> On 17 December 2015 at 14:14, Stefan Sperling wrote:
> > So I think we'll need some automated support for finding moves.
> > It doesn't need to be perfect, though.
>
> Yes, that's all correct: t
On Thu, Dec 17, 2015 at 12:34:46PM +, Julian Foad wrote:
> I mean that if the user doesn't explicitly specify any moves, then it
> will match by path only, which will result in behaviour similar to
> today. If the user specifies one or more 'moves', those will override
> the path matching for t
schedule-metadata-removal(path)
else
schedule-deletion(path)
else
if missing(path)
schedule-install(path)
run-workqueue
My 2¢; I'm not a working copy expert.
-- Stefan^2.
On Tue, Dec 08, 2015 at 11:47:46AM +0300, Evgeny Kotkov wrote:
> The 1.9.3 release artifacts are now available for testing/signing.
> Please get the tarballs from
> https://dist.apache.org/repos/dist/dev/subversion
> and add your signatures there. I plan to try and release on December 15th
> so
On Sat, Dec 12, 2015 at 08:59:33PM +0100, Fabien wrote:
>
> Hello Stefan.
>
> >Your script looks very nice! This definitely saves many people some
> >work in writing their own checks.
> >
> >We're trying to retire the contrib/ directory, since there are seve
On Sat, Dec 12, 2015 at 10:26:52AM +0100, Fabien wrote:
>
> Hello svn-dev,
>
> I've developped a while back a configurable pre-commit script which we have
> been using in production on several repositories for some years, see:
>
> http://www.coelho.net/svn-pre-commit.html
>
> I would be w
ash function.
Furthermore, it is up to the APR project to keep their
API documentation in sync with the code such that users
won't jump through hoops needlessly.
-- Stefan^2.
On 09.12.2015 18:25, Branko Čibej wrote:
On 09.12.2015 15:13, Stefan Fuhrmann wrote:
On 09.12.2015 13:39, Stefan Fuhrmann wrote:
On 08.12.2015 09:47, Evgeny Kotkov wrote:
The 1.8.15 release artifacts are now available for testing/signing.
Please get the tarballs from
https
On 08.12.2015 09:47, Evgeny Kotkov wrote:
The 1.8.15 release artifacts are now available for testing/signing.
Please get the tarballs from
https://dist.apache.org/repos/dist/dev/subversion
and add your signatures there. I plan to try and release on December 15th
so please try and get your vot
On 09.12.2015 13:39, Stefan Fuhrmann wrote:
On 08.12.2015 09:47, Evgeny Kotkov wrote:
The 1.8.15 release artifacts are now available for testing/signing.
Please get the tarballs from
https://dist.apache.org/repos/dist/dev/subversion
and add your signatures there. I plan to try and release
votes/signatures in place by December 14th.
Thanks!
I see JAVAHL test failure on Ubuntu 15.10.
-- Stefan^2.
[[[
$ make check-javahl
checking javahl ...
if [ "LD_LIBRARY_PATH" = "DYLD_LIBRARY_PATH" ]; then for d in
/run/shm/dist/subversion-1.8.15/subversion/
On 08.12.2015 09:47, Evgeny Kotkov wrote:
The 1.9.3 release artifacts are now available for testing/signing.
Please get the tarballs from
https://dist.apache.org/repos/dist/dev/subversion
and add your signatures there. I plan to try and release on December 15th
so please try and get your vote
On Mon, Nov 30, 2015 at 02:02:26PM -, rhuij...@apache.org wrote:
> Author: rhuijben
> Date: Mon Nov 30 14:02:26 2015
> New Revision: 1717253
>
> URL: http://svn.apache.org/viewvc?rev=1717253&view=rev
> Log:
> On the ra-git branch: To avoid having to reimplement quite a bit of the repos
> layer
On 11/27/2015 2:48 PM, Bert Huijben wrote:
-Original Message-
From: Stefan Hett [mailto:ste...@egosoft.com]
Sent: vrijdag 27 november 2015 13:47
To: dev@subversion.apache.org
Cc: users
Subject: Re: svn cleanup error "svn: E720032: Can't remove '...\.svn\tmp\svn-
...
ue (aka: a VS keeping the reference
and preventing SmartSVN to release it)?
--
Regards,
Stefan Hett
ss.
Yup that should be improved. Done in r1716779.
-- Stefan^2.
On Fri, Nov 13, 2015 at 11:30:59AM +, Philip Martin wrote:
> Johan Corveleyn writes:
>
> > I'm still very much wondering how this will fit in with the general
> > direction of Subversion ... but as you say, that's something we need
> > to work out together. That, for me, is currently the bigg
On trunk, people may feel more inclined to review and
adjust those points of interaction.
Any objections?
Once the cleanup is done, +1 on merge.
-- Stefan^2.
On 26.10.2015 17:45, Evgeny Kotkov wrote:
Stefan Fuhrmann writes:
As for /trunk, I think that we could do that, so I sketched this option in
the attached patch.
The patch looks o.k.
Thanks for giving this patch a look.
I examined the differences between these functions
On Wed, Oct 21, 2015 at 2:21 PM, Evgeny Kotkov
wrote:
> Stefan Fuhrmann writes:
>
> > Could you at least use the new API in svn_repos__compare_files instead
> > of re-implementing parts of the FS back-end but worse? I know this is
> > the code as it has been in 1.8 but t
ludes
> > cache settings, for instance.
>
> Shouldn't it read that setting from the config that we created a few lines
> above?
>
Nope, those are different things (but easily confused).
The thing copied by maybe_install_fs_conf is fs*.conf.
Its contents will always be read and used by fs_open.
The fs_config hash represents the server / UI parameters
(cache settings in particular).
-- Stefan^2.
On Tue, Oct 20, 2015 at 11:35 AM, Ivan Zhakov wrote:
> On 20 October 2015 at 12:23, Stefan Fuhrmann
> wrote:
> > On Mon, Oct 19, 2015 at 6:22 PM, Ivan Zhakov wrote:
> >>
> >> On 7 October 2015 at 18:10, Julian Foad wrote:
> >> > Stefan
the FS back-end but worse?
I know this is the code as it has been in 1.8 but that does not
make the it any better.
-- Stefan^2.
On Mon, Oct 19, 2015 at 6:22 PM, Ivan Zhakov wrote:
> On 7 October 2015 at 18:10, Julian Foad wrote:
> > Stefan Fuhrmann wrote:
> >> Julian Foad wrote:
> >>> Stefan: First review comment: You can much more efficiently convert a
> >>> stringbuf to a
tty safe. If this patch series
introduced a problem then it is one of the read queries in lib_repos
not returning the latest data when they should. And those invocations
are easy to review.
-- Stefan^2.
> *From:* Stefan Fuhrmann [mailto:stefan.fuhrm...@wandisco.com]
> *Sent:* zondag 11 okto
ff
> > ==
> >
> > --- subversion/trunk/subversion/libsvn_repos/rev_hunt.c (original)
> > +++ subversion/trunk/subversion/libsvn_repos/rev_hunt.c Sun Oct 11
> > 17:11:27 2015
> > @@ -171,7 +171,8 @@ svn_repos_get_committed_info(svn_revnum_
> >SVN_ERR(svn_fs_node_created_rev(committed_rev, root, path, pool));
> >
> >/* Get the revision properties of this revision. */
> > - SVN_ERR(svn_fs_revision_proplist(&revprops, fs, *committed_rev,
> pool));
> > + SVN_ERR(svn_fs_revision_proplist2(&revprops, fs, *committed_rev,
> > FALSE,
> > +pool, pool));
>
> Same here... also documented in your log message to use latest, while it
> now uses cached.
>
I just went through yesterday's patch set, checked the
parameter values and found a few more instances.
Bad commit day, apparently.
Thanks for reviewing!
-- Stefan^2.
tion or even
> hardware access.
>
OTOH, the UUID generation is not time-critical.
It will only happen if a repos layer operation
explicitly allows cached revprops and then it
will only happen once for the whole e.g. report.
-- Stefan^2.
>
> Bert
> --
>
implement the new behavior in FSFS
* bump FS API
* update lib_repos queries one-by-one for review and testability
* implement the new behavior in FSX
-- Stefan^2.
On Thu, Oct 8, 2015 at 1:07 PM, Evgeny Kotkov
wrote:
> Stefan Fuhrmann writes:
>
> > This is not about performance, it is about API guarantees and functional
> > stability. So, yes that is an optimization in the sense of "making it
> better
> > than before&qu
mour and reading a few bits of spec doesn't make me an NFS expert, I'm
afraid.
Maybe link to the SQLite FAQ about this:
https://www.sqlite.org/faq.html#q5
See the second paragraph under that FAQ entry.
I'd say if SQLite does not recommend storing the db file on NFS,
Subversion should do the same and not recommend storing working copies
on NFS.
Stefan
On Wed, Oct 7, 2015 at 3:21 PM, Julian Foad wrote:
> >>> Julian Foad wrote:
> >>>> [...] I will be
> >>>> interested in reviewing the (single) implementation.
>
> Stefan wrote:
> > [...] Here the final version.
> > If that doesn
On Wed, Oct 7, 2015 at 3:02 PM, Ivan Zhakov wrote:
> On 7 October 2015 at 15:57, Stefan Fuhrmann
> wrote:
> > On Wed, Oct 7, 2015 at 2:47 PM, Julian Foad
> wrote:
> >>
> >> Stefan wrote:
> >> > I guess the correct way of doing this is revert Ivan
On Wed, Oct 7, 2015 at 2:57 PM, Stefan Fuhrmann <
stefan.fuhrm...@wandisco.com> wrote:
> On Wed, Oct 7, 2015 at 2:47 PM, Julian Foad wrote:
>
>> Stefan wrote:
>> > I guess the correct way of doing this is revert Ivan's
>> > change and apply somethi
On Wed, Oct 7, 2015 at 2:47 PM, Julian Foad wrote:
> Stefan wrote:
> > I guess the correct way of doing this is revert Ivan's
> > change and apply something like the attached patch.
> Ivan wrote:
> > Here is the patch that I wanted commit later. What do you thin
1001 - 1100 of 5045 matches
Mail list logo
