Remove py2 support from mailer.py?

Hey all, I am proposing to remove py2 support from mailer.py. It is an anchor on some of the coding options within the module. I would suggest installations requiring py2 for mailer.py "just don't upgrade". This tool is not part of our core distribution, and I would further note that py2 was

Re: svn commit: r1914679 - /subversion/trunk/tools/hook-scripts/mailer/mailer.py

On Fri, Dec 15, 2023 at 4:51 AM Yasuhito FUTATSUKI wrote: > Hi, > > On 2023/12/15 18:44, gst...@apache.org wrote: > > Author: gstein > > Date: Fri Dec 15 09:44:03 2023 > > New Revision: 1914679 > > > > URL: http://svn.apache.org/viewvc?rev=1914679=rev > > Log: > > class DifflibDiffContent does

Re: Python 3 compatibility issue in tools/hook-scripts/mailer/mailer.py

Oh, shoot. And I was trying to be incremental/careful. Thank you for catching that! I also like how you fixed this. The .run() method did need to be removed because of that singular usage. Using the new generate_diff() function is a great solution! (whereas we used to have an object, which made

Re: Deleting /tools/dev/iz/

I'm with Mark on this one: whack it. With prejudice :-) On Fri, Nov 3, 2023 at 7:18 AM Mark Phippard wrote: > On Fri, Nov 3, 2023 at 8:15 AM Daniel Sahlberg > wrote: > > > > Hi, > > > > I don't know about the policy for deleting unmaintained / no longer > relevant code, so I'm asking here

Re: mailer.py

On Fri, Oct 13, 2023 at 10:35 AM Stefan Sperling wrote: > On Fri, Oct 13, 2023 at 12:42:27AM -0500, Greg Stein wrote: > >... > I have only seen cases where mailer.py is invoked with its command line > via a hook script. > Great situational feedback. Thx. > And I would

mailer.py

Hey all, So I'm looking at incorporating a couple key svn-mailer (by Andre Malo) features into mailer.py. Specifically, the body-length limit and mail encoding, and in turn deferring to viewvc links to replace what would be large emails. The py3 work was done by stsp and futatuki, so I ask them

Re: svn commit: r1896611 - /subversion/site/staging/mailing-lists.html

On Tue, Jan 4, 2022 at 7:02 AM Daniel Sahlberg wrote: >... > I think this is a case of too much removed context replying to the e-mails. > > My comment "I'm not fond of using yet another external service." was > related to using marc.info as new source of message search. > Gotcha. Yes, going

Re: svn commit: r1896611 - /subversion/site/staging/mailing-lists.html

On Tue, Jan 4, 2022 at 7:58 PM Daniel Shahaf wrote: > Greg Stein wrote on Tue, Jan 04, 2022 at 06:31:16 -0600: > > On Mon, Jan 3, 2022 at 2:18 AM Daniel Sahlberg < > daniel.l.sahlb...@gmail.com> > > wrote: > > > Den mån 3 jan. 2022 kl 06:27 skrev Daniel S

Re: svn commit: r1896611 - /subversion/site/staging/mailing-lists.html

On Mon, Jan 3, 2022 at 2:18 AM Daniel Sahlberg wrote: > Den mån 3 jan. 2022 kl 06:27 skrev Daniel Shahaf : > >... > I don't see the problem. We point folks on users@ to git/hg if those >> suit their needs better, so what's stopping us from pointing our users >> to an external list archive? >>

Re: Download page

On Tue, Dec 28, 2021 at 2:08 PM Daniel Sahlberg wrote: > Den tis 28 dec. 2021 kl 20:06 skrev Nathan Hartman < > hartman.nat...@gmail.com>: > >> On Tue, Dec 28, 2021 at 11:16 AM Daniel Sahlberg >> wrote: >> > >... > > Do you see different mirrors as primary and backup? For me both are the >>

Re: Commit reviews' author statistics: bus factor issue?

On Wed, Apr 28, 2021 at 11:07 AM Johan Corveleyn wrote: > On Sun, Apr 25, 2021 at 4:44 PM Nathan Hartman > wrote: > > > > On Fri, Apr 23, 2021 at 9:40 AM Daniel Shahaf > wrote: > > > > > > Nathan Hartman wrote on Thu, 22 Apr 2021 21:41 +00:00: > > > > Not knowing whether / how many people have

strange error, file causes commit error

Hey all, This is a very strange error that we're seeing in Infra, on the ASF svn server. It appears that the presence of a particular file in a commit causes a failure. Please see: https://issues.apache.org/jira/browse/INFRA-21346 Does anybody have thoughts on this? I'm stumped. Thanks! Greg

Re: svn.haxx.se is going away

On Fri, Dec 25, 2020 at 11:17 AM Daniel Shahaf wrote: >... > > I'll figure out a way to have the mboxes downloadable. If I understand > > Google's documentation of robots.txt they don't care about robots.txt if > a > > specific URL is linked from somewhere indexable, they will index it > anyway.

Re: svn.haxx.se is going away

On Mon, Dec 21, 2020 at 4:03 AM Daniel Shahaf wrote: > Daniel Sahlberg wrote on Mon, 21 Dec 2020 08:55 +0100: > > Den fre 27 nov. 2020 kl 19:26 skrev Daniel Shahaf < > d...@daniel.shahaf.name>: > > > > > Sounds good. Nathan, Daniel Sahlberg — could you work with Infra on > > > getting the data

Re: svn.haxx.se is going away

On Fri, Nov 27, 2020 at 12:26 PM Daniel Shahaf wrote: > Greg Stein wrote on Wed, Nov 25, 2020 at 00:08:32 -0600: > > Hey Daniel, > > > > I think the best place for this content is on mbox-vm.a.o. That is where > we > > have our permanent list archives in mbox f

Re: svn.haxx.se is going away

On Wed, Nov 25, 2020 at 8:52 AM Daniel Sahlberg wrote: >... > As for the question in your other mail (the reply to Daniel Shahaf) > regarding the desire to keep the URLs. My initial question to Daniel > Stenberg was if they would consider CNAME:ing svn.haxx.se to my server > and he seemed ok

Re: svn.haxx.se is going away

nteer infra time to help sort through our backlog. (access to archival messages has generally been lower priority; volunteers welcome) No issues on the storage. It's all about servicing up a landing page for $oldHaxxLink. Cheers, Greg Stein Infrastructure Administrator, ASF

Re: svn.haxx.se is going away

?) Cheers, Greg Stein Infrastructure Administrator, ASF On Tue, Nov 24, 2020 at 7:04 PM Daniel Shahaf wrote: > Nathan Hartman wrote on Tue, 24 Nov 2020 21:27 +00:00: > > On Tue, Nov 24, 2020 at 2:56 AM Daniel Sahlberg > > wrote: > > > Den tors 12 nov. 2020 kl 17:

