On Thu, Feb 11, 2021, 14:36 Private List Moderation <
mod-priv...@gsuite.cloud.apache.org> wrote:
> On Thu, 11 Feb 2021 at 12:15, Branko Čibej wrote:
>
>> On 11.02.2021 12:23, Stefan Sperling wrote:
>>
>> On Thu, Feb 11, 2021 at 11:02:32AM +, Private List Moderation wrote:
>>
>> Irrelevant.
>
How can a link be more important than an announcement for a fix of an
*unauthenticated* remote DoS ?
Same for the KEYS file???
Don't you think that's way out of proportion?
Erik.
On Wed, Feb 10, 2021 at 4:50 PM Private List Moderation
wrote:
>
> I don't see how the missing links can be regard
>
> By the way, I'm not sure why we carry around the "defined(__OS2__)"
> check in io.c. As far as I'm aware, no-one has ever actually tested
> Subversion on OS/2 ... these checks are probably just lifted out of APR,
> but don't do anything useful.
>
Maybe not tested, but there are supposedly floa
> > Hi Mark,
> >
> > I'm going to start migration process tomorrow morning. Could you
> > please lock tigris.org project? I think it will ok if our issue
> > tracker will read-only for day or something.
> >
> >
> Issues are finally migrated to ASF JIRA:
> https://issues.apache.org/jira/browse/SVN
>
> > Heh :-) I meant the branch-specific code -- not *all* of the client and
> > library! I have no idea what that means, because I didn't study the code
> > closely (yet). I'll need some directions on where to look for the
> > branch-specific code so I can try to figure out where to hook Lua in.
>
> > Am I right that if we were to run this experiment with the
> > move-tracking-2 branch code, that the entire client and library would
> > be subject to conversion to the higher level language?
>
> No! That would be literally years of rewriting and debugging and
> re-testing, not to mention inter
> > @Julian, do you have a specific area of our code that would most benefit
> > from "moving 'up' from C"? Preferably some part of code that's currently
> > very much in flux?
>
> 'svnmover' on the 'move-tracking-2' branch. It includes both 'client'
> and 'library' code, and I'm moving code freely
> Hence my suggestion for Lua, which doesn't have a GIL, as far as I can
>> find. Nor does it need manual reference-keeping like is needed with Python
>> or Perl. With Lua you can have as many evaluation environments as you want.
>> Instantiating them when crossing a certain API boundary to be used
> > These days, I suppose we'd be looking at something like Go, which can
> > be linked with C/C++ and also natively export functions that can be
> > called from C/C++.
>
> As far as I can see, Go always comes with Garbage Collection instead of a
> deterministic memory management.
>
> Also, as far
> In the past I'd thought about embedding Python into our sources, but
> Python still (after 20 years ...) depends on a global interpreter lock
> which pretty much kills any chance of lockless thread-safe code.
>
Hence my suggestion for Lua, which doesn't have a GIL, as far as I can
find. Nor doe
> > It would make sense to design type-safe, light-weight container and
> > iterator template wrappers around the APR structures if we decided to
> > write code in C++. Since we're not, "explicit is better than
> > implicit".
>
> I understand the point. I note that "explicit" is not a binary qualit
Hi kay,
On Thu, Feb 12, 2015 at 5:48 PM, kay wrote:
> Just to clarify the "support security" was a typo. I meant they thought BDB
> will have better features for user authentication, privacy, permission and
> security issues.
Well, then I think your customer, or you, don't get Branko's "There'
Hi Neels,
Would it be an idea to switch the baseline of the tests to 1.8.1? I
regularly look at them, but got confused with the reported performance gain.
Just to let you know :-)
Erik.
sent from my phone
On Jul 29, 2013 2:38 AM, wrote:
> 1.7.0@1181106 vs. trunk@1507860
> Started at Mon Jul 2
One application has multiple active code page settings on Windows. Or
course if your example was the only option, we would not be having this
discussion.
Bye,
Erik.
sent from my phone
On May 23, 2013 6:44 PM, "Dongsheng Song" wrote:
> On Thu, May 23, 2013 at 11:38 PM, Erik Hue
Found at least one of the related discussions:
http://svn.haxx.se/dev/archive-2004-05/0078.shtml
bye,
Erik.
On May 23, 2013 5:38 PM, "Erik Huelsmann" wrote:
>
> > >
> > >> I think the best solution is: DO NOTconvert the GETTEXT(3) returned
> > >>
> >
> >> I think the best solution is: DO NOTconvert the GETTEXT(3) returned
> >> messages, write it ***AS IS***, since GETTEXT(3) already do the
> >> correct conversion for us.
> >
> > Well, even though gettext may want us to believe otherwise, this doesn't
> > work for cross platform application
sent from my phone
On May 23, 2013 4:43 PM, "Dongsheng Song" wrote:
>
> On Thu, May 23, 2013 at 10:06 PM, Philip Martin
> wrote:
> > Dongsheng Song writes:
> >
> >> On Thu, May 23, 2013 at 9:28 PM, Philip Martin
> >> wrote:
> >>> Dongsheng Song writes:
> >>>
> On Thu, May 23, 2013 at 9:11
Hi Ash,
Thanks for picking up the initiative to implement this feature.
On Thu, Mar 22, 2012 at 7:01 PM, Ivan Zhakov wrote:
> On Thu, Mar 22, 2012 at 18:30, Daniel Shahaf wrote:
> > OK, I've had a cruise through now.
> >
> > First of all I have to say it's an order of magnitude larger than wha
Forwarding my response back to the list...
-- Forwarded message --
From: Erik Huelsmann
Date: Mon, Mar 12, 2012 at 4:14 PM
Subject: Re: Compressed Pristines
To: Johan Corveleyn
Hi Johan,
> Has nothing to do with the property. The pristine matches the repository,
> >
On Thu, Feb 2, 2012 at 10:59 PM, Hiroaki Nakamura wrote:
> 2012/2/3 Peter Samuelson :
>>
>>> On 02.02.2012 20:22, Peter Samuelson wrote:
>>> > By proposing a client-only solution, I hope to avoid _all_ those
>>> > questions.
>>
>> [Branko Cibej]
>>> Can't see how that works, unless you either make
> Given that httpd is avoiding setlocale() we're pretty much left without
> locale support in mod_dav_svn.
Beware that you don't depend on setlocale() not having been called
though: at least one of the popular mod_ modules
*does* use setlocale(). (I think it was php5.)
Other than that: completely
Hi Hyrum,
On Thu, Jun 30, 2011 at 11:33 PM, Hyrum K Wright wrote:
> On Thu, Jun 30, 2011 at 3:27 PM, Peter Samuelson wrote:
> >
> > [Ivan Zhakov]
> >> It should be easy to implement editing revprops without using SQLite:
> >> in case someone modify revprop non-packed revprop file is created, in
Hi Arwin,
On Tue, Jun 21, 2011 at 9:45 AM, Arwin Arni wrote:
> 3. Will this feature be considered at all (if it is any good) or am I simply
> doing something to exercise my brain cells?
Actually, I think it'd be a good idea to have a standardized command
to have where all clients work alike.
W
One of my after-hours activities is to help maintain a community
hosting site for Common Lisp development.
During our latest system migration, I noticed that mod_dav_svn acts
weird in view of symlinks:
If you check http://svn.common-lisp.net/, the repository listing page
is empty. However, if you
On Sat, Feb 5, 2011 at 8:25 PM, Mark Phippard wrote:
> On Sat, Feb 5, 2011 at 1:05 PM, Erik Huelsmann wrote:
>
>> Scenario (2) takes ~0.27 seconds to evaluate in the unmodified
>> database. Adding an index on (wc_id, local_relpath) makes the
>> execution time d
Now attached as text files (to be renamed to .py) to prevent the
mailer software from dropping them...
Bye,
Erik.
On Sat, Feb 5, 2011 at 7:05 PM, Erik Huelsmann wrote:
> Yesterday or IRC, Bert, Philip and I were chatting about our SQLite
> perf issues and how Philip's findings
Yesterday or IRC, Bert, Philip and I were chatting about our SQLite
perf issues and how Philip's findings in the past suggested that
SQLite wasn't using its indices to optimize our queries.
After searching and discussing its documentation, Philip suggested the
-too obvious- "maybe we have the wron
Hi Hyrum,
On Wed, Oct 27, 2010 at 11:34 PM, Hyrum K. Wright
wrote:
> On Wed, Oct 27, 2010 at 3:40 PM, wrote:
>> Author: stefan2
>> Date: Wed Oct 27 20:40:53 2010
>> New Revision: 1028092
>>
>> URL: http://svn.apache.org/viewvc?rev=1028092&view=rev
>> Log:
>> Incorporate feedback I got on r98560
>> - if (! replaced && status == svn_wc__db_status_added
>> + if (reverted
>> + && ! replaced
>> + && status == svn_wc__db_status_added
>> && db_kind == svn_wc__db_kind_dir)
>> {
>> - /* Non-replacements have their admin area deleted. wc-1.0 */
>> + /* Non-replaced
Hi Stefan,
I see you're not on irc, so you may have missed it: This commit, or
the next, turned the buildslaves red.
Bye,
Erik.
On Thu, Oct 21, 2010 at 9:07 PM, wrote:
> Author: stsp
> Date: Thu Oct 21 19:07:54 2010
> New Revision: 1026105
>
> URL: http://svn.apache.org/viewvc?rev=1026105&vi
Last week, I greatly simplified our 'revert' code. However, in the
process, I changed the notifications from 'revert' too:
The old code would send notifications for all modified nodes
(including tree modifications), with a single exception: it would send
a notification only for the root in case of
>> - cold cache: 1.7 is almost 50% faster than 1.6
>> 1.7: 22s
>> 1.6: 42s
>>
>> - hot cache: 1.7 is just about on par with 1.6 (only 20% slower)
>> 1.7: 0.86s
>> 1.6: 0.72s
>>
>
> What do you guys mean by "cold cache" and "hot cache"? If they mean what I
> think they mean, wouldn't "hot cache" be
As Julian pointed out, I'm working on making 'revert' work with our
NODES table in the layered design situation. As part of that work, I
was studying the current behaviour of revert: supposedly, that's what
the behaviour of the new revert should look like in simple cases.
However, one of the thing
On Wed, Oct 6, 2010 at 1:12 PM, Julian Foad wrote:
> On Wed, 2010-10-06 at 09:32 +0100, Philip Martin wrote:
>> I'd like to enable NODES as a replacement for BASE_NODE and
>> WORKING_NODE. This would involve bumping the format number, and old
>> working copies would get automatically upgraded.
>
On Wed, Sep 22, 2010 at 11:25 PM, Greg Stein wrote:
> On Wed, Sep 22, 2010 at 05:39, wrote:
> >...
> > +++ subversion/trunk/subversion/libsvn_wc/wc-queries.sql Wed Sep 22
> 09:39:45 2010
> > @@ -215,7 +215,7 @@ update nodes set properties = ?3
> > where wc_id = ?1 and local_relpath = ?2
> >
Sorry to have left the discussion running so long without contributing to it
myself. The reason I started about changing the repository / fs is because
it is where we store the dataset that we'll need to support forever: working
copies get destroyed and checked out over and over every hour, every d
Hi Greg,
On Thu, Sep 16, 2010 at 10:47 PM, Erik Huelsmann wrote:
>
>
> On Thu, Sep 16, 2010 at 10:40 PM, Philip Martin <
> philip.mar...@wandisco.com> wrote:
>
>> Erik Huelsmann writes:
>>
>> > We're now back to a single failure. It's in t
On Thu, Sep 16, 2010 at 10:40 PM, Philip Martin
wrote:
> Erik Huelsmann writes:
>
> > We're now back to a single failure. It's in the relocation-verification
> code
> > in db-test.c (line 1505). With the half-hour I've spent so far, I wasn't
> >
Hi Philip,
On Thu, Sep 16, 2010 at 10:07 PM, wrote:
> Author: ehu
> Date: Thu Sep 16 20:07:27 2010
> New Revision: 997905
>
> URL: http://svn.apache.org/viewvc?rev=997905&view=rev
> Log:
> Fix one of two remaining SVN_WC__NODES failures (manifesting itself twice).
>
> * subversion/tests/libsvn_
called the issue the "Erik Huelsmann issue" yesterday :-)
The issue consists of two parts:
1. The repository which should determine that paths being added by a commit
are unique, regardless of their encoding (NFC/NFD)
2. The client which should detect that the pathnames coming in from the
Julian,
This commit should remove the test failures you were experiencing on trunk
with SVN_WC__NODES. At least that should give you confidence that if you see
failures, you probably introduced them with local changes :-)
Bye,
Erik.
-- Forwarded message --
From:
Date: Mon, Se
Today, I finished replacing all NODE_DATA queries (UPDATE/DELETE/INSERT) in
wc_db.c by queries which operate on NODES. From here on, I'll start to write
code to query BASE_NODE+NODES and WORKING_NODE+NODES, verifying that both
tables return the same results.
There are however, a few queries in 'en
In r992993 the NODES table design was added. The SVN_WC__NODES conditional
was created to enable known-working code for this schema. The NODES
conditional will be used to flag sections which need to be further looked
into for modification, just as with SINGLE_DB and NODE_DATA.
It would be my idea
On Mon, Sep 6, 2010 at 11:35 AM, Bert Huijben wrote:
>
> > + SVN_ERR(svn_sqlite__get_statement(&stmt, pdh->wcroot->sdb,
> > +STMT_INSERT_NODE_DATA));
> > +
> > + SVN_ERR(svn_sqlite__bindf(stmt, "isi", pdh->wcroot->wc_id, base,
> > +
it's not done today, then I expect it
to be able to finish it this week.
Anyone wanting to join in: let's chat on IRC.
Bye,
Erik.
On Thu, Sep 2, 2010 at 11:34 PM, Erik Huelsmann wrote:
>
>
> As described by Julian earlier this month, Julian, Philip and I observed
> that
As described by Julian earlier this month, Julian, Philip and I observed
that the BASE_NODE, WORKING_NODE and NODE_DATA tables have many fields in
common. Notably, by introducing the NODE_DATA table, most fields from
BASE_NODE and WORKING_NODE already moved to a common table.
The remaining fields
>>
>> Modified:
>> subversion/trunk/subversion/libsvn_wc/wc-queries.sql
>> subversion/trunk/subversion/libsvn_wc/wc_db.c
>
> Your log message doesn't describe any changes in wc_db.c
Prop-edited now. Thanks.
Bye,
Erik.
After lots of discussion regarding the way NODE_DATA/4th tree should
be working, I'm now ready to post a summary of the progress. In my
last e-mail (http://svn.haxx.se/dev/archive-2010-07/0262.shtml) I
stated why we need this; this post is about the conclusion of what
needs to happen. Also included
>> * moved_here
>> * moved_to
On IRC, we were discussing the fact that these columns are in the
databases, but nobody seems to be planning to implement them for 1.7.
Is that your perception too? If so, we could remove them with the
upcoming schema-change required for NODE_DATA.
Bye,
Erik.
On Sun, Jul 11, 2010 at 1:04 AM, Greg Stein wrote:
> On Sat, Jul 10, 2010 at 17:55, Erik Huelsmann wrote:
>>...
>> Columns to be placed in NODE_DATA:
>>
>> * wc_id
>> * local_relpath
>> * oproot_distance
>> * presence
>> * kind
>&g
As announced by gstein before, we've had some discussion on the
NODE_DATA structure which should allow storing multiple levels of tree
manipulation in our wc-db. This mail aims at describing my progress on
the subject so far. Please review and comment.
Introduction
What's the 4t
On Wed, Jun 30, 2010 at 10:13 PM, Daniel Shahaf wrote:
> [ trim CC ]
>
> Mark Mielke wrote on Wed, 30 Jun 2010 at 21:37 -:
>> On 06/30/2010 05:57 AM, michael.fe...@evonik.com wrote:
>> > P.S. Thanks for the warning; we are not going to use 1.7.
>
> Did you check what is the probability of dyin
Hi Philip,
On Mon, Apr 12, 2010 at 3:14 PM, Philipp Marek
wrote:
> Hello Bert!
>
> On Montag, 12. April 2010, Bert Huijben wrote:
>> Well, on Windows consoles are all 80 characters wide. (You can fix this if
>> you are a frequent Command Prompt User, but most applications just assume
>> 80 chara
hi Phil,
On Mon, Apr 12, 2010 at 7:54 AM, Philipp Marek
wrote:
> Hello Johan,
> hello Stefan,
>
> On Freitag, 9. April 2010, Stefan Sperling wrote:
>> On Fri, Apr 09, 2010 at 10:17:12PM +0200, Johan Corveleyn wrote:
>> > So I guess this is coming up for you guys when s.a.o reaches the 1
>> > mill
Dear Karthik,
How about libsvn_ra_svn? (Which is an implementation of libsvn_ra.)
http://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_ra_svn/
libsvn_ra is available here:
http://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_ra/
And the headers with documentation -
55 matches
Mail list logo
