Remove py2 support from mailer.py?

[Greg Stein]

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 EOL'd in January 2020. I do not believe that Apache Subversion
should support versions of Python that no longer receive updates (security,
or otherwise).

No rush on this, and no need for +1 responses ... I'm interested in people
saying "keep py2 support" and the rationale. I'll give it a week before
declaring consensus for removal, if there is no counter-argument.

Thanks!
-g

ps. to be clear: the ASF *does not* use mailer.py today (we use Andre
Malo's svnmailer). We intend to switch to the py3 version of mailer.py in
the near future. I am adding features that the ASF needs (eg. around "don't
send over-large commit emails")

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

[Greg Stein]

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 not work, and maybe never did. There is
> > no .next() method on the unified_diff() result object. While it would
> > be possible to use the next() function, it is better to just remove
> > this entirely and require the host OS to have a diff executable (not a
> > hard requirement).
>
> I don't want to make objection to removing DifflibDiffContent, but
> it seems it worked on Python 2, where generator object has next()
> method instead of .__next__() method. So it is a missed feature
> while porting Python 3.
>

We could probably use the next() builtin function (available in Py2 and
Py3).

But should we? Is there a platform without a diff executable? Maybe Windows?

I found this "use difflib" feature was added in 2010, in r1032568, with no
further work in the intervening years. How many people use this?

Consider: it didn't work in Py3. "All" unix-ish systems have "diff". So
we're talking about (maybe?) Windows-based svn administrators using Python
2.

Personally, I think it is safe to just omit this "feature", which is likely
unused today.

Cheers,
-g

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

[Greg Stein]

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 it unclear
on how to use it for this situation)

I've applied your patch in r1914729.

Thanks!
-g


On Sat, Dec 16, 2023 at 6:08 AM Yasuhito FUTATSUKI 
wrote:

> On 2023/12/11 12:54, Yasuhito FUTATSUKI wrote:
> > On 2023/12/10 4:22, Yasuhito FUTATSUKI wrote:
>
> >> Thank you for the review. However, it turned out that even with this
> >> patch, mailer.py did not work for post-revprop-change hook.
> >> It caused exception like
> >>
> >> [[[
> >> svn: E165001: post-revprop-change hook failed (exit code 1) with output:
> >> Traceback (most recent call last):
> >>   File
> "/home/futatuki/tmp/svn-test/mailer_test/repo-smtpoutput/hooks/mailer.py",
> line 1593, in 
> >> ret = svn.core.run_app(main, cmd, config_fname, repos_dir,
> >>   File "/usr/local/lib/python3.9/site-packages/svn/core.py", line 324,
> in run_app
> >> return func(application_pool, *args, **kw)
> >>   File
> "/home/futatuki/tmp/svn-test/mailer_test/repo-smtpoutput/hooks/mailer.py",
> line 148, in main
> >> return messenger.generate(output, pool)
> >>   File
> "/home/futatuki/tmp/svn-test/mailer_test/repo-smtpoutput/hooks/mailer.py",
> line 601, in generate
> >> output.run(self.cfg.get_diff_cmd(group, {
> >>   File
> "/home/futatuki/tmp/svn-test/mailer_test/repo-smtpoutput/hooks/mailer.py",
> line 224, in run
> >> self.write_binary(buf)
> >> AttributeError: 'SMTPOutput' object has no attribute 'write_binary'
> >> ]]]
>
> The cause was that Output.run() was broken by removal of
> Output.write_binary() on r1912978.
>
> Here is an ad hoc patch:
> [[[
> Fix PropChange.generate
>
> * tools/hook-scripts/mailer/mailer.py
>   (OutputBase.run): remove, because below was the only usage.
>   (PropChange.generate):
> use generate_diff() to render propchange diff instead of
> OutputBase.run()
>
> Index: tools/hook-scripts/mailer/mailer.py
> ===
> --- tools/hook-scripts/mailer/mailer.py (revision 1914700)
> +++ tools/hook-scripts/mailer/mailer.py (working copy)
> @@ -211,23 +211,7 @@
>  representation."""
>  raise NotImplementedError
>
> -  def run(self, cmd):
> -"""Override this method, if the default implementation is not
> sufficient.
> -Execute CMD, writing the stdout produced to the output
> representation."""
> -# By default we choose to incorporate child stderr into the output
> -pipe_ob = subprocess.Popen(cmd, stdout=subprocess.PIPE,
> -   stderr=subprocess.STDOUT,
> -   close_fds=sys.platform != "win32")
>
> -buf = pipe_ob.stdout.read(self._CHUNKSIZE)
> -while buf:
> -  self.write_binary(buf)
> -  buf = pipe_ob.stdout.read(self._CHUNKSIZE)
> -
> -# wait on the child so we don't end up with a billion zombies
> -pipe_ob.wait()
> -
> -
>  class MailedOutput(OutputBase):
>
>def start(self, subject_line, group, params):
> @@ -598,12 +582,13 @@
>tempfile2 = tempfile.NamedTemporaryFile()
>tempfile2.write(self.repos.get_rev_prop(self.propname,
> scratch_pool))
>tempfile2.flush()
> -  output.run(self.cfg.get_diff_cmd(group, {
> -'label_from' : 'old property value',
> -'label_to' : 'new property value',
> -'from' : tempfile1.name,
> -'to' : tempfile2.name,
> -}))
> +  for diffs in generate_diff(self.cfg.get_diff_cmd(group, {
> +  'label_from' : 'old property value',
> +  'label_to' : 'new property value',
> +  'from' : tempfile1.name,
> +  'to' : tempfile2.name,
> +  })):
> +  writer.write(to_str(diffs.raw))
>  output.finish()
>except MessageSendFailure:
>  ret = 1
> ]]]
>
> Cheers,
> --
> Yasuhito FUTATSUKI /
>

Re: Deleting /tools/dev/iz/

[Greg Stein]

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 first.
> >
> > /tools/dev/iz/ (
> https://svn.apache.org/repos/asf/subversion/trunk/tools/dev/iz/) seems to
> be a tool to extract issues statistics from IssueZilla (which I as far as I
> understand was a CollabNet(?) customised(?) BugZilla instance). Last
> relevant update was 2004, after that only Python3 and similar fixes.
> >
> > Since we don't use BugZilla anymore: Anyone against deleting
> tools/dev/iz/
> >
> > I think keeping old code for accessing old systems around will only
> cause additional work for someone to look at "do we need to update this
> code becaus of XX". If someone needs it, I heard someone mentioning version
> control :-)
>
> I do not recall this folder existing or what it does, but IssueZilla
> was the issue tracker we used when this project was hosted on
> tigris.org. Maybe it was something someone created to help migrate our
> issues to Apache?
>
> IssueZilla does not exist anymore. Agree it could be ditched.
>
> Mark
>

Re: mailer.py

[Greg Stein]

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 say if anyone reached into internals they will well be
> able to deal with updates that break things for them and adapt their
> code. It's not going to be a hugely complicated effort for them.
> We never promised such compatibility in the first place, as far as I know.
>

Ah! That is a great point. If they are "reaching in", then they can
compensate for the changes that we make. That makes me more comfortable
with structural/workflow changes.

Thank you!
-g

mailer.py

[Greg Stein]

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 specifically, and
the community in general: do we have any guarantees on *internal*
interfaces of the mailer.py script? Do we know of any users that import
that script and use its functions/classes? In other words, is there an
implied API to maintain guarantees for?

If the answer is "no", then I'd prefer to change the dataflow for rendering
and its write(_binary) mechanism.

Thoughts?

Cheers,
-g

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

[Greg Stein]

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 back and re-reading, I see that now.

Thx,
-g

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

[Greg Stein]

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 Shahaf <
> d...@daniel.shahaf.name>:
>
>...

> > >> 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?
> > >
> > DShahaf is very Right. There are a dozen third party services supporting
> > the Apache Subversion community. There really isn't a reason to fear this
> > one. Especially when the Foundation has a contractual relationship with
> > them.
>
> That's not what I said.  You might've been thinking of Daniel Gruno.
>

There are a lot of Daniels around, but you basically said that right above
in the part I quoted. "I don't see the problem. ..."

If you meant marc.info by "an external list archive" rather than lists.a.o,
then sure: your sentence reads quite differently :-)

[DSahlberg:]

> > > I'm just worried that we point someone to an external archive, start to
> > > accumulate a lot of links and suddenly the external party lose
> interest in
> > > maintaining the site and we end up in a situation where we have a lot
> of
> > > links that suddenly are 404. Similar to what happened to svn.haxx.se a
>
[me:]

> > Key difference: lists.apache.org compared to svn.haxx.se
> >
> > Should the Foundation ever terminate its agreement with the lists.a.o
> > service provider, we can provide redirection since we "own" the hostname
> > and can run a redirection service. Please don't worry about 404s. We have
> > spent the past couple years building redirection rules for
> > mail-archives.a.o, over to lists.a.o. Those are still being
> > tweaked/modified, as we speak. That same kind of effort will apply to any
> > lists.a.o turn-off, should it ever happen one day.
>
> Are lists.a.o permalinks permanent, as the name implies?


Yes.


> Even if they are, you're ignoring the points about lists.a.o requiring
> javascript and requiring being online to resolve links.  It's well


Not ignoring it. Just don't have an answer. (but I did re: lists.a.o
permanence)


> within this PMC's mandate to decide to use an archive whose links are
> resolvable offline (which entails usability and privacy wins) and
>

Of course. I'm trying to be helpful here, not antagonistic, Daniel.

Cheers,
-g

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

[Greg Stein]

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?
>>
>
DShahaf is very Right. There are a dozen third party services supporting
the Apache Subversion community. There really isn't a reason to fear this
one. Especially when the Foundation has a contractual relationship with
them.

I'm just worried that we point someone to an external archive, start to
> accumulate a lot of links and suddenly the external party lose interest in
> maintaining the site and we end up in a situation where we have a lot of
> links that suddenly are 404. Similar to what happened to svn.haxx.se a
>

Key difference: lists.apache.org compared to svn.haxx.se

Should the Foundation ever terminate its agreement with the lists.a.o
service provider, we can provide redirection since we "own" the hostname
and can run a redirection service. Please don't worry about 404s. We have
spent the past couple years building redirection rules for
mail-archives.a.o, over to lists.a.o. Those are still being
tweaked/modified, as we speak. That same kind of effort will apply to any
lists.a.o turn-off, should it ever happen one day.

Regards,
Greg
InfraAdmin, ASF; fellow svn

Re: Download page

[Greg Stein]

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
>> dlcdn. But I guess this could vary with location.
>>
>> Hmm both are showing dlcdn, except one is suffixed "(backup)". I
>> assumed there was a difference between these but didn't dig any deeper
>> on that.
>>
>
> I've started a thread in users@infra.a.o, but it seems that list is not
> public so I cannot link. But it seems that dlcdn.a.o is the only "mirror"
> right now, with downloads.a.o being the "backup" (but not a backup in the
> script).
>

dlcdn.a.o is served by the CDN, and is the new/current default. For
European users, they may also see downloads.a.o. The Foundation has a ton
of bandwidth and "no" data cap (just limited by bandwidth) on a server or
two in Europe. So we tend to direct people to downloads.a.o if it appears
they are in Europe, too.

ezt is indeed used by Subversion, by ViewVC, and a lot of Infra stuff. It's
a great/fast little template engine for Python. The Lua version is in that
infra-p6 directory you linked (visible to ASF committers). Please feel free
to create branches and PRs if you're gutsy enough to make any fixes. If
not, and there is an incompatibility, then open an INFRA ticket, please.

Cheers,
Greg
InfraAdmin, ASF; and fellow svn guy

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

[Greg Stein]

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 reviewed a particular
> > > > commit is, as was said elsewhere, a silent failure mode of the CTR
> > > > (commit-then-review) convention.
> > > >
> > > > Do we want to try switching to a RTC (review-then-commit) convention?
> > >
> > > If we do switch to RTC, we might want to also retroactively ensure all
> > > commits post 1.14.x's branching have been reviewed by at least two
> pairs
> > > of eyes each.
> > >
> > > However, I wonder whether there's a smaller change we can do first,
> > > rather than a full-blown s/CTR/RTC/ flag day.  For instance, how
> > > about we agree, for the next N weeks, to make our commit reviews
> > > explicit?  I.e., to explicitly say "I've reviewed this commit and
> > > found no issues"?  (Call this Commit-Then-Explicit-Review.)
> >
> > I'm +1 to this idea. It sounds to me like a reasonable middle ground
> > to gain some insights before making bigger workflow-altering changes.
>
> I'm doubtful that this will improve our bus factor for reviews, except
> perhaps by drawing in some more reviewer-attention by seeing more of
> it on the list.
>
> So far I'm mostly seeing reviews by DanielSh and Nathan. Switching
> from CTR to CTER (or to RTC) will not really change that. It might
>

Yeup. It's just rearranging deck chairs, rather than bringing in new
reviewers.

Let's also note that the analysis was regarding "re: svn commit". Meaning a
selected group of commits which were commented-upon. That completely leaves
out all of the totally awesome super-duper commits that I've made which
definitely don't need comments!  *wink*

I would posit there are quite a few commits that occur which simply don't
need review. And if you say "only these two guys are doing review", then
RTC implies that *all* commits are conditioned upon two people's attention.
I cannot see anything good coming out of that.

CTR is predicated on trust of our fellow committers. They will get it
right. Get them active, remove roadblocks, and carry the project forward.

CTR is also predicated on svn: we have version control! We can unwind
things that break.

With a mature project like svn, moving to RTC is just imposing additional
constraints upon our community, and (personally) I don't see the *benefit*.
Most commits do not need a review. That's because I (we?) trust our fellow
community members. Leave the 90% commits as they are: CTR.

-1 on any switch to RTC for trunk.

Cheers,
-g

strange error, file causes commit error

[Greg Stein]

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
InfraAdmin, ASF

Re: svn.haxx.se is going away

[Greg Stein]

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.
> > Maybe just make one big tarball of everything?
>
> One big tarball would be wasteful to consume (would have to download
> everything) and to produce (would need to, basically, «cp everything.tgz
> tmp.tgz; tar -zcf - $new >> tmp.tgz; mv tmp.tgz everything.tgz», and you
> can
> see that's O(#everything) rather than O(appended stuff)).  Would rather
> avoid
> it if possible.
>
> Not sure what to do about robots.  I suppose we could set  rel="canonical"> in the HTTP headers when serving the rfc822 files (example
> in )?
>

I thought robots.txt can exclude subdirs. So just cut off (say)
svn-haxx.apache.org/mbox/

I'm not too worried about Google crawling the mboxes, as they'll likely do
it just once and never again (by keeping the etag and/or mtime).

>...

> > I couldn't figure out puppet, the links was 404 for me. I've created a
> > request in Jira and I hope someone will take a look:
> > https://issues.apache.org/jira/browse/INFRA-21230
>
> I think the github repository is restricted to Apache committers only, so
> you'll need to enter your github username on id.apache.org in order to get
> access to that URL.  If you don't have a github account, there ought to be
> a mirror of the repository on *.apache.org somewhere (at least, if Infra's
> following the same policy PMCs do).
>

Correct: committers only. And only after linking accounts via
https://gitbox.apache.org/setup/ as Nathan noted (and we forgot to mention
to DSahlberg).

If you do not have a GitHub account, or do not want one (say, because you
don't want to accept their T), then you can use the repository via
gitbox.apache.org (ask on Slack for the link; I prefer not to post it here).

Cheers,
-g

Re: svn.haxx.se is going away

[Greg Stein]

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 over to ASF hardware?
> >
> > I have been given access to svn-qavm and uploaded a tarball of the
> website
> > (including mboxes). I'm a bit reluctant to unpack it since it takes
> almost
> > 7GB, and there is only 14 GB disk space remaining. Is it ok to unpack or
> > should we ask Infra for more disk space?
>
> I vote to ask for more disk space, especially considering that some
> percentage is reserved for uid=0's use.
>

DSahlberg hit up Infra on #asfinfra on the-asf.slack.com, and asked for
more space. That's been provisioned now.

>...

> > The mboxes will be preserved but I don't plan to make them available for
> > download (since they are not available from lists.a.o or
> mail-archives.a.o).
>
> Please do make them available for download.  Being able to download the
> raw data is useful for both backup and perusal purposes, and I doubt
> the bandwidth requirements would be a problem.  (Might want
> a robots.txt entry, though?)
>

Bandwidth should not be a problem for the mboxes, but yes: a robots.txt
would be nice. I think search engines spidering the static email pages
might be useful to the community, but the spiders really shouldn't need/use
the mboxes.

Regarding the behaviour of the existing archives, see
> 
> (which used to also be available via
> https://subversion.apache.org/mail/, but nowadays that just redirects
> to a landing page ☹).  I don't know whether lists.a.o has equivalent
> functionality, but then again, lists.a.o has had vendor lock-in baked
> into it from day one, so a lack of a "download raw rfc822 data" feature
> might simply be another form of that.
>

I don't know if our vendor for lists.a.o plans to do an mbox download. I
doubt they retain the data in that format. The Foundation has "all the
data", of course, going back to the mid-90s. An mbox download service might
be interesting, once we decommission the mod_mbox services.

>...

> > 1. Install a web server. nginx? (just kidding)
>
> Apache HTTP Server would probably be a better choice since more dev@svn
> and Infra people are familiar with it, but it's a fair question to ask.
> (Cf. INFRA-7524)
>

Infra has no position on that. Feel free to use nginx  ... but DShahaf is
correct: local support will be higher with apache httpd.

> 2. Setup httpd.conf
> > 3. Configure a DocumentRoot where I can put the files. Doesn't seem right
> > to store them in /home
>
> Hmm.  These things should all be done via puppet.  I'm not sure what's
> best practice nowadays regarding writing puppet PRs and testing them,
> though.


I think the first thing is to get httpd up and running with the desired
configuration. Then step two will be to memorialize that into puppet. Infra
can assist with the latter. I saw on Slack that Humbedooh gave you a link
to explore.

Cheers,
-g

Re: svn.haxx.se is going away

[Greg Stein]

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 format.
> > We can then arrange to ship them off to lists.a.o. If you concur,
>
> I concur in the sense that it'd be great to have the mboxes stored on
> and served by whatever Infra uses for all other archives.
>
> However, when I last looked at lists.a.o I was of the opinion that Infra
> shouldn't use it.  (Back then its permalinks weren't permanent and
> weren't able to be generated or dereferenced while the user was offline
> *or while the external vendor was offline*.  I don't know whether those
> have been fixed since then.)  Unless that has changed, I wouldn't like
> Subversion to rely on that particular archive.  Instead, there's
> mod_mbox, or a static snapshot of svn.haxx.se.
>

Infra has no plans to switch away from lists.a.o. The permalinks issue is
being solved for the oldest archives (we have a copy of the ElasticSearch
database holding them, so we don't have to rely on a .csv file). The
mail-archives.a.o and mail-private.a.o mod_mbox servers will be taken
offline at some point, and a redirector left in its place.

The Subversion community can stand up its own archive on svn-qavm, or rely
on lists.a.o and a redirector. Infra has no opinion on that.

(@Greg: You know I wouldn't normally have repeated the above, but
> (1) you asked, and (2) the dev@ audience doesn't all know this context.)
>

No worries at all.


> > then I'll ask the team to get you access.
>
> Would InfraAdmin let someone else from the PMC take point?  I realize
> that this is an ASF-wide box (as opposed to a PMC box) and I'm a known
> entity at Infra, but I'm short on tuits.
>

Anybody with an @apache account. Or if somebody emails me privately with a
path on svn-qavm.a.o for the content that I should mirror onto our mbox
storage machine. I can get that content moved over from svn-qavm maybe even
a bit more easily. (iirc, DShahaf and Nathan have copies on svn-qavm?)

> You can preserve all the data you want into your homedir, and we can
> > sort from there.
>
> Sounds good.  Nathan, Daniel Sahlberg — could you work with Infra on
> getting the data over to ASF hardware?
>
> Note that svn-org@ doesn't have an equivalent @s.a.o list, and that, as
> mentioned upthread, the post-migration (from tigris.org to apache.org)
> mboxes may be in a different order than the official ones, and shouldn't
> be "deduplicated".
>
> > You indicate a desire to maintain URLs. Do you have some ideas on that?
>
> Each individual message .shtml file contains the message-id in
> a comment.  We can extract the comments and build a redirector around
> them.  (By the way, this is basically the same exercise that Infra must
> have solved back when Sebb received that CSV file from the lists.a.o
> vendor, so there may be an opportunity for code reuse.)  Of course, the
> full rsync likely has the same info available less scrapily.
>
> Or, as mentioned above, the .shtml files could just be preserved
> statically (plus or minus an appropriate message in the list of years on
> the /${listname}/ page).  In fact, I'm having trouble coming up with
> a reason _not_ to serve a static snapshot of the pages, even if we do
> build a redirector.
>

svn-haxx.spache.org is live now. It is an A record pointing to
svn-qavm.a.o. (one day, it might be a CNAME, but for $reasons it is not,
today).

Thus, anybody can configure httpd on svn-qavm however you like, and have it
respond to svn.haxx.se and svn-haxx.apache.org. Whether redirects or a
static site, or ...

DSahlberg could do this if somebody on the PMC gives him a +1 to have an
account created (effectively as a partial committer, but with no
directories specified). Then he can sign/send an ICLA, and get an account.
That can be added to svn-qavm, where he could set up a site. Tho I'll warn
that root would be required for httpd configuration.

Medium/long-term I would suggest putting the httpd configuration into
Puppet once it is stable, so it will stick around across machine
(re)provisioning.

Feel free to ping me on Slack or via email. I read svn lists sporadically
nowadays, but am more than happy to represent both svn and infra.

Cheers,
-g

Re: svn.haxx.se is going away

[Greg Stein]

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 with that, however we have not reached a formal agreement.
> I assume it would be even easier for him to CNAME it to a server provided
> by the ASF.
>

I would suggest a CNAME to svn-haxx.apache.org, which Infra would further
CNAME to (say) svn-qavm. That would mean Mr Stenberg wouldn't ever need to
alter his CNAME record, while the ASF could repoint svn-haxx.a.o at-will
over time. Today, the "301 mapping server" could be svn-qavm, but maybe
we'd do something different in a few years.

Cheers,
-g

Re: svn.haxx.se is going away

[Greg Stein]

On Thu, Nov 12, 2020 at 10:47 AM Daniel Sahlberg <
daniel.l.sahlb...@gmail.com> wrote:

> Den tors 5 nov. 2020 kl 15:31 skrev Julian Foad :
>
>> Main point: Thanks to everyone helping this preservation effort.
>>
>> > * updating the 63+87 links in the site and source to point to links
>> hosted on ASF hardware
>> >
>> Observation: s/hardware/domain/. While the ASF has long promoted "on our
>> own hardware", the more critical and often under-valued key to keeping
>> control of one's Internet assets is "on our own domain name". That's
>> assumed in this context, but something to keep in mind elsewhere.
>>
>
> Agreeing with Julian's point on "on our own domain name", however this is
> as it is. If we can get an agreement regarding keeping svn.haxx.se
> pointing to a server where, at least, the old mailing list archive is
> available then we would be better off.
>
> Could ASF provide this server space (basically a VirtualHost)? The archive
> is about 6.5 GB so it is not a huge amount.
>

Well, svn-qavm.a.o already exists, and DShahaf has already moved content
there. I think the larger concern is if a "redirect mapping" server were
stood up to capture svn.haxx.se clicks and redirect them, then to ... where?

In INFRA-20213, we noted that mail-archives.a.o is going away. Our end goal
is lists.a.o, so that is where the content needs to be migrated.

We (Infra) have a lot of issues with loading archival data onto lists.a.o.
We have a bunch of it, there are permalink issues, and it is going to a
long slog. So there is also the issue for the svn community to determine
whether it wants to fill the gap or maybe throw in some volunteer 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

[Greg Stein]

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 format. We can then arrange to
ship them off to lists.a.o. If you concur, then I'll ask the team to get
you access. You can preserve all the data you want into your homedir, and
we can sort from there.

You indicate a desire to maintain URLs. Do you have some ideas on that?
Would we be able to have the DNS record for svn.haxx.se CNAME'd to one of
our boxes which simply generates 301 responses? (from your email, it
implies we don't have confirmation of that yet?)

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:46 skrev Daniel Sahlberg <
> daniel.l.sahlb...@gmail.com>:
> > >> Could ASF provide this server space (basically a VirtualHost)? The
> archive is about 6.5 GB so it is not a huge amount.
> > >
> > > Any thoughts on this?
> >
> > I am looking into this; waiting for a reply...
>
> In the circumstances — it's Nov 25 and the site says it'll be taken down
> "in November 2020", not specifying a date — I'd say, better ask
> forgiveness than permission.  Let's go ahead and grab all the data we
> need to stand up the site (we have the mboxes, but not the mapping of
> *.shtml files to message-id's, nor any of the HTML/CSS/images), and if
> possible, also set it up (on svn-qavm.a.o or wherever) to ensure we've
> got everything and to prepare for a DNS repointing, if Daniel agrees.
> We can figure out the "paperwork", Puppet PRs, etc., later.
>
> I'd say the highest priority is to save the mapping of .shtml URLs to
> message-id's (which are available as comments in the source HTML),
> whether via a recursive wget(1) invocation, or by asking Daniel to run
> an appropriate grep, or however else.  Without that info, we won't be
> able to preserve old URLs.
>
> Maybe there's also a button we can press to sic the archive.org spider
> on svn.haxx.se.
>
> (We can't derive the message<->.shtml mapping from the mboxes we have.
> I only grabbed mboxes through the transition to ASF; for anything after
> that point, the order of .shtml files would be the order in which list
> mails reached haxx.se's MX, and we have no backups of that info.)
>
> Cheers,
>
> Daniel
>
> P.S.  Yes, it's a bit https://m.xkcd.com/2337/ of me to refer to both
>   Daniel and Daniel as "Daniel". :)
>

Re: Nightly builds not getting auto-purged

[Greg Stein]

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, is it?  Assuming we discard .bz2 files
> to save some disk space ("Let them use gzip!"):
>
> 20MB/nightly * 1 nightly/month * 24 months[minor line release period] =
> 0.5GB
>

As I said: the space is likely not going to be an issue. The primary
question is "what do we want to retain?"


> (Don't know where your 50MB figure is from; on dist/ it's 25MB/release.)
>

$ ls -laF r1784492/
total 51276
drwxr-xr-x   2 buildmaster buildmaster 4096 Feb 27  2017 ./
drwxr-xr-x 293 buildmaster buildmaster12288 Feb 27  2017 ../
-rwxr-xr-x   1 buildmaster buildmaster 15559956 Feb 27  2017
subversion-nightly.tar.bz2*
-rwxr-xr-x   1 buildmaster buildmaster   40 Feb 27  2017
subversion-nightly.tar.bz2.sha1*
-rwxr-xr-x   1 buildmaster buildmaster 18534901 Feb 27  2017
subversion-nightly.tar.gz*
-rwxr-xr-x   1 buildmaster buildmaster   40 Feb 27  2017
subversion-nightly.tar.gz.sha1*
-rwxr-xr-x   1 buildmaster buildmaster 18360378 Feb 27  2017
subversion-nightly.zip*
-rwxr-xr-x   1 buildmaster buildmaster   40 Feb 27  2017
subversion-nightly.zip.sha1*
-rwxr-xr-x   1 buildmaster buildmaster13087 Feb 27  2017
svn_version.h.dist-nightly*

Mark notes else-thread that this hasn't worked in a long while. So maybe we
simply disable it, until there is a call for nightly builds?

Note: distinct from build/test and report build success/failure. ... this
is about storing builds for people to access/test.

Cheers,
-g

Re: Nightly builds not getting auto-purged

[Greg Stein]

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 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 2015 (!!)
>>
>
> https://ci.apache.org/projects/subversion/nightlies/index.html
> https://ci.apache.org/projects/subversion/nightlies/dist/
>
> It seems that we likely only need (say) one week's worth of nightlies
> (each is about 50M). What is the appropriate number?
>
> Is there a buildbot config option that is missing, that is avoiding a
> purge of these files? Or does something "behind the scenes" need to take
> responsibility?
>
> I believe Infra is likely to start *enforcing* some duration and overall
> disk usage constraints. This likely won't impact us, as long as we purge
> old builds according to our desired retention. So I think the more
> important concern for our community is the question of "how many nightlies
> do we want to retain?" ... I suspect whatever answer will be fine, but
> finding an accepted consensus would be helpful.
>
> I'll lead with this stake-in-the-ground:
> ** retain one week of nightly builds
>
>
> +1   a week seems reasonable
>
> Do we only make a new nightly if the /trunk HEAD has advanced since the
> last one? If so, then are you suggesting we keep the last 7 nightlies?
>
>
> Did you happen to check if we even have a current nightly? ISTR several
> months ago C-Mike had a question about building the tarball so he could try
> out the Python 3 bindings where someone pointed out we post nightlies and
> he could use that ... but then it turned out that the process had not been
> working for a few years.
>
> Maybe I mis-remember or maybe it was fixed. But it could be that none of
> them have any value (they are all old) and we are not even making these
> anymore.
>

So I was just looking at the *build date* ... but Mark is right: it's
totally broken. It has been building the same thing for a loong time.

Can anybody volunteer to pick this up, and correct it? Get it building HEAD
rather than $oldcrap ?

Then we still have the "how many to retain?" question. I do like Mark's
idea of maybe defining it as "7 builds" rather than "7 nights".

Cheers,
-g

Re: Nightly builds not getting auto-purged

[Greg Stein]

[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 2015 (!!)
>

https://ci.apache.org/projects/subversion/nightlies/index.html
https://ci.apache.org/projects/subversion/nightlies/dist/

It seems that we likely only need (say) one week's worth of nightlies (each
is about 50M). What is the appropriate number?

Is there a buildbot config option that is missing, that is avoiding a purge
of these files? Or does something "behind the scenes" need to take
responsibility?

I believe Infra is likely to start *enforcing* some duration and overall
disk usage constraints. This likely won't impact us, as long as we purge
old builds according to our desired retention. So I think the more
important concern for our community is the question of "how many nightlies
do we want to retain?" ... I suspect whatever answer will be fine, but
finding an accepted consensus would be helpful.

I'll lead with this stake-in-the-ground:
** retain one week of nightly builds

Cheers,
-g

Nightly builds not getting auto-purged

[Greg Stein]

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?)

[Greg Stein]

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 coordination with our vendor.
I'm tending towards "yes", but the path isn't clear yet.

There is zero problem with placing the archives onto our mbox machine for
long-term archival/safety, and is likely a first step regardless. Hit me up
offlist, and we can figure that part out.

Cheers,
Greg
InfraAdmin, ASF
(and old-school Subversion dude)

On Sun, May 17, 2020 at 3:30 PM Daniel Shahaf 
wrote:

> Pinging VP Infra.
>
> Daniel Shahaf wrote on Mon, 11 May 2020 15:35 +:
> > Daniel Shahaf wrote on Wed, 29 Apr 2020 15:38 +:
> > > I've opened an INFRA ticket for importing the dev@ and users@
> archives:
> > >
> > > https://issues.apache.org/jira/projects/INFRA/issues/INFRA-20213
> >
> > Infra declined to merge the pre-Apache archives into the main archives.
> > Instead they offered to host the pre-Apache archives on a service that's
> > accessible only to Apache Software Foundation members, and even then
> > available only on request.  Infra also reminded us that we have the
> > option of appealing their decision to VP Infra, …
> >
> > … which I hereby do.  David, the Subversion PMC requests that its
> > pre-Apache archives, about 240MB worth of gzipped mboxes, be publicly
> > served by the Apache Software Foundation.  Please let the project
> > (Cc'd) know your answer.
> >
> > Cheers,
> >
> > Daniel
>
>

Re: utf8proc required

[Greg Stein]

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 it is a required dependency. Currently I added it at the end,
> >> item 24. Moving it up will renumber most of the items. Should I do
> >> that?
> >
> >
> > +1 to group the required items, with the requisite renumbering for
> optionals.
>
> Done.
>
> r1870861 documents the required dependency on utf8proc without
> altering any other text.
>
> r1870862 moves the required dependencies SQLite, libz, and utf8proc to
> the top of the list and renumbers the list.
>

Thanks!

(and I like how you used two revs)

Cheers,
-g

Re: utf8proc required

[Greg Stein]

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 configure failed.
> >
> > This requirement is not listed in INSTALL.
>
> Good catch! Thank you for reporting.
>
> I propose to add the following (or similar) to INSTALL.
>
> I'd prefer to put utf8proc toward the top of "Dependencies in Detail"
> because it is a required dependency. Currently I added it at the end,
> item 24. Moving it up will renumber most of the items. Should I do
> that?
>

+1 to group the required items, with the requisite renumbering for
optionals.

... and:

On Tue, Dec 3, 2019 at 5:33 PM Branko Čibej  wrote:
>...

> It's bundled, so not a required external dependency.
>

Ah! Yeah... didn't know this. Daniel just made a change to point this out
at configure failure. I think we're good now, with that, and Nathan
applying his patch (above).


> $ ./configure --help
> ...
>   --with-utf8proc=PREFIX|internal
>   look for utf8proc in PREFIX or use the internal code
> ...
>
>
> But sure, it should be documented in INSTALL ... I think you might have
> commit access to that? :)


I certainly do. For nearly 20 years :p ... but as stated: I didn't know
which path/intent was appropriate. And Nathan beat me with a proposed
patch. I defer to him.

Thanks all, for the quick response and solutions!

Cheers,
-g

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

[Greg Stein]

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: http://svn.apache.org/viewvc?rev=1870772=rev
> Log:
> * build/ac-macros/utf8proc.m4
>   (SVN_UTF8PROC): When --with-utf8proc was not given, or given without an
> argument, and utf8proc was not found, have the error message suggest
> using --with-utf8proc=internal.
>
> Found by: gstein
>
> Modified:
> subversion/trunk/build/ac-macros/utf8proc.m4
>
> Modified: subversion/trunk/build/ac-macros/utf8proc.m4
> URL:
> http://svn.apache.org/viewvc/subversion/trunk/build/ac-macros/utf8proc.m4?rev=1870772=1870771=1870772=diff
>
> ==
> --- subversion/trunk/build/ac-macros/utf8proc.m4 (original)
> +++ subversion/trunk/build/ac-macros/utf8proc.m4 Tue Dec  3 23:31:42 2019
> @@ -54,7 +54,7 @@ AC_DEFUN(SVN_UTF8PROC,
>SVN_UTF8PROC_PREFIX
>  fi
>  if test "$utf8proc_found" != "yes"; then
> -  AC_MSG_ERROR([Subversion requires UTF8PROC])
> +  AC_MSG_ERROR([Subversion requires UTF8PROC; install it or re-run
> configure with "--with-utf8proc=internal"])
>  fi
>fi
>AC_SUBST(SVN_UTF8PROC_INCLUDES)
>
>
>

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

[Greg Stein]

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
> > >...
> > > +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 os.path.exists('subversion/include/svn_version.h')
> > >  + if _is_working_copy():
> >
> > Why a local func instead of just using os.path.exists() in the 'if'
> > statement? If for doc purposes, then I think a comment would suffice.
>
> Yes, for doc purposes.  How would a comment be better than a one-line
> helper function?
>

For me, it was the complexity. "Oh! A local function. What is this gonna be
used for? ... oh." Local functions are a pretty high-level Python Fu. It
kinda stood out to me.

It is a rather complicated commentary. I'd think a simpler approach:
# are we looking at a local working copy?

Cheers,
-g

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

[Greg Stein]

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 os.path.exists('subversion/include/svn_version.h')
> +if _is_working_copy():
>

Why a local func instead of just using os.path.exists() in the 'if'
statement? If for doc purposes, then I think a comment would suffice.

Cheers,
-g

Re: Subversion 2.0

[Greg Stein]

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 only if,
> >>> we decide to break backwards compatibility in some area.
> >>
> >> I disagree. It is quite common use to name something 2.0 if it has
> >> serious improvements over 1.x.
> >
> >That's marketing, not software development. :)
>
> Subversion needs some marketing -- separately from and in addition to
> plans for a 2.0.
>
> I understand that from a technical perspective, there is no reason to
> change the major version number unless compatibility/API/ABI promises are
> going to be broken. A 2.0 means you can break those promises, BUT I propose
> that just because you CAN do something doesn't mean you have to. Subversion
> 2.0 could very well keep 100% of 1.x's promises.
>

That isn't how it works.

Subversion 1.x is a signal to system administrators that they can upgrade
their 1.x installations to the latest 1.x and NOT WORRY.

Once you bring in 2.x, regardless of what the developers do to keep/lose
compatibility ... you have lost the 20-year guarantee of compatibility. The
admin must now do some research. And the question in that admin's head will
always be "what am I missing? if this is compatible with 1.x, and I should
not fear upgrading to 2.0 ... then why did they change the version number?
that was supposed to be a signal."

For 20 years, the promise has been "upgrade to 1.x without fear. 2.x makes
no guarantee". You speak of "marketing". There is no amount of marketing
that will alter the past 20 years of our API guarantees.

Cheers,
-g

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

[Greg Stein]

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 looking at Ev2
rather than creating Yet Another Editor.

Cheers,
-g

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

[Greg Stein]

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? :)
>
> The further I progress into adulthood, the more our tiny indentation
> by two spaces seems to be causing me trouble...
>
> Maybe(we) could have another (historical) vote, on tabs vs spaces this
> time?
> Disclaimer: I'd vote for tabs :)
>

Heresy!!!

Re: is translate.a.o used?

[Greg Stein]

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 last activity on that site
> > appears to be 2015 for the 1.9.0 release.
>
> I am not using this service actively at this time. I found it
> potentially useful for some activities, but it brings no improvements in
> translating the shell command help output (and it's changes) relative to
> po file editors or direct editing.
>
> So it would not have any effect if the service was discontinued.
>
> Andreas
>

is translate.a.o used?

[Greg Stein]

Hi Andreas, et al,

I'm curious whether translate.apache.org is being used (for the de.po
file). The last activity on that site appears to be 2015 for the 1.9.0
release.

The file itself (po/de.po) has seen a couple commits in 2018.

If the Apache Infrastructure team were to turn off translate.a.o, 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"

[Greg Stein]

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 to me that a lot of that knowledge
> > is likely missing in httpd-land. I also know that some of that has been
> > backported back to APR itself, but I am wondering (as I am wont to do),
> > if we couldn't do a better job here. I am sure that there are things in
> > svn that could be easily and readily folded back into APR w/o breaking
> > anything.
> >
> > I know that some of that influenced Greg's PoCore work, but it would be
> > really cool if someone in Subversion could maybe point out some of those
> > improvements and "lessons learned" so that both APR and httpd could
> > benefit.
>
> For starters, here's what we've already written down:
>
>
> https://subversion.apache.org/docs/community-guide/conventions.html#apr-pools
>
> I would especially point out the result_pool/scratch_pool distinction:
> each function gets *two* pools, one in which to allocate the return
> value, and one whose lifetime is defined as "the pool may be deleted at
> any time after the function returns".
>
> For example, when one calls a function declared as:
> .
> apr_status_t find_foo(foo_t *outparam, ..., apr_pool_t *result_pool,
> apr_pool_t *scratch_pool)
> .
> then on return *outparam will be allocated in result_pool, and
> apr_pool_clear(scratch_pool) may be called as soon as find_foo()
> returned.


Yup.


>   Thus, scratch_pool is passed into the result_pool formal
> parameter of functions find_foo() calls, is the pool iterpools are created
> as subpools of, etc. .
>

This is a bit unclear, so skip this and go read the page :-)


> I'm sure Greg is subscribed to at least one of these lists and will add
> anything I forgot :)


All three, actually :-) ... and the pointer to the coding convention page
is exactly what I wanted to point the other groups at.

iterpool, scratch_pool, and result_pool are the KEY three concepts that we
learned while working on Subversion. Also relying on your *caller* to know
more about memory management / lifetimes. The conventions page does a
really great job of describing what we learned, and we're here to
expand/answer where it isn't (and #fixthedoc :-P ), and/or provide further
examples to clarify.

Cheers,
-g

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

[Greg Stein]

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:

Consider if the mid-LTS had an entrypoint with 3 parameters, so a client
coded to that to (also) experiment with the feature set. So Alan has got
his client installed, trying out this new "shelve" feature, running against
the mid-LTS release that has been on the system for the past year.

The following week, Brian, his system administrator upgrades to the LTS
release, for the admin's sanity. "What? LTS releases? YAY! Less work for
me."

In the LTS, the entrypoint takes 5 parameters. So the function reads wonky
stuff from the stack. Hilarity ensues.

Brian now gets a call from Alan: "I was working with $client, doing all my
normal Subversion work. But now it seems that my working copy is corrupted.
What happened?"

The hilarity ends. Alan is told he can't use his nifty client. Alan gets
angry. Brian bangs his head on his desk, and wonders how 18 years of random
Subversion upgrades were always safe. But not this week. Why did it break
this week? And it was an LTS release!?! Why

Cheers,
-g

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

[Greg Stein]

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 a
> >> regular release signifies only that we consider them more experimental
> >> (less stable) than others.
> >>
> >> That might be fine. Anyone developing against a regular release is
> >> necessarily developing against new (experimental) APIs, so maybe no
> >> explicit warning mechanism is necessary.
> > I have gone ahead with producing a release candidate 1.11.0-rc1 with
> things just as they are. It currently seems OK to me. If we decide we need
> to change this, we can.
>
>
> I've been thinking about this idea of having different compatibility
> rules for LTS and regular releases. For 18 years now we've promised and
> maintained fairly simple rules of API and ABI compatibility; so much so
> that they're implied in and used by our own code. I've come to the
> conclusion that changing these rules just because we're changing how
> many releases we support would be a very bad idea indeed.
>

Being absent from that discussion ... oh geez.

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. And in 18 years, we've never
allowed for API/ABI breakage. Never.

We've been able to be hard-core with our compatibility guarantees for 18
years. Why stop?

-g

Re: thoughts about shelving

[Greg Stein]

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 shelves.
>
> There isn't a way to convert old shelves (which are patch files) to the
> new format.
>
> However, as they are just patch files, there is an easy manual work-around
> to still apply them -- using "svn patch ".
>

When I envisioned the implementation of shelving, I figured that we would
use the sql database to its best effect. Store new pristines (which is
logically just key->fulltext). Maybe create an artificial wc_id to
construct an alternate tree of ACTUAL_NODE entries where you can store node
information of the items on the shelf.

We have a database. I see no reason to fall back to messing with patch
files.

>...

Cheers,
-g

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

[Greg Stein]

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.  The
> format
>
> The new text omits the information that f8 is new in 1.10.  In fact, the
> term "upgraded" could be taken to imply the opposite.
>
> I would suggest to keep the previous text, but clearly something about
> it wasn't right.  What was unclear about the previous text?
>

Awkward sentence structure.


> >  bump is required to allow using LZ4 compression for the data that is
> stored
> >  on the disk.  (The svnadmin info command displays the
> filesystem
> >  format number of a repository.)
>
> Unrelated: "The 'svnadmin info' command" could become a link to
> '1.9#svnadmin-info'.
>

Done. Would be preferable to have an svnbook reference.

Cheers,
-g

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

[Greg Stein]

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: 1825449
> >
> > URL: http://svn.apache.org/viewvc?rev=1825449=rev
> > Log:
> > rewrite unclear sentence. fix typo.
> >
> > +++ subversion/site/staging/docs/release-notes/1.10.html Tue Feb 27
> > 13:46:48 2018
> > @@ -538,7 +538,7 @@ version, which still uses zlib compressi
> >   title="Link to this section">
> >  
> >
> > -The default filesystem format is now a new format, numbered 8.  The
> format
> > +The default filesystem format has been upgraded to version 8.  The
> format
>
> The new text omits the information that f8 is new in 1.10.  In fact, the
> term "upgraded" could be taken to imply the opposite.
>
> I would suggest to keep the previous text, but clearly something about
> it wasn't right.  What was unclear about the previous text?
>
> >  bump is required to allow using LZ4 compression for the data that is
> stored
> >  on the disk.  (The svnadmin info command displays the
> filesystem
> >  format number of a repository.)
>
> Unrelated: "The 'svnadmin info' command" could become a link to
> '1.9#svnadmin-info'.
>
> Cheers,
>
> Daniel
>

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

[Greg Stein]

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,  wrote:

> Author: gstein
> Date: Tue Feb 27 13:46:48 2018
> New Revision: 1825449
>
> URL: http://svn.apache.org/viewvc?rev=1825449=rev
> Log:
> rewrite unclear sentence. fix typo.
>
> Modified:
> subversion/site/staging/docs/release-notes/1.10.html
>
> Modified: subversion/site/staging/docs/release-notes/1.10.html
> URL: http://svn.apache.org/viewvc/subversion/site/staging/docs/
> release-notes/1.10.html?rev=1825449=1825448=1825449=diff
> 
> ==
> --- subversion/site/staging/docs/release-notes/1.10.html (original)
> +++ subversion/site/staging/docs/release-notes/1.10.html Tue Feb 27
> 13:46:48 2018
> @@ -538,7 +538,7 @@ version, which still uses zlib compressi
>   title="Link to this section">
>  
>
> -The default filesystem format is now a new format, numbered 8.  The
> format
> +The default filesystem format has been upgraded to version 8.  The
> format
>  bump is required to allow using LZ4 compression for the data that is
> stored
>  on the disk.  (The svnadmin info command displays the filesystem
>  format number of a repository.)
> @@ -649,7 +649,7 @@ as a single, efficient server-side query
>
>  svnbench now displays its wall-clock run time and the total
>  number of bytes transferred across the network. The
> --with-no-revprops
> -option which did not actually work in Subversion 1.9 haas been fixed.
> +option which did not actually work in Subversion 1.9 has been fixed.
>
>   
>
>
>
>

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

[Greg Stein]

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 sense. But talking
 about just "C90 + //" is, IMO, a waste of time.

>>>
Right. "Change the accepted set of compiles so we can use // comments" ...
Wat?


> About //-comments specifically, my thinking was that if we supported such
>>> comments we wouldn't run into "//-comments v. /**/-comments" conflicts
>>> when updating our embedded utf8proc.
>>>
>>
Seems like the real question is related to utf8proc, rather than comment
style.

>...

> The problem with the feature cherry-picking approach is that we don't
>> have a reliable way for compilers to warn about when /other/ features
>> except the blessed ones appear in the code.
>>
>> If we want to take the Great Leap Forward, I'd prefer to just move to
>> C99 lock, stock and barrel instead. That would likely cause problems to
>> some of our downstream users, however.
>>
>
> I fully agree with Brane on this.
>

Concur.


> Another thing that has popped up in the past and that I, personally,
> would love to see happening is supporting C++ inside our libs. I think
> that would have it made easier to me, using wrapper classes / templates
> with appropriate operator overloading, to migrate code from one API /
> data structure to another.
>

Yeah. It would be great to start using some C++ within include/private/,
and the implementing modules.

It is difficult to see how we could place any C++ into our public API,
however. And yeah, I know you didn't mention that. :-)


> However, that move too, would create all sorts of compatibility issues
> with rules to address them and all for a limited increase in coding
> convenience.
>

Right. Like /*..*/ comments versus //

Cheers,
-g

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

[Greg Stein]

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 -shared to the
> compile and link commands.  If we do this for the libsvn_auth_ libraries
>

I can see this, in order to avoid hauling in large parts of Gnome/KDE.


> then we should probably do it for the apache modules as well.  I don't
>

But Apache httpd can be built as a static build, including all modules
statically. httpd has various logic to determine whether a module has been
linked or must be loaded.

I'm not sure how many people choose to do static linking of httpd today,
but it is a definite removal of a feature.

>...

Cheers,
-g

RAT builds

[Greg Stein]

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 we haven't noticed), then
please feel free to email us at users@infra.a.o

Thanks!
-g

Re: Files with identical SHA1 breaks the repo

[Greg Stein]

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 once. Very handy, when
you're talking about megabytes in a stream-y environment.

(and medium-term, push this dual-sha1 computation back into APR)


On Sun, Feb 26, 2017 at 10:08 AM, Garance A Drosehn  wrote:

> On 24 Feb 2017, at 15:46, Stefan Sperling wrote:
> >
> > I believe we should prepare a new working format for 1.10.0
> > which addresses this problem. I don't see a good way of fixing
> > it without a format bump. The bright side of this is that it
> > gives us a good reason to get 1.10.0 ready ASAP.
> >
> > We can switch to a better hash algorithm with a WC format
> > bump.
>
> One of the previous messages mentioned that better hash
> algorithms are more expensive.  So let me mention a tactic
> that I used many years ago, when MD5 was the best digest
> algorithm that I knew of, and I didn't trust it for the
> larger files I was working with at the time:
>
> Instead of going with a completely different hash algorithm,
> just double-down on the one you're using.  What I did was to
> calculate one digest the standard way, and then a second one
> which summed up every-other-byte (or every 3rd byte, or ...).
> So to get a collision, not only do two files have to get the
> same digest-result for all their data, but they have to also
> get the same digest-result when exactly half the data is
> skipped over.
>
> (I did this a long time ago, and forget the details.  What
> I may have done for performance reasons was every-other-word,
> not every-other-byte)
>
> My thinking was that *any* single algorithm which processes
> all the data is going to get collisions, eventually.  But it
> will be much harder for someone to generate a duplicate file
> where there will also be a collision when summing up only
> half of the data.
>
> I'm not claiming this is great cure-all solution, but just
> that it's an alternate tactic which might be interesting.
> People could create repositories with just the one digest,
> or upgrade it to use multiple digests if they have the need.
>
> I found a few benchmarks which suggest that sha-256 is maybe
> twice as expensive as sha-1, so calculating two sha-1 digests
> might be a reasonable alternative.
>
> --
> Garance Alistair Drosehn= dro...@rpi.edu
> Senior Systems Programmer   or   g...@freebsd.org
> Rensselaer Polytechnic Institute; Troy, NY;  USA
>

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

[Greg Stein]

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 SHA-1 collision" >&2
> +  exit 2
> +fi
> +
> +FILES=`$SVNLOOK changed -t "$TXN" "$REPOS" | /usr/bin/grep -Ev '^D ' |
> /usr/bin/awk '{print $2}'`
>

FILES is not defined before the upper block.

>...

Cheers,
-g

Re: buildbot failure in on svn-warnings

[Greg Stein]

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
> building . Full details are available at:
> https://ci.apache.org/builders/svn-warnings/builds/1687
>
> Buildbot URL: https://ci.apache.org/
>
> Buildslave for this Build: bb_qnode4_ubuntu
>
> Build Reason: forced: by IRC user  on channel #svn-dev: None
> Build Source Stamp: HEAD
> Blamelist:
>
> BUILD FAILED: failed Configure
>
> Sincerely,
>  -The Buildbot
>
>
>
>

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

[Greg Stein]

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 thread:
>
> https://mail-archives.apache.org/mod_mbox/subversion-dev/
> 201611.mbox/%3c20161107031933.GA7609@fujitsu.shahaf.local2%3e
>
>
Yeah... they all failed starting last night, when hemera was turned off.

repeated failed builds

[Greg Stein]

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

[Greg Stein]

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 
Date: Sun, Nov 27, 2016 at 4:39 AM
Subject: Re: hemera Buildbot Slave being turned off end of month
To: bui...@apache.org


Hi All,

Just a friendly reminder that Hemera will be turned off in 3 days time.

In 2 days time any remaining jobs will be moved to another host, those on
the list currently are:-

odftoolkit-trunk 
openejb-branch31 
openejb-branch32 
svn-backport-conflicts-1.7.x  svn-backport-conflicts-1.8.x  svn-backport-conflicts-1.9.x <
https://ci.apache.org/builders/svn-backport-conflicts-1.9.x> svn-warnings <
https://ci.apache.org/builders/svn-warnings> tomee-1.7.x-deploy <
https://ci.apache.org/builders/tomee-1.7.x-deploy> tomee-1.7.x-ubuntu <
https://ci.apache.org/builders/tomee-1.7.x-ubuntu> tomee-javaee-api <
https://ci.apache.org/builders/tomee-javaee-api> tomee-patches <
https://ci.apache.org/builders/tomee-patches> tomee-trunk-deploy <
https://ci.apache.org/builders/tomee-trunk-deploy> tomee-trunk-empty-repo <
https://ci.apache.org/builders/tomee-trunk-empty-repo> tomee-trunk-ubuntu <
https://ci.apache.org/builders/tomee-trunk-ubuntu> tomee-trunk-ubuntu-jvm8 <
https://ci.apache.org/builders/tomee-trunk-ubuntu-jvm8>

Gav…

> On 7 Nov. 2016, at 9:38 am, Gavin McDonald  wrote:
>
> Hi All,
>
> Hemera [1] one of our oldest build slaves (over 5 years old now), will be
turned off on the 30th November.
>
> It is recommended you move your builds to one of the new puppetised nodes
listed below [2].
> You all have karma to edit your own config files [3] or please do file an
INFRA Jira ticket [4]
> if you need assistance in making the move.
>
> I would advise you start the move NOW so that we can iron out any
wrinkles before Hemera gets
> turned off for good.
>
> Projects who are in the BCC of this mail - you are affected! Please also
reply to bui...@apache.org  list
> only. As previously mentioned you should all have representatives of the
project signed up to the
> builds mailing list. There will be no more mails about this sent direct
to the projects so keep an eye on
> the builds list for updates and discussions. (Other projects affected may
have the same questions as
> you already answered.)
>
> List of affected builds that need to move off of Hemera:-
>
> jmeter-nightly 
jmeter-nightly-index 
jmeter-trunk  odftoolkit-trunk
 openejb-branch31 <
https://ci.apache.org/builders/openejb-branch31> openejb-branch32 <
https://ci.apache.org/builders/openejb-branch32>
svn-backport-conflicts-1.7.x  svn-backport-conflicts-1.8.x  svn-backport-conflicts-1.9.x <
https://ci.apache.org/builders/svn-backport-conflicts-1.9.x> svn-warnings <
https://ci.apache.org/builders/svn-warnings> tomee-1.7.x-deploy <
https://ci.apache.org/builders/tomee-1.7.x-deploy> tomee-1.7.x-ubuntu <
https://ci.apache.org/builders/tomee-1.7.x-ubuntu> tomee-javaee-api <
https://ci.apache.org/builders/tomee-javaee-api>tomee-patches <
https://ci.apache.org/builders/tomee-patches> tomee-trunk-deploy <
https://ci.apache.org/builders/tomee-trunk-deploy> tomee-trunk-empty-repo <
https://ci.apache.org/builders/tomee-trunk-empty-repo> tomee-trunk-ubuntu <
https://ci.apache.org/builders/tomee-trunk-ubuntu> tomee-trunk-ubuntu-jvm8 <
https://ci.apache.org/builders/tomee-trunk-ubuntu-jvm8> wicket-branch-1.3.x
 wicket-branch-1.4.x <
https://ci.apache.org/builders/wicket-branch-1.4.x> wicket-branch-1.5.x <
https://ci.apache.org/builders/wicket-branch-1.5.x> wicket-branch-6.x <
https://ci.apache.org/builders/wicket-branch-6.x> wicket-branch-7.x <
https://ci.apache.org/builders/wicket-branch-7.x> wicket-master <
https://ci.apache.org/builders/wicket-master>
>
> [1] - https://ci.apache.org/buildslaves 
(see the hemera_ubuntu entry)
> [2] - https://ci.apache.org/buildslaves/bb_1604_test_ubuntu <
https://ci.apache.org/buildslaves/bb_1604_test_ubuntu> ;
https://ci.apache.org/buildslaves/bb_slave1_ubuntu  ; https://ci.apache.org/
buildslaves/bb_slave2_ubuntu 

Re: Migrating our wiki

[Greg Stein]

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! In fact, I think it's faster now than
> it ever was before :-).
>

Hat tip to Daniel Gruno. Moin has this unfortunate habit of scanning
*every* registered user when saving a page. With 1.7M spam accounts ...
well, you can see the issue :-)

He moved moin to a box with SSDs for faster I/O and nuked all inactive
accounts. Win!

(moin has been hitting Infra with downtime, so this *also* helps us, in
addition to all moin users; just needed somebody/time to dig into the "why")

Cheers,
-g

Re: backport.pl now running on svn-qavm3

[Greg Stein]

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 the new machine svn-qavm3.
>
> Thanks Johan!
>

Yeah! Great work. Thanks!

Re: MacOS buildbot?

[Greg Stein]

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 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)
>>
>
> ​I'm a bit curious ​about why you don't ask infra for this, I seem to
> remember they offered us a Mac buildbot a long time ago.
>

Long story :-/ ... the short is AOO got one from Infra, but didn't use it
or maintain it, so Infra took it down.

Re: MacOS buildbot?

[Greg Stein]

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 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)
>
>
> I maintain that bot. It's a Mac Mini:
>
> $ sw_vers
> ProductName:Mac OS X
> ProductVersion: 10.9.5
> BuildVersion:   13F34
>
> $ sysctl -a | grep memsize
> hw.memsize = 8589934592
>
> $ sysctl -a | grep cpu.thread_count
> machdep.cpu.thread_count: 8
>
> $ df -h /
> Filesystem Size   Used  Avail Capacity  iused ifree %iused
> Mounted on
> /dev/disk0s2  931Gi   42Gi  888Gi 5% 11150418 2328303245%   /
>
>
> It can run up to 2 SVN builds in parallel that each use a 2-gig RAMdisc
> (hence, using up half the available RAM). Running SVN build and tests on
> the spinning disk would be horribly slow. The RAMdiscs are created
> on-demand. There are currently 3 Serf and 11 Subversion builders
> configured to use this slave.
>
> Building AOO nightlies or releases shouldn't be a problem, assuming they
> don't need a gazillion dependencies installed on the box. Using it as a
> commit-triggered build slave would probably be a bit too much.
>
> -- Brane
>

MacOS buildbot?

[Greg Stein]

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

[Greg Stein]

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 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!
>
> +1 on both counts.
>
> Perhaps we could run this on candidate tarballs as part of the release
> process?
>
> At least at major releases, if not every candidate. I haven't explored the
> toolset to see how packaged/automatable it is.
>
> Conceivably, we could have a buildbot run this nightly-ish (weekly?), and
> have it flag issues relative to the prior release.
>
> Cheers,
> -g
>
>
> See http://lvc.github.io/abi-compliance-checker/#ABI_Dumper for
> instructions on how to run the basic analysis tool on the library objects.
>

That is some fantastic work. Thank you!

Re: ABI changes analysis

[Greg Stein]

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 expect.
> >
> > Thank you for this!
>
> +1 on both counts.
>
> Perhaps we could run this on candidate tarballs as part of the release
> process?
>

At least at major releases, if not every candidate. I haven't explored the
toolset to see how packaged/automatable it is.

Conceivably, we could have a buildbot run this nightly-ish (weekly?), and
have it flag issues relative to the prior release.

Cheers,
-g

Re: ABI changes analysis

[Greg Stein]

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 never intended to be exported (aka: double _ in
>> the name).
>
>
To be clear: they WERE intended to be exported, so other svn libraries
could use them. We have hundreds of such functions.

Cheers,
-g

Re: ABI changes analysis

[Greg Stein]

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 intentionally broken.
>

Hunh? No compatibility was broken. Those were private symbols, so removing
them was perfectly acceptable. They are/were *not* part of the (defined)
ABI.

Did you see something else? Some other breakage? Or are you just referring
to the difference between actual and defined/public ABI?

Cheers,
-g

Re: ABI changes analysis

[Greg Stein]

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,
>
> I'm working on a new project for backward compatibility analysis of the
> Linux ABIs. The report for Subversion base libraries has been recently
> added to the project:
> http://abi-laboratory.pro/tracker/timeline/subversion/
>
> The report is generated with the help of the abi-compliance-checker,
> abi-dumper and abi-tracker tools: https://github.com/lvc/abi-tracker
>
> Hope this will help users, maintainers and developers of libraries to
> maintain backward compatibility.
>
> Thank you.
>

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

[Greg Stein]

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 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?
> > >
> >
> > Darn. http://subversion.apache.org/docs/community-guide/conventions.html
> > does not talk about it at all. Nor about our argument ordering
> conventions.
>
> Patch here:
> https://home.apache.org/~danielsh/28b4fc20e310ece9885af0dd3f5171db56c3384d.txt
>
> ldap is down so I can't commit it now.  (Nor the
> plaintext_password_helper() patch from upthread)
>
>
>

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

[Greg Stein]

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 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 decide whether to save the plaintext password to disk according to
> > > the value of uninitialized memory.
> > >
> >
> > no no no ... we've always said that OUT parameters are not dependable
> when
> > an error occurs. I see no reason to change here.
>
> I don't dispute that.  We do not promise to initialize the value of an
> output argument on error.
>
> > Especially no reason to claim an API change/errata.
>
> Suppose an API consumer's code assumes the output variable would be
> initialized on error.  (Yes, it is a bug for the API consumer to make
> that assumption.)  Making the change Julian suggested might cause users
> of that API consumer to have their passwords stored in plain text on
> disk.¹  I do not consider that an acceptable result of a code
> simplification.
>

In this situation ... I would concur. The safe/conservative position is
appropriate when we're talking about passwords. Very good point.

Thx,
-g

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

[Greg Stein]

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 API docs mention this anywhere?
> Or was this information only passed around among SVN devs?
>

Darn. http://subversion.apache.org/docs/community-guide/conventions.html
does not talk about it at all. Nor about our argument ordering conventions.

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

[Greg Stein]

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 decide whether to save the plaintext password to disk according to
> the value of uninitialized memory.
>

no no no ... we've always said that OUT parameters are not dependable when
an error occurs. I see no reason to change here. Especially no reason to
claim an API change/errata.

>...

Cheers,
-g

Re: Merging parallel-put to /trunk

[Greg Stein]

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 that does that.  The aim is to measure what we
> can expect from this approach.  Please note that the patch is just a proof
> of concept, and has many various issues — the wire format, only supporting
> short-circuit authz, etc.
>
> Results without and with the patch are:
>
>   Importing 1 files, 150 ms RTT1887.582 s → 46.363 s(40.7x
> faster)
>

Is that normal-svn vs single-POST-svn?

Or is that parallel-PUT-svn vs single-POST-svn?

Re: Making FS and repos layer log API streamy

[Greg Stein]

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
> require FS implementation to be fully reentrant (to avoid problems
> like fixed in r1718167 [1])
>

Well, a callback-based interface can snapshot the state and use that as the
basis for each iteration of the callback.

An iteration interface may need to load/unpack on each invocation, and may
need to re-establish the snapshot established at the beginning of the
iteration.

I don't believe there is clearly-favored solution here. This new API solves
a clear problem with our existing API, so I say +1 for it. Sure, maybe
there are other approaches that might also work. I'll +1 that work when it
arrives too :-)

One thing that I found during some of the Ev2 work, and the ra_serf work,
is that push/pull models of control flow really affect our API and our
clients. Ideally, we'd have both, though I hate the additional complexity.
But providing clients the choice of push vs pull can be a huge win.

Cheers,
-g

Re: Merging parallel-put to /trunk

[Greg Stein]

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 feature, on the *supposition* that problems *may*
exist in another component.

Let's move forward, and not hold back on a mere thought of other problems.
... You know of one? Then okay. But otherwise, hold your tongue.

FWIW, serf can manage multiple connections, all runnings PUTs to the
server. No real issue there. We haven't tried it because the server has
never supported it. (and we couldn't under ra_neon)

Our commit code flow may need work to support it, but that does NOT detract
from creating the parallel-PUT capability on the server-side. We need an
update on the client to issue parallel PUTs, so this only means it would be
a bit more work to do so. That has no bearing on introducing the capability
on the server.


> (Can we actually do it?  What can be parallelized while keeping the
>  necessary order of operations on the transaction?  How do we plug that
>  into the commit editor?  As well as that currently HTTP/2 is not
>  officially supported by neither httpd nor serf.)
>

Oh, give me a break. "not officially supported" ... This is a public list.
I'll be nice.

Both of those components have H/2 support now.

 (2) Is making parallel PUTs the proper way to speed up commits?
>

Absolutely. Typically, the PUT is a delta against a prior revision, it may
be compressed, and it may be encrypted. ALL of the work to handle those
aspects can be handled by a different core in the server.

I seem to recall an inspection of our server time, that showed MD5 handling
was a significant component. By separating PUTs, we can get multiple server
cores working for us.


> 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.

>...

> So, are we sure that we need to implement it this way?
>

Yes. We've been wanting parallel PUTs for years. The backend has denied us.
If Stefan can pull off this work, the beer is on me. Let's say 3 nights,
however much Stefan can manage.

Cheers,
-g

Re: Making FS and repos layer log API streamy

[Greg Stein]

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 a full collection of all changes
>   Most consumers simply scan that data once. So, they can
>   just as well work on a one change at a time basis as a
>   callback.
>
> * The data types are different, so we end up with two copies.
>   A revised svn_fs_path_change_t with identical
>   svn_repo_path_change3_t can fix this. Minor adjustments
>   to the element data types further improve efficiency.
>
> I've played with a revised version of svn_fs_paths_changed
> and svn_repos_get_logs to use callbacks for the individual
> path changes. Effectively, the FS layer can now pump the
> info through the repos / authz filter into the RA layer.
>
> I'll commit the changes to /trunk over the next couple of weeks,
> mostly on 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.
>

Re: svncutter can be removed

[Greg Stein]

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 appreciated for the prior work, and the heads up!
>
> As a matter of potential interest: I originally thought that svncutter
> would be completely obsolesced by reposurgeon.  But it turns out there
> is one case where the former is still more useful.  That's when you
> have a multi-project Subversion repository and want to split it up
> into components for separate conversion to git or whatever.
>
> 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 separate dumpfiles (and then perocessing each one
> through reposugeon separately) than it would be by reading in the whole
> repo at once and doing the dissection in gitspace.
>

Gotcha. How is that different from "svndumpfilter include" ?

Or maybe the latter was created after you started svncutter?

That's why repocutter still exists.  It's not a hugely common case, but
> it comes up often eniugh to merit some support.
>

We actually use it quite a bit at the ASF, when projects go from the
"mother" svn repository, to Git repositories. Git is simply unworkable at
the scale of our svn repository, so projects have to switch to one or more
Git repos when they convert.

Cheers,
-g

Re: svncutter can be removed

[Greg Stein]

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 work, and the heads up!

Cheers,
-g


On Tue, Feb 2, 2016 at 5:42 PM, Eric S. Raymond  wrote:

> The svncutter utility under contrib/server-side can be removed.  I
> wrote it, and I'd do this myself, but I no longer seem to have current
> write-access credentials to the repo.
>
> A revised and improved version named 'repocutter' is now part of the
> reposurgeon distribution, where it actually has proper documentation
> and tests.
> --
> http://www.catb.org/~esr/;>Eric S. Raymond
>
> The IRS has become morally corrupted by the enormous power which we in
> Congress have unwisely entrusted to it. Too often it acts like a
> Gestapo preying upon defenseless citizens.
> -- Senator Edward V. Long
>

Re: svncutter can be removed

[Greg Stein]

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.
>
> 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 work, and the heads up!
>
> Cheers,
> -g
>
>
> On Tue, Feb 2, 2016 at 5:42 PM, Eric S. Raymond <e...@thyrsus.com> wrote:
>
>> The svncutter utility under contrib/server-side can be removed.  I
>> wrote it, and I'd do this myself, but I no longer seem to have current
>> write-access credentials to the repo.
>>
>> A revised and improved version named 'repocutter' is now part of the
>> reposurgeon distribution, where it actually has proper documentation
>> and tests.
>> --
>> http://www.catb.org/~esr/;>Eric S. Raymond
>>
>> The IRS has become morally corrupted by the enormous power which we in
>> Congress have unwisely entrusted to it. Too often it acts like a
>> Gestapo preying upon defenseless citizens.
>> -- Senator Edward V. Long
>>
>
>

Re: svncutter can be removed

[Greg Stein]

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 include" ?
> >
> > Or maybe the latter was created after you started svncutter?
>
> I think it was; svncutter dates back to 2009, possibly earlier.
>
> Another function it has is test load reduction.  There's a 'strip' command
> that replaces all content blobs with small unique cookies, leaving all
> node structure and metadata intact.
>
> This is very handy when some metadata malformation triggers a bug and
> the person reporting wants to send me a smallest-possible repo that will
> reproduce it.
>
> Usually the test load can be made still smaller with a 'reduce' operation.
> This, essentially, drops all nodes corresponding to plain file changes
> that are not adjacent to something interesting, like a copyfrom or
> directory
> creatio or property change. So, the branch topology is preserved.
>
> Always, so far, if a full repository triggers a bug, the stripped and
> reduced version does too. And is much easier to pass around and look at.
> --
> http://www.catb.org/~esr/;>Eric S. Raymond
>

Re: Last-Modified HTTP header in GET responses

[Greg Stein]

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
proxies/etc can properly cache the results, and (thus) avoid future touches
on the backend server, then we're good to go.

If the patch doesn't affect the caching (which it sounds like "no"), then
just go with it. Sure, it is neat to look at ayscalls, but... why? I don't
understand the need to examine/profile. Educate me?

Thx,
-g


On Mon, Jan 4, 2016 at 11:03 AM, Ivan Zhakov  wrote:

> On 4 January 2016 at 16:25, Philip Martin 
> wrote:
> > Branko Čibej  writes:
> >
> >> Your analysis looks sound, but I wonder if doing this would have any
> >> serious effect on checkout/update times; after all, the bulk of the work
> >> there is in report generation, only HTTPv2 is affected by GET response
> >> construction.
> >
> > When I checkout Subversion trunk from my local mirror I cannot measure a
> > client gain, but I can measure better server efficiency:
> >
> >  - The CPU used by Apache goes down from 1.2s to 1.1s.
> >
> >  - The number of system calls made by Apache goes down
> >
> >   68822 to  50664 for hot FSFS cache
> >  178885 to 161722 for cold FSFS cache
> >
> I'm getting similar results on Windows.  svnbench null-export of 2000
> 15kb random files in 20 directories:
> Cold FSFS caches: CPU: 2028ms, IO Reads: 16350, Elapsed: 1374ms
>  Hot FSFS caches: CPU: 1482ms, IO Reads:  9403, Elapsed: 1253ms
>
> Patched:
> Cold FSFS caches: CPU: 1794ms, IO Reads: 14440, Elapsed: 1230ms
>  Hot FSFS caches: CPU: 1263ms, IO Reads:  7787, Elapsed: 1184ms
>
> Elapsed is total execution time of svnbench null-export. CPU is
> processor used by server to serve client operation, IO reads is number
> of IO read operations of server process.
>
> So it's about 10% improvement in case of hot disk caches and local
> disk. Improvement could be more significant in case of network
> storage, spinning disks or high-load.
>
> I've also tested with 128 MB FSFS caches and full-text caching enabled:
> Baseline:
> Cold: CPU: 2028ms, IO Reads: 16028, Elapsed: 1643ms
>  Hot: CPU: 1138ms, IO Reads:  2083, Elapsed: 1164ms
>
> Patched:
> Cold: CPU: 1934ms, IO Reads: 14028, Elapsed: 1473ms
>  Hot: CPU: 1060ms, IO Reads:83, Elapsed: 1059ms
>
> --
> Ivan Zhakov
>

votes? [HISTORY HELP?]

[Greg Stein]

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 don't recall. ... ???

What other community votes have we performed?

I'm talking formal votes. Not the drive-by stuff for release branches, or
privates votes for committers. Flat-out votes where we have asked the whole
community to VOTE.

It has been rare. Thankfully. Anybody know what else we voted on?

Thx,
-g

Re: Running SVN 1.9.x on ASF servers?

[Greg Stein]

[bcc: dev@svn; switching lists...]

Yeah. I'll follow up to a more appropriate list, as we're getting into
Infra bits rather than svn bits :-)

On Tue, Dec 1, 2015 at 3:13 PM, Tony Stevenson <pct...@apache.org> wrote:

> cc+= David Nalley (for oversight, the fact there is an 'issue', etc).
>
> Hey Greg,
>
> Sorry I didn't mean to use beta. You are indeed correct, as usual, they
> are releases. :)
>
> I will state again, that while I appreciate that differing versions of
> httpd and/or subversion (and the libraries it uses) is far from a a trivial
> task for us. This will essentially mean migrating and replacing the current
> EU slave to bring it into line with the US master.  You may recall that the
> US master move (and therefore migration) was forced upon us when eris died
> over a year ago now.
>
> This forced move meant the host was put on a different OS, which
> introduced the disparity between the EU and US today.
>
> Fixing this is something that Infra would consider a project piece. i.e.
> not something we can just slot in this week. Given the projects on the
> table already, and the skills in Infra to to do the work being tied up in
> other projects; it is going to be weeks before there is any available
> cycles to address it.
>
> I understand this might not be what you want to hear, but it is a fact of
> where we are in terms of standardising, and automating everything.
>
> 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 these are not "beta" (like you said back in October). They are 1.9.x
> release packages. We don't have to do a repository upgrade at this time,
> but we may want to later. Note that you have different httpd packages on us
> and eu. That should be fixed first. And then, yes: upgrading the server
> means upgrading mod_dav_svn.
>
> Part of the reason for upgrade is to get everybody better performance, but
> also to bring us and eu into alignment. Having the write-through proxy be a
> different stack is not "bad", but it certainly isn't Good.
>
> Thanks,
> -g
>
>
> On Mon, Nov 30, 2015 at 8:40 AM, Tony Stevenson <pct...@apache.org> wrote:
>
>
> Greg,
>
> In principal this is fine, yes. If the *PMC* are going to vouch for these
> binaries, and are willing to help support Infra if/when they are deployed.
>
> Of course, I will re-iterate that Infra will roll back if any forward
> rolling is catastrophic to the service.  We are also likely to want to roll
> up the repo, in to a tarball or some such before hitting the big red
> button. JIC we need to roll back, and we cannot undo svnadmin upgrade
> (assuming such an action is needed too).
>
> Perhaps a crash course for the PMC about the stack as is, and how we get
> to a deployed update is a good idea?   Also, we'd like/need a JIRA issue
> for each bump you want (to contain any notices about steps required, or
> library changes and so on).
>
> 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 work for you, Tony?
>
> On Sat, Nov 28, 2015 at 10:04 PM, James McCoy <james...@debian.org> wrote:
>
> On Fri, Nov 27, 2015 at 10:53:43AM +0100, Bert Huijben wrote:
> > Is somebody still working on this?
>
> I had mentioned on IRC that I'd provide a PPA based on my Debian
> packaging.  I forgot to follow up and state that it's available:
>
> https://launchpad.net/~jamessan/+archive/ubuntu/subversion
>
> Cheers,
> --
> James
> GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy <james...@debian.org>
>
>
>
> Cheers
>
> --
> Tony
>
>
>
>
> Cheers
>
> --
> Tony
>
>

Re: Running SVN 1.9.x on ASF servers?

[Greg Stein]

We've *always* been willing to help.

Note these are not "beta" (like you said back in October). They are 1.9.x
release packages. We don't have to do a repository upgrade at this time,
but we may want to later. Note that you have different httpd packages on us
and eu. That should be fixed first. And then, yes: upgrading the server
means upgrading mod_dav_svn.

Part of the reason for upgrade is to get everybody better performance, but
also to bring us and eu into alignment. Having the write-through proxy be a
different stack is not "bad", but it certainly isn't Good.

Thanks,
-g


On Mon, Nov 30, 2015 at 8:40 AM, Tony Stevenson <pct...@apache.org> wrote:

> Greg,
>
> In principal this is fine, yes. If the *PMC* are going to vouch for these
> binaries, and are willing to help support Infra if/when they are deployed.
>
> Of course, I will re-iterate that Infra will roll back if any forward
> rolling is catastrophic to the service.  We are also likely to want to roll
> up the repo, in to a tarball or some such before hitting the big red
> button. JIC we need to roll back, and we cannot undo svnadmin upgrade
> (assuming such an action is needed too).
>
> Perhaps a crash course for the PMC about the stack as is, and how we get
> to a deployed update is a good idea?   Also, we'd like/need a JIRA issue
> for each bump you want (to contain any notices about steps required, or
> library changes and so on).
>
> 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 work for you, Tony?
>
> On Sat, Nov 28, 2015 at 10:04 PM, James McCoy <james...@debian.org> wrote:
>
> On Fri, Nov 27, 2015 at 10:53:43AM +0100, Bert Huijben wrote:
> > Is somebody still working on this?
>
> I had mentioned on IRC that I'd provide a PPA based on my Debian
> packaging.  I forgot to follow up and state that it's available:
>
> https://launchpad.net/~jamessan/+archive/ubuntu/subversion
>
> Cheers,
> --
> James
> GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy <james...@debian.org>
>
>
>
> Cheers
>
> --
> Tony
>
>

Re: svn+ssh long-lived daemon

[Greg Stein]

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 features. Many reproducing what has
already been done in httpd. And this is Yet Another.

I don't like this kind of feature reproduction, as I consider it a waste of
energy, and am registering my -0 on it.

Cheers,
-g


On Thu, Nov 19, 2015 at 12:22 PM, Philip Martin 
wrote:

> How do we get good performance when using public/private key pairs for
> authentication?
>
> One reason to use svn+ssh is a preference for key pairs over passwords
> for authentication.  The svnbook describes how to setup a single system
> user ID that can be used by multiple repository users:
>
>
> http://svnbook.red-bean.com/nightly/en/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.sshtricks.fixedcmd
>
> The ssh authorized_keys file is used to map public keys to Subversion
> user IDs via the --tunnel-user option.  Maintaining an authorized_keys
> file like this is not much different from maintaining a Subversion
> password file, the difference being it maps public keys to users rather
> than users to passwords and passwords do not have to be maintained.
>
> One big disadvantage of this setup is that the repository access pattern
> gives poor Subversion performance.  The reason is that svn+ssh has no
> long-lived daemon but instead starts a new svnserve tunnel process for
> each connection.  This process has a small FSFS cache and that cache
> starts empty.  It's not possible to make the cache significantly bigger
> as there may be a large number of processes, and even if it were larger
> each operation starts with a new, empty, cache.  To get good performance
> while using key pairs we need a long-lived daemon of some sort.
>
> I can simulate such a daemon by running a conventional svnserve daemon
> and then replacing the svnserve tunnel process in the authorized_keys
> file with a proxy process such as
>
>command="socat STDIO TCP:localhost:3690"
>
> In this case the client sets up an ssh tunnel, runs the socat proxy on
> the server, and the svn protocol stream from the client gets handled by
> the long-lived daemon.  While this solves the performance problem it
> doesn't really work: after authenticating to setup the ssh tunnel a
> second authentication is required to pass a username to the svnserve
> daemon.  Running the svnserve daemon in anonymous mode solves the second
> authentication problem but results in commits without svn:author and
> disallows authz.  A proxy like this is mostly pointless if Subversion
> passwords still have to be maintained.
>
> What we need is a new daemon that accepts an equivalent of --tunnel-user
> for each connection.  Here's a possible design:
>
>   1. A new svnserve "tunnel daemon" mode
>
>svnserve --tunnel-daemon -T -r path -M size
>
>  This creates a named pipe and blocks reading from the pipe.
>
>   2. A new svnserve "tunnel proxy" started via the authorized_keys file:
>
>svnserve --tunnel-proxy --tunnel-user name
>
>  This creates/binds/listens a localhost TCP socket and then writes
>  the port and the tunnel username to the named pipe.  It then blocks
>  accepting a connection on the socket.
>
>   3. The tunnel daemon main thread receives the port and username and
>  hands these to a worker thread.  The main thread goes back to
>  reading the named pipe.  The worker thread connects back to the
>  tunnel proxy using the given port.  Then the worker thread runs as
>  it would for our current svnserve tunnel mode.
>
>   4. The tunnel proxy accepts the connection from the tunnel daemon and
>  starts to proxy.  It reads from stdin and writes to the socket, and
>  reads from the socket and writes to stdout.
>
> The tunnel daemon will be able to read/write the repository as any
> Subversion user.  The named pipe can have the same OS permissions as the
> repository and this limits communication between the tunnel-proxy and
> the tunnel-daemon to system users that can already write to the
> repository.  Reads and writes on the named pipe should be atomic
> provided they are less than PIPE_BUF.
>
> Does this sound like a good idea?
>
> APR has named pipe support but it is APR_ENOTIMPL on Windows so this
> feature may start out as Unix only.
>
> Are there alternative ways to get a long-lived daemon to do
> authentication with public/private key pairs?  Can svn:// with SASL do
> it?  It might be possible to extend SASL, but I think this would involve
> client and server changes.
>
> --
> Philip Martin
> WANdisco
>

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/

[Greg Stein]

Oh! I missed the static. ... then I guess dropping the prefix altogether
would be the correct "fix". ??

On Thu, Nov 12, 2015 at 4:38 PM, Julian Foad <julianf...@gmail.com> wrote:

> Well spotted, thanks. I didn't find this as it's a local name (static
> func), although 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/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.
> >>   */
> >>  static svn_error_t *
> >> -svn_branch_revision_fetch_info(svn_branch_txn_t **txn_p,
> >> -   svn_branch_repos_t *repos,
> >> +svn_branch_revision_fetch_info(svn_branch__txn_t **txn_p,
> >
> >
> > Seems you've missed a class of renames. Shouldn't this function name be
> > renamed, too?
> >
> >>...
> >
> > Cheers,
> > -g
> >
>

Re: Merge 'svnmover' demo tool to trunk

[Greg Stein]

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 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
> >> big batch of solo thinking and scratched hundreds of sketches on scrap
> >> paper, which was productive and resulted in what I think are some good
> >> ideas, but there are still some big gaps in how to fit them together
> >> into a real Subversion.
> >
> > A quick perusal shows that this model reads entire files into memory.
> That
> > isn't workable.
>
> Of course reading entire files into memory isn't workable for a real
> product, yes, well spotted! But dealing with the file text content is
> ancillary to the element-tracking principles that this demo is
> demonstrating. Those aspects don't depend on reading the full file
> text into memory. That's just one prototyping shortcut among many.
>

While I agree with that generally, I think it needs to be considered.

In Ev1, the driver gave the receiver a window handler, and the receiver
pushed content back to the driver.

In Ev2, the driver gives the receiver a stream, and the receiver pulls
content as needed.

That change in data flow was *huge*. Lots of our code had been set up to
assume certain push/pull directions, and had to be rejiggered to cope with
the flow change.

As a result of that experience, I think simply carrying around content
misses a key piece of the puzzle.

Cheers,
-g

Re: Merge 'svnmover' demo tool to trunk

[Greg Stein]

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
> big batch of solo thinking and scratched hundreds of sketches on scrap
> paper, which was productive and resulted in what I think are some good
> ideas, but there are still some big gaps in how to fit them together
> into a real Subversion.
>

A quick perusal shows that this model reads entire files into memory. That
isn't workable.

-g

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/

[Greg Stein]

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.
>   */
>  static svn_error_t *
> -svn_branch_revision_fetch_info(svn_branch_txn_t **txn_p,
> -   svn_branch_repos_t *repos,
> +svn_branch_revision_fetch_info(svn_branch__txn_t **txn_p,
>

Seems you've missed a class of renames. Shouldn't this function name be
renamed, too?

>...

Cheers,
-g

Re: Merge 'svnmover' demo tool to trunk

[Greg Stein]

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
> such, maybe it shouldn't appear as a top-level executable but
> somewhere else, perhaps in 'tools' or 'contrib'.
>

Tools, please. ... ISTR we have basically deprecated (third party) contrib
content.

Re: Running SVN 1.9.x on ASF servers?

[Greg Stein]

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.
>

That's totally fair, and understandable given the growth of the ASF. We're
in a much different position from running early Subversion candidates a
decade ago :-)

As Branko noted else-thread, we may come back to you with .deb packages in
hand.

Thanks!
-g

Re: Migrating Subversion issues to ...

[Greg Stein]

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 "trivialities".
>>
>
> Speaking for myself only, it is because I am not "in the room" with the
> rest of you so cannot tell if the migration is going to happen no matter
> what, or if it is going to get delayed again due to these trivialities.  As
> long as you all have the energy to see this through, I certainly do not
> want to suggest you should not fix all of the trivialities that you
> desire.  I just do not want the moment to pass again and have people go
> back home and move on to other things.
>
> So my goal is just to say an imperfect migration is better than the status
> quo.
>

Exactly.

And Branko: what does it matter what we say? People can still put their
time into anything they want.

-g

Re: Migrating Subversion issues to ...

[Greg Stein]

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 hackathon, gets caught up in a day
of travel, hits the weekend, returns to work on Monday, gets involved in
$dayjob, and ...

5 years later, we have never migrated our issues.

-g

Re: Migrating Subversion issues to ...

[Greg Stein]

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 from bugzilla... Bugzilla is just another option
> that would need a different migration.
>
> Bert
> --
> From: Johan Corveleyn 
> Sent: ‎16-‎9-‎2015 12:08
> To: Ivan Zhakov 
> Cc: Stefan Hett ; Stefan ; Daniel
> Shahaf ; Julian Foad ;
> Bert Huijben ; dev 
> Subject: Re: Migrating Subversion issues to ...
>
> On Wed, Sep 16, 2015 at 11:59 AM, Ivan Zhakov  wrote:
> > On 16 September 2015 at 11:32, Stefan Hett  wrote:
> >> Hi,
> 
>  Speaking about Ivan's suggested monospace-renderer-plugin and the
> concern
>  that it might break with a future version of JIRA: My experience with
>  JIRA
>  (which dates back to around 2005 I guess) is that Atlassian is quite
>  reluctant with introducing changes which break plugins. So it's quite
>  rare
>  that that a plugin which works in 6.0 breaks during the 6.x releases.
>  Things
>  are slightly different when the major version numbers change, but then
>  this
>  only happens every 2 years or so. Hence the maintenance work for such
> a
>  plugin should be considered quite low in the general case.
>  On the other side Atlassian requires plugin developers to maintain and
>  test
>  their plugins on a regular basis (so they are still ensured to be
>  compatible
>  with later versions).
>  If that's some concern and there is some help wanted/needed, I'd be
>  willing
>  to offer Ivan a hand with the maintenance work on his plugin (if that
>  would
>  help). As a test environment I'd provide my own JIRA instance, so that
>  would
>  not add much workload to me.
> 
> >>> Thanks for offering help, but I already have test JIRA instance at my
> >>> office that I used for Serf project issues migration.
> >>>
> >>> Btw do you have any experience in writing JIRA plugins? Writing
> >>> monospaced (preformated) text render would be big help.
> >>
> >> Unfortunately not at all, otherwise I would have offered to do so.
> >> While I do have some decent knowledge of Java due to my studies, I
> haven't
> >> been coding in Java for several years now and don't even have a
> development
> >> environment set-up for that.
> >>
> > I also don't have Java environment, while I developed several plugins
> > more then 10 years ago.
> > Link to the Atlassian tutorial if ever want to learn it:
> >
> https://developer.atlassian.com/docs/getting-started/set-up-the-atlassian-plugin-sdk-and-build-a-project
> >
>
> I think we're almost there: I don't think we need a custom renderer or
> plugin. Apparently, we can get what we want by enclosing everything
> coming from bugzilla within: {noformat:nopanel=true}
>
> That way, we still have the option of using the normal rendering for
> new issues (or even editing old issues to move "nicer parts" out of
> the noformat block), and only put inside a noformat block the things
> which really need to be monospaced.
>
> See here for an example:
>
> https://issues.apache.org/jira/browse/TST-210?focusedCommentId=14747248=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14747248
>
>
>
> --
> Johan
>

Re: Migrating Subversion issues to ...

[Greg Stein]

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  wrote:

> If what Johan says is all true (which I assume it is) then why not just do
> a straight-up migration of issues and let things be proportional?  You
> could then manually correct the parts of descriptions or comments that
> would be better be formatted differently ... but only if someone cares
> enough.
>
> If it is an old closed issue, who would even care?
>
> Anyway, it just seems like new issues moving forward will be proportional
> font except where people choose to change format, so why not do same for
> history?  Especially given that it seems easier.
>
> Mark
>
>
> On Wed, Sep 16, 2015 at 6:07 AM, Johan Corveleyn 
> wrote:
>
>> On Wed, Sep 16, 2015 at 11:59 AM, Ivan Zhakov  wrote:
>> > On 16 September 2015 at 11:32, Stefan Hett  wrote:
>> >> Hi,
>> 
>>  Speaking about Ivan's suggested monospace-renderer-plugin and the
>> concern
>>  that it might break with a future version of JIRA: My experience with
>>  JIRA
>>  (which dates back to around 2005 I guess) is that Atlassian is quite
>>  reluctant with introducing changes which break plugins. So it's quite
>>  rare
>>  that that a plugin which works in 6.0 breaks during the 6.x releases.
>>  Things
>>  are slightly different when the major version numbers change, but
>> then
>>  this
>>  only happens every 2 years or so. Hence the maintenance work for
>> such a
>>  plugin should be considered quite low in the general case.
>>  On the other side Atlassian requires plugin developers to maintain
>> and
>>  test
>>  their plugins on a regular basis (so they are still ensured to be
>>  compatible
>>  with later versions).
>>  If that's some concern and there is some help wanted/needed, I'd be
>>  willing
>>  to offer Ivan a hand with the maintenance work on his plugin (if that
>>  would
>>  help). As a test environment I'd provide my own JIRA instance, so
>> that
>>  would
>>  not add much workload to me.
>> 
>> >>> Thanks for offering help, but I already have test JIRA instance at my
>> >>> office that I used for Serf project issues migration.
>> >>>
>> >>> Btw do you have any experience in writing JIRA plugins? Writing
>> >>> monospaced (preformated) text render would be big help.
>> >>
>> >> Unfortunately not at all, otherwise I would have offered to do so.
>> >> While I do have some decent knowledge of Java due to my studies, I
>> haven't
>> >> been coding in Java for several years now and don't even have a
>> development
>> >> environment set-up for that.
>> >>
>> > I also don't have Java environment, while I developed several plugins
>> > more then 10 years ago.
>> > Link to the Atlassian tutorial if ever want to learn it:
>> >
>> https://developer.atlassian.com/docs/getting-started/set-up-the-atlassian-plugin-sdk-and-build-a-project
>> >
>>
>> I think we're almost there: I don't think we need a custom renderer or
>> plugin. Apparently, we can get what we want by enclosing everything
>> coming from bugzilla within: {noformat:nopanel=true}
>>
>> That way, we still have the option of using the normal rendering for
>> new issues (or even editing old issues to move "nicer parts" out of
>> the noformat block), and only put inside a noformat block the things
>> which really need to be monospaced.
>>
>> See here for an example:
>>
>> https://issues.apache.org/jira/browse/TST-210?focusedCommentId=14747248=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14747248
>>
>>
>>
>> --
>> Johan
>>
>
>
>
> --
> Thanks
>
> Mark Phippard
> http://markphip.blogspot.com/
>

Re: Migrating Subversion issues to ...

[Greg Stein]

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 16, 2015 at 11:14 AM, Julian Foad 
wrote:

> Ivan Zhakov wrote:
> > Julian Foad wrote:
> >> The time zone offset appears not to be handled correctly in converting
> >> time stamps (on Dates: Created, Updated; and on Comments).
> >>
> >> # http://subversion.tigris.org/issues/show_bug.cgi?id=1532
> >> Opened: Tue Sep 23 10:02:00 -0700 2003
> >> --- Additional comments from Peter N. Lundblad Thu Jan 12 05:42:25
> >> -0700 2006 ---
> >> --- Additional comments from Peter N. Lundblad Tue May 2 02:21:02
> >> -0700 2006 ---
> >> --- Additional comments from Julian Foad Tue Feb 17 09:41:24 -0700
> >> 2015 ---
> >>
> >> # http://subversion.tigris.org/issues/xml.cgi?id=1532
> >> 2003-09-23 10:02:50
> >> lundblad2006-01-12 04:42:25
> >> lundblad2006-05-02 02:21:02
> >> julianfoad2015-02-17 08:41:24
> >>
> >> # https://issues.apache.org/jira/browse/SVN-1532
> >> Created: 23/Sep/03 11:02
> >> Updated: 17/Feb/15 08:41
> >> Subversion Importer added a comment - 12/Jan/06 04:42
> >> Subversion Importer added a comment - 02/May/06 03:21
> >>
> >> The time zone in my Jira profile is set to London (GMT+00), and
> >> probably assumes something about how to display local times in BST
> >> (GMT+01).
> >
> > It should be fixed now. Please note that issue tracker on tigris.org
> > displays time always in (-0700) timezone, while JIRA display in
> > user-configured timezone.
>
> That's closer, but not correct. I checked some issue notification
> emails to be sure.
>
> The time stamps in the PDT portion of any year are now converted
> correctly, but the time stamps in the PST (UTC-0800) portion of any
> year are now converted to one hour less than the correct value.
>
> I think the XML export from Tigris expresses a timestamp using PDT
> (UTC-0700) if the timestamp date is in the PDT portion of the year,
> and using PST (UTC-0800) if the timestamp date is in the PST portion
> of the year. I guess you assumed they are all in PDT?
>
> I do not know exactly what algorithm the Tigris export uses for "PDT
> portion of the year". However, the normal HTML view on Tigris is
> (currently) displaying all timestamps as PDT (UTC-0700).
>
> In issue #4594, Bert commented at:
> = 15:58 CEST (UTC+0200) (personally confirmed)
> = 14:58 BST (UTC+0100)
> = 13:58 UTC
> = 06:58 PDT (UTC-0700)
>
> => For a time stamp made today (in the DST portion of the year),
> IssueZilla now reports it in PDT in both HTML (labeled as "(+0700)")
> and XML views (unlabeled).
>
> => For a time stamp made in the DST portion of any year, I assume the same.
>
> Julian's comment on issue #1532
> <
> http://permalink.gmane.org/gmane.comp.version-control.subversion.issues/27552
> >
> = 2015-02-17 16:41:24 GMT (header of notification email from Tigris)
> = Tue Feb 17 08:41:24 -0800 2015 (in notification email from Tigris)
>
> => For a time stamp made in the winter portion of any year, Tigris
> currently (in DST) reports one hour greater in HTML (still labeled as
> "(+0700)") than in XML (unlabeled).
> => The XML is therefore reporting the time as PST (UTC-0800) and I
> would guess the HTML is reporting it as Tigris local time (currently
> UTC-0700).
>
> - Julian
>

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

[Greg Stein]

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
> pointed me to Serf.
>
>
>
> I'd like to be able to use a fully-featured WebDAV client side and
> possibly server side library.
>
>
>
> Neon was my initial choice, but since my app uses Apache/MIT licensed
> libraries, I was concerned that the LGPL license of Neon would rule that
> out, but then I noticed that SVN was using an Apache License but was using
> Neon, although use of Neon was then depreciated in favour of Serf.
>
>
>
> Some questions:
>
>
>
> How was SVN able to use the Neon library without running into license
> issues?
>
> Well, SVN is distributed as a source distribution and doesn't include the
> Neon dependency. Therefore in case of SVN it's nothing which would violate
> the LPGL.
> When it comes to using Neon in your own app you just have to comply with
> the LPGL license (for instance you'll have to provide means for others to
> use ur app with a different/customized version of Neon - see the license
> for details).
> Under which license you distribute ur app is then a separate question. You
> just have to make sure you comply to all the licenses 3rd party software
> you are using in ur app is licensed with.
>
> The other part of ur question I guess is better answered by s/o else.
>

I responded to John's message over on d...@serf.apache.org, as he'd sent a
similar query to the serf devs.

Thanks,
-g

Re: Migrating Subversion issues to ...

[Greg Stein]

I got some details back from ASF Infra:

"""
gstein ok so if we enable wiki style formatting you can wrap anything in
{{monospaced}} blocks. And use {code} blocks etc. This is already built in
to Jira and just needs enabling for your project jira.
see:
https://jira.atlassian.com/secure/WikiRendererHelpAction.jspa?section=advanced
 and
https://jira.atlassian.com/secure/WikiRendererHelpAction.jspa?section=texteffects
for
more info.
"""

This sounds like the wiki formatting schabi is talking about. So I'd raise
two questions:

1) maybe the wiki *can* somehow be applied to Description and Steps.
how/true?
2) maybe we call it "good enough", and go with proportional fonts for
Description/Steps.

Infra did say they might allow a plugin, but they would want to review it
first. Apparently, plugins affect the *entire* instance, in their
experience (tho, they might not be Render plugins; short answer: they are
hesitant, but might allow it). ... And yes: no cycles there to write such a
plugin.

Cheers,
-g


On Tue, Sep 15, 2015 at 5:54 AM, Markus Schaber <m.scha...@codesys.com>
wrote:

> Hi,
>
>
>
> We’re running jira here in-house, and it’s a rather nice system, and the
> latest releases work actually rock solid on our server.
>
>
>
> There is some wiki syntax for preformatted text, like {code} or
> {noformat}, but (at least in our installation) it’s only available for the
> comments, but not within the Description and Steps to Repeat fields.
>
>
>
> Best regards
>
> Markus Schaber
>
> *CODESYS®* a trademark of 3S-Smart Software Solutions GmbH
>
> *Inspiring Automation Solutions *
> --
>
> 3S-Smart Software Solutions GmbH
> Dipl.-Inf. Markus Schaber | Product Development Core Technology
> Memminger Str. 151 | 87439 Kempten | Germany
> Tel. +49-831-54031-979 | Fax +49-831-54031-50
>
> E-Mail: m.scha...@codesys.com | Web: codesys.com <http://www.codesys.com>
> | CODESYS store: store.codesys.com
> CODESYS forum: forum.codesys.com
>
> *Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner* | *Trade
> register: Kempten HRB 6186* | *Tax ID No.: DE 167014915*
> * -- *
>
>
>
> *This e-mail may contain confidential and/or privileged information. 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.*
>
> *Von:* Greg Stein [mailto:gst...@gmail.com]
> *Gesendet:* Dienstag, 15. September 2015 12:50
> *An:* Ivan Zhakov
> *Cc:* dev@subversion.apache.org
> *Betreff:* Re: Migrating Subversion issues to ...
>
>
>
> 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...@qqmail.nl> wrote:
>
> >...
>
> > I think we really have 3 options:
> >
> > [ ] Keep our issues on Tigris
> > [ ] Migrate our issues to a new Bugzilla instance hosted by ASF infra
> > [ ] Migrate to the standard ASF Jira installation
>
>
>
> +1 to JIRA. (and -0 on tigris; -0.5 bugzilla)
>
>
>
> >...
>
> One option to resolve this would be create JIRA plugin with very
> simple "field renderer" that uses monospaced font. Field renderer is
> configured per project, so it's technically possible to use it on
> shared ASF JIRA installation. The only question is whether ASF infra
> allow us to install such simple plugin (or develop it for us?).
>
>
>
> They already have lots of concerns around the JIRA installation. I
> seriously doubt they'd approve any such plugin, and certainly would not
> develop/test such a thing. I'll go ask ...
>
>
>
> Do JIRA comments have any sort of formatting available (eg markdown), to
> do the formatting?
>
>
>
> Cheers,
>
> -g
>
>
>

Re: Migrating Subversion issues to ...

[Greg Stein]

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 infra
> > [ ] Migrate to the standard ASF Jira installation
>

+1 to JIRA. (and -0 on tigris; -0.5 bugzilla)

>...

> One option to resolve this would be create JIRA plugin with very
> simple "field renderer" that uses monospaced font. Field renderer is
> configured per project, so it's technically possible to use it on
> shared ASF JIRA installation. The only question is whether ASF infra
> allow us to install such simple plugin (or develop it for us?).
>

They already have lots of concerns around the JIRA installation. I
seriously doubt they'd approve any such plugin, and certainly would not
develop/test such a thing. I'll go ask ...

Do JIRA comments have any sort of formatting available (eg markdown), to do
the formatting?

Cheers,
-g

Re: Migrating Subversion issues to ...

[Greg Stein]

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...@qqmail.nl>
>> b...@qqmail.nl> wrote:
>>
> >...
>
>> > I think we really have 3 options:
>> >
>> > [ ] Keep our issues on Tigris
>> > [ ] Migrate our issues to a new Bugzilla instance hosted by ASF infra
>> > [ ] Migrate to the standard ASF Jira installation
>>
>
> +1 to JIRA. (and -0 on tigris; -0.5 bugzilla)
>
> >...
>
>> One option to resolve this would be create JIRA plugin with very
>> simple "field renderer" that uses monospaced font. Field renderer is
>> configured per project, so it's technically possible to use it on
>> shared ASF JIRA installation. The only question is whether ASF infra
>> allow us to install such simple plugin (or develop it for us?).
>>
>
> They already have lots of concerns around the JIRA installation. I
> seriously doubt they'd approve any such plugin, and certainly would not
> develop/test such a thing. I'll go ask ...
>
> Do JIRA comments have any sort of formatting available (eg markdown), to
> do the formatting?
>
> Short answer: yes it has
> From JIRA's feature point of view, it has the same features available as
> the description field or any other custom field you add. That said, it can
> be set to use the text- or the wiki-markup renderer.
>

Yup. I just found the following page:

https://confluence.atlassian.com/jira/configuring-renderers-185729478.html

I don't see "Steps to Reproduce" in there, but we won't be converting any
Tigris issues into that field. We don't need monospace there. ... as long
as we have monospace in Description and Comments, then we're good to go.

I'd further posit: we can lose some fidelity in the conversion. The above
seems like we'll get 99%

Cheers,
-g

Re: 1.9.1 wrong sha1 sums on website

[Greg Stein]

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 gives:  1244a741dbcf24f2b1d165225f0159a0c994e37a  subversion-
> > 1.9.1.tar.bz2
> >
> > all 1.9.1 files, different mirrors checked, yesterday and now.
> 
> Published:
> 
> subversion-1.9.1.tar.bz22ba78f59b3669e461ef6f56326426918100e2073
> subversion-1.9.1.tar.gz 59958ee5e112a242c37d829331dde38affe2337a
> subversion-1.9.1.zip5073ed3e5c449d4abb96dcb5eca9204611bf9e5b
> 
> Actual (from mirror.catn.com):
> 
> subversion-1.9.1.tar.bz21244a741dbcf24f2b1d165225f0159a0c994e37a
> subversion-1.9.1.tar.gz db79ba6a563faf4092854f89618cfc52a2662a8f
> subversion-1.9.1.zip1427e52979097a316a392238f9806b14af1ec6b4

These three (correct/actual) checksums were in the release
announcement email. So it looks like some kind of breakdown between
the announcement and the website update. We have scripts to perform
these various steps. Maybe something broke down, or didn't get
executed correctly. We'll review.

Much appreciated!

Cheers,
-g

Re: Migrating Subversion issues to ...

[Greg Stein]

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.com> wrote:
>>
>>> On 15 September 2015 at 11:59, Bert Huijben < <b...@qqmail.nl>
>>> b...@qqmail.nl> wrote:
>>>
>> >...
>>
>>> > I think we really have 3 options:
>>> >
>>> > [ ] Keep our issues on Tigris
>>> > [ ] Migrate our issues to a new Bugzilla instance hosted by ASF infra
>>> > [ ] Migrate to the standard ASF Jira installation
>>>
>>
>> +1 to JIRA. (and -0 on tigris; -0.5 bugzilla)
>>
>> >...
>>
>>> One option to resolve this would be create JIRA plugin with very
>>> simple "field renderer" that uses monospaced font. Field renderer is
>>> configured per project, so it's technically possible to use it on
>>> shared ASF JIRA installation. The only question is whether ASF infra
>>> allow us to install such simple plugin (or develop it for us?).
>>>
>>
>> They already have lots of concerns around the JIRA installation. I
>> seriously doubt they'd approve any such plugin, and certainly would not
>> develop/test such a thing. I'll go ask ...
>>
>> Do JIRA comments have any sort of formatting available (eg markdown), to
>> do the formatting?
>>
>> Short answer: yes it has
>> From JIRA's feature point of view, it has the same features available as
>> the description field or any other custom field you add. That said, it can
>> be set to use the text- or the wiki-markup renderer.
>>
>
> Yup. I just found the following page:
>
> https://confluence.atlassian.com/jira/configuring-renderers-185729478.html
>
> I don't see "Steps to Reproduce" in there, but we won't be converting any
> Tigris issues into that field. We don't need monospace there. ... as long
> as we have monospace in Description and Comments, then we're good to go.
>
> I'd further posit: we can lose some fidelity in the conversion. The above
> seems like we'll get 99%
>

Gavin set up a test/example: https://issues.apache.org/jira/browse/TST-210

Re: Review of sizeof usage

[Greg Stein]

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, i.e.
 
abc_t *v = apr_pcalloc(pool, sizeof(*v));
apr_hash_set(hash, key, sizeof(*key), y);
z = apr_hash_get(hash, key, sizeof(*key));
 
  rather than
 
abc_t *v = apr_pcalloc(pool, sizeof(abc_t));
apr_hash_set(hash, key, sizeof(key_t), y);
z = apr_hash_get(hash, key, sizeof(key_t));
  We have had problems with both styles in the past, so neither is immune
  to bugs.  I prefer the explicit type as it is easier to grep.

 The explicit type form is more accident-prone than the variable form
 because any change requires two modifications in the same statement
 instead of one.


Agreed. I much prefer the variable-based form. It works well for locals,
arguments, fields in a structure, dereferences, etc.

Cheers,
-g

Re: The patch-exec branch

[Greg Stein]

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 x  0100 == 0100, or access(X_OK), or …)

 My answer to the first question is yes, as discussed above.


Whatever the answer, I don't think the client should _ever_ set group/world
*write* [directed by the server]. Maybe not execute, too. That just
screams for creating a point of abuse. (maybe umask applies, but I'd prefer
to ignore that; we're getting perm bits from (potentially) an untrusted
server)

Cheers,
-g

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

[Greg Stein]

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 kicks in a lot earlier in the request
 processing flow, and by modifying the request record instead of some
 internal structure it's more future-proof. IMO, that's a good thing.


Well... Bert's patch sets depth=0 for ALL walks when the method is COPY.
That is unsafe, as you don't know *why* the walk is being performed. We
only want to disable a specific walk, and the Depth:0 header trick does
exactly that.

To be fair, one day, if mod_dav ever decides to be strict about the Depth
header matching the resource type (file vs dir), then this could break. But
I don't see that happening, as it hasn't in over 15 years.

The patch that Stefan and I came up with is just moving Johan's set Depth
header concept into code.

Hat tip to Johan for finding the workaround!

Cheers,
-g

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

[Greg Stein]

Sure, I can add your +1 ... both backports? 1.8 and 1.9 ?

On Sun, Apr 19, 2015 at 1:21 PM, Bert Huijben b...@qqmail.nl wrote:

  Thanks for the explanation on why you prefer the tweak here. With that
 explanation feel free to add my +1. (Or I will add it myself later tonight).

 Bert

 Sent from 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 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 kicks in a lot earlier in the request
 processing flow, and by modifying the request record instead of some
 internal structure it's more future-proof. IMO, that's a good thing.


 Well... Bert's patch sets depth=0 for ALL walks when the method is COPY.
 That is unsafe, as you don't know *why* the walk is being performed. We
 only want to disable a specific walk, and the Depth:0 header trick does
 exactly that.

 To be fair, one day, if mod_dav ever decides to be strict about the Depth
 header matching the resource type (file vs dir), then this could break. But
 I don't see that happening, as it hasn't in over 15 years.

 The patch that Stefan and I came up with is just moving Johan's set Depth
 header concept into code.

 Hat tip to Johan for finding the workaround!

 Cheers,
 -g

Re: branching over mod_dav 2.4.6 is O(tree)

[Greg Stein]

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 all the
 active tokens under a given path and then match them against what the
 client
 has provided.  DAV supports recursive locks so the same token can be
 applied to
 multiple paths.  The client can provide that token attached to any path
 (not
 even one that it is attached to).  As long as they provide the token then
 they're ok.

 In the process of fixing mod_dav's issues over the last few years I've
 written
 a test suite for mod_dav_fs (one of these days I'm going to clean it up so
 I
 can commit it someplace).  When I first wrote it I thought this locking
 behavior was a bug.  Careful reading of the DAV spec says this is exactly
 how
 the protocol is supposed to operate.

 I believe, but I wasn't involved in the original DAV standardization
 discussions so I can't say for sure, that there are probably good reasons
 for
 this.  Locks move with paths as they move as so a lock token provided by a
 client might be based on a different location than the current lock
 applies to.
  Also DAV supports recursive locks and the actual locked location might be
 above anything the client is aware of.


And if you modify A/B, then sometimes you must provide lock tokens for both
A and B.

...

 This isn't about lock validation.  I already added a flag to mod_dav's
 request
 validation to say not to validate locks on the COPY source.  Doing the lock
 validation on the COPY source was flat out wrong in generic DAV as well as
 SVN's usage of DAV.  The problem is that mod_dav's code to validate ETag's
 in
 If statements is (unfortunately) intertwined with the locks.  Since
 mod_dav's
 interface to validate locks walks the tree to discover the locks this means
 that validating the ETag's also walks the tree (which is itself probably
 suboptimal but that's another issue for another day).


It's kind of hard to get around that tree walk :-/

But I'll warn you now: that if-header processing logic, that handles the
etags and locks ... the code in there is my THIRD attack at the problem. It
was incredibly difficult to get it done correctly. Other people ran into
the same difficulty of implementing that stuff; I still recall another
implementor trying to get it right, and the answer his manager provided
was, do whatever mod_dav does.

I'd be happy to review any patches. Just let me know.

...

 What mod_dav_svn is not advertised is as a generic DeltaV server (which is
 an
 additional layer on top of DAV).  Our protocol changes with http v2 were to
 diverge from the official DeltaV specification.  We never promised anyone
 that
 we'd continue to adhere strictly to DeltaV.

 To the best of my knowledge there is almost no interoperable DeltaV
 software
 out there.  I haven't actually tried but I don't think Cadavear can really
 be
 used as a SVN client and I'm certain you can't use SVN against the only
 other
 DeltaV server (Oberon) that exists.


None. We hoped there would be, and that we could make the necessary
client/server changes to interoperate with that software ... but none ever
developed. DeltaV was designed with ClearCase and Perforce models in mind,
and possibly a couple others. It had zero support for SVN/CVS style
client-side working copies. I got that added into the spec, back in 2000,
and that's what we used for our first protocol.

But with the lack of other DeltaV software, there was no need to stick to
extra machinations, and CMike got all that ripped out with v2.


 Despite all of that, we actually do have to continue to support the
 original
 protocol implementation (that as far as I'm aware of is precisely DeltaV)
 because we have SVN clients in the wild that only talk that protocol.


Right. SVN 1.0 clients should be able to work against a 1.9 server (and
vice-versa).

Cheers,
-g

Re: Copyright year displayed by command-line tools

[Greg Stein]

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:
  ...
 
  IMO, we should either not display the year (which IIUC would
  violate ASF policy), or we should display the correct year.
  Anything else makes us look silly.
 
 
  Hmm? Policy is at:
http://www.apache.org/legal/src-headers.html
 
  And that is what I see in a random sampling of our source.
 
 
 
  If I'm wrong about policy, then I propose we just change those
  lines from:
 
  Copyright (C) 2014 The Apache Software Foundation.
 
 
  Where are you seeing this?

 Output of 'svn --version', it's in subversion/libsvn_subr/version.c (and
 was in .../opt.c in 1.7).

 Been that way for decades.

 -- Brane

Re: Copyright year displayed by command-line tools

[Greg Stein]

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...@gmail.com wrote:

 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:
  ...
 
  IMO, we should either not display the year (which IIUC would
  violate ASF policy), or we should display the correct year.
  Anything else makes us look silly.
 
 
  Hmm? Policy is at:
http://www.apache.org/legal/src-headers.html
 
  And that is what I see in a random sampling of our source.
 
 
 
  If I'm wrong about policy, then I propose we just change those
  lines from:
 
  Copyright (C) 2014 The Apache Software Foundation.
 
 
  Where are you seeing this?

 Output of 'svn --version', it's in subversion/libsvn_subr/version.c (and
 was in .../opt.c in 1.7).

 Been that way for decades.

 -- Brane