Re: Nightly builds not getting auto-purged

On Mon, Jul 13, 2020 at 8:49 AM Daniel Shahaf wrote: >... > Also, why seven? I'd rather keep as many builds as needed to go back > I just threw out a number, to start the conversation. > to before the branching point of the latest stable release. It's not > going to be that much disk space,

Re: Nightly builds not getting auto-purged

On Mon, Jul 13, 2020 at 6:34 AM Mark Phippard wrote: > [ sigh; now I sent it unfinished ] > > On Jul 13, 2020, at 7:31 AM, Mark Phippard wrote: > > On Jul 13, 2020, at 7:28 AM, Greg Stein wrote: > > [sigh; sent unfinished] > > On Mon, Jul 13, 2020 at 6:19 AM Greg

Re: Nightly builds not getting auto-purged

[sigh; sent unfinished] On Mon, Jul 13, 2020 at 6:19 AM Greg Stein wrote: > Hey all, > > Not sure who is keeping an eye on the buildbot config, but Infra has been > looking at the buildmaster and found that we (svn) have about 14G of > nightlies laying around since 201

Nightly builds not getting auto-purged

Hey all, Not sure who is keeping an eye on the buildbot config, but Infra has been looking at the buildmaster and found that we (svn) have about 14G of nightlies laying around since 2015 (!!)

Re: Lists history (was: Re: commit failed due to "backwards-sliding source views" - what do I do?)

Hey Daniel, et al, Sorry to leave this hanging. I've been thinking on the best approach, but I do not have answer just yet. My initial thinking is that we are going to decommission mail-*.apache.org, so any solution basically means: backfill on lists.a.o. That is going to require some

Re: utf8proc required

On Wed, Dec 4, 2019 at 11:38 PM Nathan Hartman wrote: > On Wed, Dec 4, 2019 at 12:28 AM Greg Stein wrote: > > On Tue, Dec 3, 2019 at 10:41 PM Nathan Hartman > wrote: > >> I'd prefer to put utf8proc toward the top of "Dependencies in Detail" > >> because

Re: utf8proc required

On Tue, Dec 3, 2019 at 10:41 PM Nathan Hartman wrote: > On Tue, Dec 3, 2019 at 5:15 PM Greg Stein wrote: > > I was setting up a new chromebook, with a completely barren Ubuntu > install (using ChromeOS linux beta feature). utf8proc was not installed, > and the c

Re: svn commit: r1870772 - /subversion/trunk/build/ac-macros/utf8proc.m4

Thanks, Daniel. I didn't realize that option existed, when I hit my failure. The LZ4 stuff was documented to use --with-lz4=internal, so I went that route. On Tue, Dec 3, 2019 at 5:31 PM wrote: > Author: danielsh > Date: Tue Dec 3 23:31:42 2019 > New Revision: 1870772 > > URL:

Re: svn commit: r1864256 - /subversion/site/tools/upcoming.py

On Tue, Aug 6, 2019 at 9:41 AM Daniel Shahaf wrote: > Greg Stein wrote on Tue, 06 Aug 2019 07:58 +00:00: > > On Fri, Aug 2, 2019 at 12:53 PM wrote: > > >... > > > +++ subversion/site/tools/upcoming.py Fri Aug 2 17:53:38 2019 > > >... > > > +

Re: svn commit: r1864256 - /subversion/site/tools/upcoming.py

On Fri, Aug 2, 2019 at 12:53 PM wrote: >... > +++ subversion/site/tools/upcoming.py Fri Aug 2 17:53:38 2019 > >... > +def get_reference_version(): > +"Return the version to use as the oldest end of the 'svn log' output > to generate." > +def _is_working_copy(): > +return

Re: Subversion 2.0

On Tue, Jun 25, 2019 at 6:18 PM Nathan Hartman wrote: > On Tue, Jun 25, 2019 at 5:34 PM Branko Čibej wrote: > >On 25.06.2019 19:16, Thomas Singer wrote: > >>> I don't want to rain on anyone's parade but here's some food for > >>> thought. The only valid reason to call anything 2.0 is if, and

Re: Crazy idea: changes in WC should share an API with changes in repository

On Fri, Nov 9, 2018 at 4:56 AM Julian Foad wrote: >... > Is this such a crazy idea? > Not at all. This is what Ev2 was supposed to do. Part of my work around that was to start shifting code from the old delta-editor to Ev2. We have shims already available to support that work. I'd suggest

Re: [PATCH] svn/conflict-callbacks.c indentation fix

On Fri, Nov 2, 2018 at 5:08 AM Stefan Sperling wrote: > On Fri, Nov 02, 2018 at 10:49:23AM +0100, Branko Čibej wrote: > > On 02.11.2018 10:44, Stefan Sperling wrote: > > > I confirm that your patch is correct. I mis-indented these blocks. > > > > Time to start using a real editor, I guess? :) >

Re: is translate.a.o used?

Coolio, thanks for the info, Andreas. On Sun, Oct 7, 2018, 04:21 Andreas Stieger wrote: > Hi Greg, > > On 10/7/18 5:57 AM, Greg Stein wrote: > > I'm curious whether translate.apache.org <http://translate.apache.org> > > is being used (for the de.po file). The

is translate.a.o used?

, would that be Bad? We're currently debating its use and maintenance, and the Subversion community's input is welcome. Thanks, Greg Stein Infrastructure Administrator, ASF

Re: Using APR pools "better"

On Wed, Sep 26, 2018 at 10:20 AM Daniel Shahaf wrote: > Jim Jagielski wrote on Wed, 26 Sep 2018 11:09 -0400: > > At ApacheCon's welcoming event last night, Greg, Sander and I were > > chatting and Greg reminded us that the Subversion project "learned a lot > > about using APR pools" and it seems

Re: API review for 1.11; do we need to mark new APIs as experimental?

On Sat, Sep 15, 2018 at 8:48 AM Greg Stein wrote: >... > No no no... I agree with Brane above. It is confusing, and if people > mistakenly mix/match releases things will Just Break. Mysteriously. And > horribly. And possibly data-destructively. > To clarify the above a bit: Cons

Re: API review for 1.11; do we need to mark new APIs as experimental?

On Thu, Sep 13, 2018 at 10:24 AM Branko Čibej wrote: > On 13.09.2018 17:11, Julian Foad wrote: > > Julian Foad wrote: > >> [...] Are we saying now > >> that they need not be specifically marked if we feel they are pretty > >> safe? If we say that, then marking specific APIs as "experimental" in

Re: thoughts about shelving

On Sat, Sep 15, 2018 at 4:03 AM Julian Foad wrote: >... > > * when users update to the new version, existing shelves can't be used > > anymore since they're not compatible. Is there a way to convert the old > > shelves to the new format? If not then that means users would lose those > > saved

Re: svn commit: r1825449 - /subversion/site/staging/docs/release-notes/1.10.html

On Tue, Feb 27, 2018 at 10:37 AM, Daniel Shahaf wrote: > gst...@apache.org wrote on Tue, 27 Feb 2018 13:46 +: > >... > > -The default filesystem format is now a new format, numbered 8. The > format > > +The default filesystem format has been upgraded to version 8.

Re: svn commit: r1825449 - /subversion/site/staging/docs/release-notes/1.10.html

Thanks! I will tweak, then merge, later, when I get back to laptop. On Feb 27, 2018 10:37, "Daniel Shahaf" wrote: > gst...@apache.org wrote on Tue, 27 Feb 2018 13:46 +: > > Author: gstein > > Welcome back! > > > Date: Tue Feb 27 13:46:48 2018 > > New Revision:

Re: svn commit: r1825449 - /subversion/site/staging/docs/release-notes/1.10.html

Is /staging/ not actually used, contrary to the README? ... I've seen some recent mods directly to publish, but (given my general, recent absence) followed the README and just modified /staging/. Should I just merge this mod to publish, and stop using staging? On Tue, Feb 27, 2018 at 7:46 AM,

Re: [RFC] Upgrade to C'90 as our minimum C language

On Sun, Oct 1, 2017 at 4:17 AM, Stefan Fuhrmann wrote: > > > On 24.09.2017 23:03, Branko Čibej wrote: > >> On 24.09.2017 22:05, Daniel Shahaf wrote: >> >>> Branko Čibej wrote on Sun, 24 Sep 2017 21:56 +0200: >>> >> >... > *for*-scope variable declarations, that'd make some

Re: [PATCH] shared-only build for libsvn_auth_ and apache modules

On Wed, Jul 19, 2017 at 5:16 PM, Philip Martin wrote: > Philip Martin writes: > > > but perhaps some Makefile magic to disable all the static auth provider > > builds would be better. > > The way to do this is to pass the libtool argument

RAT builds

Hey all, I've been working with Gavin to restore Subversion's RAT buildbot. It was disabled a couple years back due to flakiness. We're gonna try and resuscitate the thing, or more precisely: use it as a guinea pig for some new ASF-wide RAT support. If you see something fall over (and it seems

Re: Files with identical SHA1 breaks the repo

I really like this idea. And we could take a copy of APR's sha1 code, and rejigger it to perform *both* hashes during the same scan of the raw bytes. I would expect the time taken to extend by (say) 1.1X rather than a full 2X. The inner loop might cost a bit more, but we'd only scan the bytes

Re: svn commit: r1784336 - /subversion/trunk/tools/hook-scripts/reject-known-sha1-collisions.sh

On Fri, Feb 24, 2017 at 3:29 PM, wrote: >... > +++ subversion/trunk/tools/hook-scripts/reject-known-sha1-collisions.sh > Fri Feb 24 21:29:04 2017 > >... > +$SVNLOOK changed -t "$TXN" "$REPOS" > +if [ $? -ne 0 ]; then > + echo $FILES >&2 > + echo "svnlook failed, possible

Re: buildbot failure in on svn-warnings

With the move off of hemera, we're missing packages. I'm working on that, along with a few changes to the svn-warnings buildbot code (simplifying, so far). On Tue, Nov 29, 2016 at 7:45 PM, wrote: > The Buildbot has detected a new failure on builder svn-warnings while >

Re: Fwd: hemera Buildbot Slave being turned off end of month

On Sun, Nov 27, 2016 at 12:28 PM, Daniel Shahaf <d...@daniel.shahaf.name> wrote: > Greg Stein wrote on Sun, Nov 27, 2016 at 10:48:27 -0600: > > Do we need to reconfig something to select another buildslave? > > Yes. See my previous reply to the dev@svn part of this thr

repeated failed builds

Looks like our nightly has been failing for weeks: https://ci.apache.org/builders/svn-trunk-nightly Something to do with fetching swig. Anybody have insights on this? Cheers, -g

Fwd: hemera Buildbot Slave being turned off end of month

I see some of our buildbot jobs running hemera. I've got no idea how buildbot works. Do we need to reconfig something to select another buildslave? I'm guessing the jobs won't just self-migrate to a new bot? -- Forwarded message -- From: Gavin McDonald

Re: Migrating our wiki

On Thu, Nov 3, 2016 at 12:59 PM, Johan Corveleyn wrote: >... > > Filed the ticket: > > https://issues.apache.org/jira/browse/INFRA-12818 (MoinMoin wiki > extremely slow) > > This issue has turned out very well. Infra has worked its magic, and > our MoinMoin wiki is fast again!

Re: backport.pl now running on svn-qavm3

On Fri, Oct 7, 2016 at 11:34 AM, Daniel Shahaf wrote: > Johan Corveleyn wrote on Fri, Oct 07, 2016 at 16:59:50 +0200: > > Just a quick heads-up that our backport script (performing our > > automatic backport merges based on STATUS) is now running (nightly > > cron job) on

Re: MacOS buildbot?

On Sun, Sep 4, 2016 at 2:44 PM, Lieven Govaerts <l...@mobsol.be> wrote: > On Sat, Sep 3, 2016 at 9:55 PM, Greg Stein <gst...@gmail.com> wrote: > >> Hey all, >> >> Who owns/runs our MacOS buildbots? AOO is seeking a build server. It's a >> big build, so mi

Re: MacOS buildbot?

Thanks, Branko! On Sat, Sep 3, 2016 at 3:26 PM, Branko Čibej <br...@apache.org> wrote: > On 03.09.2016 21:55, Greg Stein wrote: > > Hey all, > > > > Who owns/runs our MacOS buildbots? AOO is seeking a build server. It's > > a big build, so might not be possi

MacOS buildbot?

Hey all, Who owns/runs our MacOS buildbots? AOO is seeking a build server. It's a big build, so might not be possible to sit next to the svn builds, and I don't know how often they want to run it (eg. buildbot, or just to compile executables for release) Thanks, -g

Re: ABI changes analysis

On Tue, Jul 5, 2016 at 6:36 AM, Ponomarenko Andrey < andrewponomare...@yandex.ru> wrote: > 28.06.2016, 03:04, "Greg Stein": > > On Sat, Jun 25, 2016 at 11:28 AM, Daniel Shahaf wrote: > > Greg Stein wrote on Sat, Jun 25, 2016 at 07:29:11 -0500: > > I've re

Re: ABI changes analysis

On Sat, Jun 25, 2016 at 11:28 AM, Daniel Shahaf <d...@daniel.shahaf.name> wrote: > Greg Stein wrote on Sat, Jun 25, 2016 at 07:29:11 -0500: > > I've reviewed the reports, and it looks like we've maintained all our ABI > > guarantees. The changes are what I would expe

Re: ABI changes analysis

On Mon, Jun 27, 2016 at 6:54 AM, Greg Stein <gst...@gmail.com> wrote: > > On Sun, Jun 26, 2016 at 7:49 PM, Stefan <luke1...@posteo.de> wrote: > >... > >> And now I also remember and realize that these removed symbols were >> actually private ones nev

Re: ABI changes analysis

On Sun, Jun 26, 2016 at 7:49 PM, Stefan wrote: >... > And now I also remember and realize that these removed symbols were > actually private ones never intended to be exported (aka: double _ in > the name). So 1.8/1.9 corrected this and ABI compatibility for these > were

Re: ABI changes analysis

This is freakin' HOT. Very nice work! I've reviewed the reports, and it looks like we've maintained all our ABI guarantees. The changes are what I would expect. Thank you for this! Cheers, -g On Sat, Jun 25, 2016 at 12:45 AM, Ponomarenko Andrey < andrewponomare...@yandex.ru> wrote: > Hello,

Re: svn commit: r1735826 - in /subversion/trunk: ./ subversion/libsvn_subr/prompt.c

I see your commit has returned :-/ On Mon, Apr 4, 2016 at 6:06 AM, Daniel Shahaf <danie...@apache.org> wrote: > Greg Stein wrote on Sat, Apr 02, 2016 at 00:23:12 -0500: > > On Fri, Apr 1, 2016 at 5:18 AM, Stefan Sperling <s...@elego.de> wrote: > > > > > On F

Re: svn commit: r1735826 - in /subversion/trunk: ./ subversion/libsvn_subr/prompt.c

On Fri, Apr 1, 2016 at 10:02 PM, Daniel Shahaf <danie...@apache.org> wrote: > Greg Stein wrote on Fri, Apr 01, 2016 at 04:38:00 -0500: > > On Fri, Apr 1, 2016 at 12:36 AM, Daniel <danie...@apache.org> wrote: > > > > > ... > > > However, if

Re: svn commit: r1735826 - in /subversion/trunk: ./ subversion/libsvn_subr/prompt.c

On Fri, Apr 1, 2016 at 5:18 AM, Stefan Sperling <s...@elego.de> wrote: > 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

Re: svn commit: r1735826 - in /subversion/trunk: ./ subversion/libsvn_subr/prompt.c

On Fri, Apr 1, 2016 at 12:36 AM, Daniel wrote: > ... > However, if we make this change, API callers that depend on the > implemented (unpromised) behaviour — that is, API callers that assume > the output parameter will be initialized even on error returns — will > then

Re: Merging parallel-put to /trunk

On Thu, Feb 11, 2016 at 6:40 AM, Evgeny Kotkov wrote: >... > >> As far as I know, squashing everything into a single POST would make > >> the commit up to 10-20 times faster, depending on the amount of > changes. > > > > Pfft. > > I attached a dirty patch

Re: Making FS and repos layer log API streamy

On Wed, Feb 3, 2016 at 6:36 AM, Ivan Zhakov wrote: >... > Also I think we should not use callbacks to deliver data from the FS > layer. Currently FS API is passive and I think it should remain the > same: FS API users may invoke FS function from callback and this will >

Re: Merging parallel-put to /trunk

On Fri, Feb 5, 2016 at 3:27 AM, Evgeny Kotkov wrote: >... > (1) Why do we start with adding a quite complex FS feature, given that we > don't know what kind of problems are associated with implementing this > in ra_serf? > Please do not deny a new

Re: Making FS and repos layer log API streamy

Very cool work! On Sun, Jan 31, 2016 at 5:03 AM, 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

Re: svncutter can be removed

On Tue, Feb 2, 2016 at 7:45 PM, Eric S. Raymond <e...@thyrsus.com> wrote: > Greg Stein <gst...@gmail.com>: > > But I'll take care of it for you, no worries. I'll rm the content, and > > leave a README pointing to reposurgeon. > > Thanks. > > > Much apprec

Re: svncutter can be removed

A year or three back, the Infra team had everybody reset their passwords. I see you have an ASF account, so it is likely just a need to reset the thing. But I'll take care of it for you, no worries. I'll rm the content, and leave a README pointing to reposurgeon. Much appreciated for the prior

Re: svncutter can be removed

Done: http://svn.apache.org/r1728244 On Tue, Feb 2, 2016 at 7:28 PM, Greg Stein <gst...@gmail.com> wrote: > A year or three back, the Infra team had everybody reset their passwords. > I see you have an ASF account, so it is likely just a need to reset the > thing. > &g

Re: svncutter can be removed

Excellent. Thanks for the detailed information. It sounds like you've filled in lots of edge details. On Tue, Feb 2, 2016 at 9:43 PM, Eric S. Raymond <e...@thyrsus.com> wrote: > Greg Stein <gst...@gmail.com>: > > Gotcha. How is that different from "svndumpfilter i

Re: Last-Modified HTTP header in GET responses

Personally, I'd be more interested in the effects on the network and its caching ability. Do we really need to save CPU/IO on the server? Today's servers seem more than capable, and are there really svn servers out in the wild getting so crushed, that this is important? It seems that as long as

votes? [HISTORY HELP?]

Hey all, There have been a few occasions when I've noted to others how our community has *avoided* voting. For FIFTEEN years. We took a vote on whitespace issues because consensus wasn't clear. That ended up with "no space before paren". But it seems we took a vote on something else. But I

Re: Running SVN 1.9.x on ASF servers?

With all that being said, I suspect you would not want us to deploy 1.9 > onto a single host (US) leaving the EU slave where it is now? > > > Tony > > > > > On Tue, 1 Dec 2015, at 08:45 PM, Greg Stein wrote: > > We've *always* been willing to help. > > Note the

Re: Running SVN 1.9.x on ASF servers?

> Will you expect us to roll dav_svn et al each time too? If so we should > ensure that your package names match those upstream in Ubuntu ( I assume > James can cope with that, given his email address ;) ). > > > On Sun, 29 Nov 2015, at 10:00 PM, Greg Stein wrote: > > Does this

Re: svn+ssh long-lived daemon

When svnserve first landed in svn, it was sold as a "simple" mechanism to allow people to use their existing SSH setup, rather than moving to Apache/TLS. I expressed my fear that svnserve was going to grow features, until one day it looked just like httpd. And yes... it has grown many, many

Re: svn commit: r1713980 [4/6] - in /subversion/branches/move-tracking-2/subversion: include/private/ libsvn_client/ libsvn_delta/ libsvn_ra/ libsvn_ra_local/ libsvn_repos/ libsvn_wc/ svnmover/

h I did catch a couple of other such cases. Will fix. > > - Julian > > On 12 November 2015 at 16:54, Greg Stein <gst...@gmail.com> wrote: > > On Thu, Nov 12, 2015 at 2:59 AM, <julianf...@apache.org> wrote: > >>... > >> > >> +++ subversion/branches

Re: Merge 'svnmover' demo tool to trunk

On Thu, Nov 12, 2015 at 4:37 PM, Julian Foad <julianf...@apache.org> wrote: > On 12 November 2015 at 17:11, Greg Stein <gst...@gmail.com> wrote: > > On Thu, Nov 12, 2015 at 4:44 AM, Julian Foad <julianf...@apache.org> > wrote: > >> I want to bring this to

Re: Merge 'svnmover' demo tool to trunk

On Thu, Nov 12, 2015 at 4:44 AM, Julian Foad wrote: >... > I want to bring this to trunk because I can't do this on my own. I > think it's the number one most important thing that Subversion needs, > and so I passionately want to make it work in some way. I have done a >

Re: svn commit: r1713980 [4/6] - in /subversion/branches/move-tracking-2/subversion: include/private/ libsvn_client/ libsvn_delta/ libsvn_ra/ libsvn_ra_local/ libsvn_repos/ libsvn_wc/ svnmover/

On Thu, Nov 12, 2015 at 2:59 AM, wrote: >... > +++ subversion/branches/move-tracking-2/subversion/libsvn_ra/ra_loader.c > Thu Nov 12 08:59:57 2015 > @@ -679,8 +679,8 @@ write_rev_prop(svn_ra_session_t *ra_sess > * branch-tracking metadata from the repository into it. >

Re: Merge 'svnmover' demo tool to trunk

On Thu, Nov 12, 2015 at 4:44 AM, Julian Foad wrote: >... > 'svnmover' is a program for helping developers to understand and try > out some concepts that I think are helpful. It is not intended to be > useful for end-users, and I hadn't even thought about releasing it. As >

Re: Running SVN 1.9.x on ASF servers?

On Sat, Oct 10, 2015 at 3:14 AM, Tony Stevenson wrote: >... > I am happy to continue this thread if you want to ask more questions. But > the 'it must be a package' - 'from a repo we trust' - 'all changes managed > by puppet' are firm policies that we will not shift from. >

Re: Migrating Subversion issues to ...

On Thu, Sep 17, 2015 at 7:18 AM, Mark Phippard wrote: > On Thu, Sep 17, 2015 at 3:31 AM, Branko Čibej wrote: > >... > And I wonder why the people who're doing the least work on this >> migration have the most to say about not wasting time with

Re: Migrating Subversion issues to ...

On Thu, Sep 17, 2015 at 9:20 PM, Branko Čibej wrote: >... > mantra and this sudden urgency to migrate the issue tracker yesterday. If > we waited for 5 years we may as well wait the couple extra days to get the > details right. > Or, in a couple days, Ivan departs the

Re: Migrating Subversion issues to ...

That is just not true, Bert. Subversion uses "IssueZilla" which is a CollabNet derivation of Bugzilla. On Wed, Sep 16, 2015 at 6:07 AM, Bert Huijben wrote: > Just noting: The issue tracker we used on tigris is based on Scarab, not > on bugzilla. > > So we are not converting

Re: Migrating Subversion issues to ...

Well, the noformat in the test import looks just fine. It works, may as well leave that. ... But end the work there. I'm with Mark: having the issues in JIRA is *way* more important than further refinements and the time involved. On Wed, Sep 16, 2015 at 8:00 AM, Mark Phippard

Re: Migrating Subversion issues to ...

Could I offer an opinion: the time stamps DO NOT MATTER. If a comment was posted at 15:00 or at 21:00 ... I don't care. If it was a Monday or a Tuesday ... I don't care. I believe I'd rather stick a fork in my eye, than ask somebody to spend even 5 minutes on timestamps. Cheers, -g On Wed, Sep

Re: Query on Subversion's use of Neon WebDAV library - mixing of Apache and LGPL libraries

On Tue, Sep 15, 2015 at 2:29 AM, Stefan wrote: > Hi, > > Hi, > > > > I'm working on a hobby application & I'd to use WebDAV. > > > > I've read Lisa Dusseault's WebDAV book and this pointed me in the > direction of Neon, which in turn pointed me in the direction of SVN which >

Re: Migrating Subversion issues to ...

ormation. If > you are not the intended recipient (or have received this e-mail in error) > please notify the sender immediately and destroy this e-mail. Any > unauthorised copying, disclosure or distribution of the material in this > e-mail is strictly forbidden.* > > *

Re: Migrating Subversion issues to ...

On Tue, Sep 15, 2015 at 5:12 AM, Ivan Zhakov wrote: > On 15 September 2015 at 11:59, Bert Huijben wrote: > >... > > I think we really have 3 options: > > > > [ ] Keep our issues on Tigris > > [ ] Migrate our issues to a new Bugzilla instance hosted by ASF

Re: Migrating Subversion issues to ...

On Tue, Sep 15, 2015 at 6:34 AM, Stefan Hett <ste...@egosoft.com> wrote: > On 9/15/2015 12:49 PM, Greg Stein wrote: > > On Tue, Sep 15, 2015 at 5:12 AM, Ivan Zhakov <i...@visualsvn.com> wrote: > >> On 15 September 2015 at 11:59, Bert Huijben < <b...

Re: 1.9.1 wrong sha1 sums on website

On Tue, Sep 15, 2015 at 10:11:47AM +, Grierson, David wrote: > > From: wolfgang.zt...@web.de [mailto:wolfgang.zt...@web.de] > > > > http://subversion.apache.org/download.cgi#supported-releases: > > subversion-1.9.1.tar.bz2 2ba78f59b3669e461ef6f56326426918100e2073 > > > > but sha1sum

Re: Migrating Subversion issues to ...

On Tue, Sep 15, 2015 at 6:37 AM, Greg Stein <gst...@gmail.com> wrote: > On Tue, Sep 15, 2015 at 6:34 AM, Stefan Hett <ste...@egosoft.com> wrote: > >> On 9/15/2015 12:49 PM, Greg Stein wrote: >> >> On Tue, Sep 15, 2015 at 5:12 AM, Ivan Zhakov <i...@visualsvn.

Re: Review of sizeof usage

On Tue, Aug 11, 2015 at 2:55 PM, Branko Čibej br...@wandisco.com wrote: On 11.08.2015 17:02, Philip Martin wrote: Stefan Fuhrmann stefan.fuhrm...@wandisco.com writes: way we use sizeof. In my opinion, we should take the size of the created or processed variable instead of its type,

Re: The patch-exec branch

On Fri, Jul 31, 2015 at 6:36 PM, Daniel Shahaf d...@daniel.shahaf.name wrote: ... Two questions: - When one side of the diff is in the OS filesystem, do we still fold its value to 644/755 for output? - If yes, how do we choose between 644 and 755? (e.g., do we use x 0111 == 0111, or

Re: svn commit: r1674628 - /subversion/branches/1.9.x/STATUS

On Sun, Apr 19, 2015 at 11:40 AM, Branko Čibej br...@wandisco.com wrote: On 19.04.2015 10:57, Bert Huijben wrote: Why do you set the header if you can just set the parsed depth value even more locally as I did in my patch I sent as reply on the thread? The patch Greg and Stefan cooked up

Re: svn commit: r1674628 - /subversion/branches/1.9.x/STATUS

Windows Mail *From:* Greg Stein gst...@gmail.com *Sent:* ‎Sunday‎, ‎April‎ ‎19‎, ‎2015 ‎7‎:‎27‎ ‎PM *To:* dev@subversion.apache.org On Sun, Apr 19, 2015 at 11:40 AM, Branko Čibej br...@wandisco.com wrote: On 19.04.2015 10:57, Bert Huijben wrote: Why do you set the header if you can just

Re: branching over mod_dav 2.4.6 is O(tree)

On Sat, Apr 4, 2015 at 4:48 PM, Ben Reser b...@reser.org wrote: ... Lock Token: The client does not have to provide a mapping of the paths to the tokens that must match what the server has. Rather it must simply provide all the tokens attached to the active locks. So the server has to find

Re: Copyright year displayed by command-line tools

hehe... I think it is time to kill that off, with extreme prejudice :-D On Fri, Mar 20, 2015 at 5:35 AM, Branko Čibej br...@wandisco.com wrote: On 20.03.2015 11:07, Greg Stein wrote: On Fri, Mar 20, 2015 at 4:28 AM, Branko Čibej br...@wandisco.com mailto:br...@wandisco.com wrote

Re: Copyright year displayed by command-line tools

Let me expand on that a bit ... let's not hold any releases for this, but let's talk to Danny and other peeps at the ASF. I believe we can clear out a few lines. Pointing to subversion.a.o is nice. We should be able to scorch the other 3 lines. On Fri, Mar 20, 2015 at 5:43 AM, Greg Stein gst

  1   2   3   4   5   6   7   8   9   10   >