Re: svn commit: r1918152 - /subversion/branches/1.14.x/STATUS

[Daniel Sahlberg]

Thanks Andreas for your work with checking the backports!

This one should be approved now that it has three votes. Would you like to
do the honors and move it under the Approved changes heading?

Kind regards,
Daniel


Den tis 4 juni 2024 kl 20:15 skrev :

> Author: astieger
> Date: Tue Jun  4 18:15:45 2024
> New Revision: 1918152
>
> URL: http://svn.apache.org/viewvc?rev=1918152=rev
> Log:
> * STATUS: vote for r1914222
>
> Modified:
> subversion/branches/1.14.x/STATUS
>
> Modified: subversion/branches/1.14.x/STATUS
> URL:
> http://svn.apache.org/viewvc/subversion/branches/1.14.x/STATUS?rev=1918152=1918151=1918152=diff
>
> ==
> --- subversion/branches/1.14.x/STATUS (original)
> +++ subversion/branches/1.14.x/STATUS Tue Jun  4 18:15:45 2024
> @@ -27,7 +27,7 @@ Candidate changes:
> Justification:
>   Users asked.
> Votes:
> - +1: dsahlberg, hartmannathan
> + +1: dsahlberg, hartmannathan, astieger
>
>   * r1917864, r1917944
> Fix cmdline parsing bugs in --change (-c) argument
>
>
>

Re: svn commit: r1915317 - /subversion/branches/1.14.x/STATUS

[Daniel Sahlberg]

Den fre 2 feb. 2024 kl 08:20 skrev Jun Omae :

> On Thu, Feb 1, 2024 at 10:42 PM Daniel Sahlberg
>  wrote:
> >
> > Den fre 19 jan. 2024 kl 07:41 skrev :
> >>
> >> Author: jun66j5
> >> Date: Fri Jan 19 06:40:59 2024
> >> New Revision: 1915317
> >>
> >> URL: http://svn.apache.org/viewvc?rev=1915317=rev
> >> Log:
> >> * STATUS: Nominate r1915316.
> >>
> >> Modified:
> >> subversion/branches/1.14.x/STATUS
> >>
> >> Modified: subversion/branches/1.14.x/STATUS
> >> URL:
> http://svn.apache.org/viewvc/subversion/branches/1.14.x/STATUS?rev=1915317=1915316=1915317=diff
> >>
> ==
> >> --- subversion/branches/1.14.x/STATUS (original)
> >> +++ subversion/branches/1.14.x/STATUS Fri Jan 19 06:40:59 2024
> >> @@ -45,6 +45,14 @@ Candidate changes:
> >> Votes:
> >>   +1: dsahlberg
> >>
> >> + * r1915316
> >> +   swig-py: Fix `none_dealloc` error caused by reference count issue in
> >> +   `apply_textdelta` invoked from `svn.repos.replay()`.
> >> +   Justification:
> >> + Fix Python interpreter crash which often occurs with large
> repositories.
> >> +   Votes:
> >> + +1: jun66j5
> >> +
> >>  Veto-blocked changes:
> >>  =
> >
> >
> > Is this serious enough that we should consider a 1.14.4 release? (Didn't
> have time to review the code yet but a quick glance positive).
> >
> > Kind regards,
> > Daniel
>
> In my opinion, yes. Python users have no workaround for the issue
> except downgrading to 1.14.2. I think it happens if Python is a
> long-running process like a daemon or with large repositories.
>
> At least, I'm considering to report it with the patch to distributors
> (Debian, Ubuntu, FreeBSD, etc.).
>
> --
> Jun Omae  (大前 潤)
>

Alright, since Nathan also thought about a release we should probably do
this.

It seems the above fix is already backported (r1915338).

There are two other fixes with two votes in the STATUS file:

 * r1914222
   Improve help message for svnmucc PUT.

This is only a help message change, but it is within the "core code" so I
think someone else has to approve it as well (but we can probably bend the
rules since it only affects translations).

 * r1912632
   Fix `invalid escape sequence` in Python scripts to prevent many
   `SyntaxWarning`s since Python 3.12.

This is the patch created by Jun last summer, review by futatuki and
committed by me. Jun, would you consider voting for this?

The two above should be fairly easy fixes and I think it would be good to
include.

Then we have the following group:

 * r1890223, r1890668, r1890673
   Support building on Win64/ARM64.

It is not approved and I'm not sure if we have someone who can look at it.

There is also the rewrite of mailer.py hook-script (in tools/hook-scripts).
I'm not sure if it is complete yet and I'm not sure if we want to release
it in a patch release. We've said before not to break Python2
compatibility, on the other hand the current script doesn't work at all
under Python3 and I'm leaning towards Python3 is the more important target
at this moment. @Greg Stein  can probably comment more on
the current status.

Kind regards,
Daniel

Re: svn commit: r1915317 - /subversion/branches/1.14.x/STATUS

[Daniel Sahlberg]

Den fre 19 jan. 2024 kl 07:41 skrev :

> Author: jun66j5
> Date: Fri Jan 19 06:40:59 2024
> New Revision: 1915317
>
> URL: http://svn.apache.org/viewvc?rev=1915317=rev
> Log:
> * STATUS: Nominate r1915316.
>
> Modified:
> subversion/branches/1.14.x/STATUS
>
> Modified: subversion/branches/1.14.x/STATUS
> URL:
> http://svn.apache.org/viewvc/subversion/branches/1.14.x/STATUS?rev=1915317=1915316=1915317=diff
>
> ==
> --- subversion/branches/1.14.x/STATUS (original)
> +++ subversion/branches/1.14.x/STATUS Fri Jan 19 06:40:59 2024
> @@ -45,6 +45,14 @@ Candidate changes:
> Votes:
>   +1: dsahlberg
>
> + * r1915316
> +   swig-py: Fix `none_dealloc` error caused by reference count issue in
> +   `apply_textdelta` invoked from `svn.repos.replay()`.
> +   Justification:
> + Fix Python interpreter crash which often occurs with large
> repositories.
> +   Votes:
> + +1: jun66j5
> +
>  Veto-blocked changes:
>  =
>

Is this serious enough that we should consider a 1.14.4 release? (Didn't
have time to review the code yet but a quick glance positive).

Kind regards,
Daniel

Re: svn commit: r1915476 - /subversion/trunk/COMMITTERS

[Daniel Sahlberg]

Nice! Welcome!

Daniel

tis 30 jan. 2024 kl. 11:54 skrev :

> Author: vinc17
> Date: Tue Jan 30 10:54:12 2024
> New Revision: 1915476
>
> URL: http://svn.apache.org/viewvc?rev=1915476=rev
> Log:
> * COMMITTERS:
>   (vinc17) Add myself as a full committer.
>
> Modified:
> subversion/trunk/COMMITTERS
>
> Modified: subversion/trunk/COMMITTERS
> URL:
> http://svn.apache.org/viewvc/subversion/trunk/COMMITTERS?rev=1915476=1915475=1915476=diff
>
> ==
> --- subversion/trunk/COMMITTERS [UTF-8] (original)
> +++ subversion/trunk/COMMITTERS [UTF-8] Tue Jan 30 10:54:12 2024
> @@ -65,6 +65,7 @@ Blanket commit access:
>futatuki   Yasuhito Futatsuki 
> jun66j5   Jun Omae 
>   dsahlberg   Daniel Sahlberg 
> +vinc17   Vincent Lefevre 
>
>  [[END ACTIVE FULL COMMITTERS.  LEAVE THIS LINE HERE; SCRIPTS LOOK FOR
> IT.]]
>
>
>
>

Re: svn commit: r1915214 - /subversion/trunk/subversion/libsvn_subr/io.c

[Daniel Sahlberg]

Den lör 13 jan. 2024 kl 09:58 skrev :

> Author: dsahlberg
> Date: Sat Jan 13 08:56:50 2024
> New Revision: 1915214
>
> URL: http://svn.apache.org/viewvc?rev=1915214=rev
> Log:
> Replace the homegrown checks for readonly/executable with calls to
> access(2)
> to consider, for example, user's secondary groups.
>
> * subversion/libsvn_subr/io.c
>   (svn_io__is_finfo_read_only): As above
>   (svn_io__is_finfo_executable): As above but move the permission check
> code
>  from here
>   (svn_io_is_file_executable): .. to here since access() wants a path and
> we
>already have it in the arguments.
>
> Suggested by: Joe Orton
> See https://lists.apache.org/list?d...@apr.apache.org
>
>
> Modified:
> subversion/trunk/subversion/libsvn_subr/io.c
>
> Modified: subversion/trunk/subversion/libsvn_subr/io.c
> URL:
> http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_subr/io.c?rev=1915214=1915213=1915214=diff
>
> ==
> --- subversion/trunk/subversion/libsvn_subr/io.c (original)
> +++ subversion/trunk/subversion/libsvn_subr/io.c Sat Jan 13 08:56:50 2024
> @@ -2531,27 +2531,14 @@ svn_io__is_finfo_read_only(svn_boolean_t
> apr_pool_t *pool)
>  {
>  #if defined(APR_HAS_USER) && !defined(WIN32) &&!defined(__OS2__)
> -  apr_status_t apr_err;
> -  apr_uid_t uid;
> -  apr_gid_t gid;
> -
> -  *read_only = FALSE;
> -
> -  apr_err = apr_uid_current(, , pool);
> -
> -  if (apr_err)
> -return svn_error_wrap_apr(apr_err, _("Error getting UID of process"));
> -
> -  /* Check write bit for current user. */
> -  if (apr_uid_compare(uid, file_info->user) == APR_SUCCESS)
> -*read_only = !(file_info->protection & APR_UWRITE);
> -
> -  else if (apr_gid_compare(gid, file_info->group) == APR_SUCCESS)
> -*read_only = !(file_info->protection & APR_GWRITE);
> -
> -  else
> -*read_only = !(file_info->protection & APR_WWRITE);
> -
> +  *read_only = (access(file_info->fname, W_OK) != 0);
> +  /* svn_io__is_finfo_read_only can be called with a dangling
> +   * symlink. access() will check the permission on the missing
> +   * target and return -1 and errno = ENOENT. Check for ENOENT
> +   * and pretend the file is writeable, otherwise we will get
> +   * spurious Reverted messages on the symlink.
> +   */
> +  if (*read_only && errno == ENOENT) *read_only = FALSE;
>  #else  /* WIN32 || __OS2__ || !APR_HAS_USER */
>*read_only = (file_info->protection & APR_FREADONLY);
>  #endif
> @@ -2564,33 +2551,7 @@ svn_io__is_finfo_executable(svn_boolean_
>  apr_finfo_t *file_info,
>  apr_pool_t *pool)
>  {
> -#if defined(APR_HAS_USER) && !defined(WIN32) &&!defined(__OS2__)
>

I'm not sure if we need to keep APR_HAS_USER here. It was required for...


> -  apr_status_t apr_err;
> -  apr_uid_t uid;
> -  apr_gid_t gid;
> -
> -  *executable = FALSE;
> -
> -  apr_err = apr_uid_current(, , pool);
>

... this function.



> -
> -  if (apr_err)
> -return svn_error_wrap_apr(apr_err, _("Error getting UID of process"));
> -
> -  /* Check executable bit for current user. */
> -  if (apr_uid_compare(uid, file_info->user) == APR_SUCCESS)
> -*executable = (file_info->protection & APR_UEXECUTE);
> -
> -  else if (apr_gid_compare(gid, file_info->group) == APR_SUCCESS)
> -*executable = (file_info->protection & APR_GEXECUTE);
> -
> -  else
> -*executable = (file_info->protection & APR_WEXECUTE);
> -
> -#else  /* WIN32 || __OS2__ || !APR_HAS_USER */
> -  *executable = FALSE;
> -#endif
> -
> -  return SVN_NO_ERROR;
> +  return svn_io_is_file_executable(executable, file_info->fname, pool);
>  }
>
>  svn_error_t *
> @@ -2599,12 +2560,7 @@ svn_io_is_file_executable(svn_boolean_t
>apr_pool_t *pool)
>  {
>  #if defined(APR_HAS_USER) && !defined(WIN32) &&!defined(__OS2__)
>

Same here...


> -  apr_finfo_t file_info;
> -
> -  SVN_ERR(svn_io_stat(_info, path, APR_FINFO_PROT | APR_FINFO_OWNER,
> -  pool));
> -  SVN_ERR(svn_io__is_finfo_executable(executable, _info, pool));
> -
> +  *executable = (access(path, X_OK) == 0);
>  #else  /* WIN32 || __OS2__ || !APR_HAS_USER */
>*executable = FALSE;
>  #endif
>
>
>
Your thoughts?

Kind regards,
Daniel

Re: svn commit: r1915215 - in /subversion/trunk/subversion: include/svn_wc.h libsvn_wc/revert.c svn/notify.c svnbench/notify.c

[Daniel Sahlberg]

Den lör 13 jan. 2024 kl 10:16 skrev :

> Author: dsahlberg
> Date: Sat Jan 13 09:16:26 2024
> New Revision: 1915215
>
> URL: http://svn.apache.org/viewvc?rev=1915215=rev
> Log:
> Manage spurious Reverted message caused by non-W access to files
> owned by another user. Part of Issue #4622.
>
> The revert notification comes from the code trying to add W permissions
> but since there is already W (for another user) the code doesn't change
> anything and the notification will come back next time as well.
>
> Changing to add a separate notification type "you don't have W access
> and we can't do anything about it".
>
> The text should be tweaked further.
>

...

Modified: subversion/trunk/subversion/svn/notify.c
URL:
http://svn.apache.org/viewvc/subversion/trunk/subversion/svn/notify.c?rev=1915215=1915214=1915215=diff
==
--- subversion/trunk/subversion/svn/notify.c (original)
+++ subversion/trunk/subversion/svn/notify.c Sat Jan 13 09:16:26 2024
@@ -450,6 +450,11 @@ notify_body(struct notify_baton *nb,
  path_local));
   break;

+case svn_wc_notify_revert_noaccess:
+  SVN_ERR(svn_cmdline_printf(pool, _("User doesn't have WRITE
permissions to file '%s' and the file isn't svn:needslock. But the file is
already writeable. Probably owned by another user."),
+ path_local));
+  break;
+
 case svn_wc_notify_failed_revert:
   SVN_ERR(svn_cmdline_printf(pool, _("Failed to revert '%s' -- "
  "try updating instead.\n"),

Modified: subversion/trunk/subversion/svnbench/notify.c
URL:
http://svn.apache.org/viewvc/subversion/trunk/subversion/svnbench/notify.c?rev=1915215=1915214=1915215=diff
==
--- subversion/trunk/subversion/svnbench/notify.c (original)
+++ subversion/trunk/subversion/svnbench/notify.c Sat Jan 13 09:16:26 2024
@@ -241,6 +241,12 @@ notify(void *baton, const svn_wc_notify_
 goto print_error;
   break;

+case svn_wc_notify_revert_noaccess:
+  if ((err = svn_cmdline_printf(pool, _("User doesn't have WRITE
permissions to file '%s' and the file isn't svn:needslock. But the file is
already writeable. Probably owned by another user."),
+path_local)))
+goto print_error;
+  break;
+
 case svn_wc_notify_failed_revert:
   if (( err = svn_cmdline_printf(pool, _("Failed to revert '%s' -- "
  "try updating instead.\n"),


I would REALLY like someone to suggest a better wording for these messages.
I couldn't come up with something simple that both explains what happend
and suggests a reason.

Kind regards,
Daniel

Re: svn commit: r1914961 - /subversion/site/staging/docs/community-guide/releasing.part.html

[Daniel Sahlberg]

Den tors 28 dec. 2023 kl 06:41 skrev :

> Author: hartmannathan
> Date: Thu Dec 28 05:41:35 2023
> New Revision: 1914961
>
> URL: http://svn.apache.org/viewvc?rev=1914961=rev
> Log:
> In site/staging:
>
> * docs/community-guide/releasing.part.html:
>   (#releasing-upload): Fix typo.
>
> Modified:
> subversion/site/staging/docs/community-guide/releasing.part.html
>
> Modified: subversion/site/staging/docs/community-guide/releasing.part.html
> URL:
> http://svn.apache.org/viewvc/subversion/site/staging/docs/community-guide/releasing.part.html?rev=1914961=1914960=1914961=diff
>
> ==
> --- subversion/site/staging/docs/community-guide/releasing.part.html
> (original)
> +++ subversion/site/staging/docs/community-guide/releasing.part.html Thu
> Dec 28 05:41:35 2023
> @@ -1222,7 +1222,7 @@ This moves the tarballs, signatures and
>  >^/dev/subversion
>  to https://dist.apache.org/repos/dist/release/subversion;
>  >^/release/subversion.
> -It takes the mirrors up to 24 hours to get pick up the new release.
> +It takes the mirrors up to 24 hours to pick up the new release.
>

I'm not sure the 24 hours apply anymore. In 2021, ASF moved to a download
content delivery network (DLCDN), see [1], and I was told that mirrors
should pick up the release within 15 minutes. Maybe we can remove this
grace period?


>  The archive will also automatically pick up the release.  While
>  running move-to-dist will move the signature files, committers are
>  still able to commit new signatures to ^/release/subversion;
>
>
>
Kind regards,
Daniel


[1] https://lists.apache.org/thread/305dcdxpoxhpoyqj4d1sfvg39olfjv6g

Re: svn commit: r1914846 - /subversion/branches/1.14.x/STATUS

[Daniel Sahlberg]

As discussed in dev@ [1], this backport should not be considered a blocker
for the upcoming 1.14.3 release.

Kind regards,
Daniel

[1] https://lists.apache.org/thread/x86cbbvy81kwq5x3jtds6dz1qwn84wsv


Den fre 22 dec. 2023 kl 10:08 skrev :

> Author: dsahlberg
> Date: Fri Dec 22 09:08:04 2023
> New Revision: 1914846
>
> URL: http://svn.apache.org/viewvc?rev=1914846=rev
> Log:
> * STATUS: Nominate r1912632.
>
> Modified:
> subversion/branches/1.14.x/STATUS
>
> Modified: subversion/branches/1.14.x/STATUS
> URL:
> http://svn.apache.org/viewvc/subversion/branches/1.14.x/STATUS?rev=1914846=1914845=1914846=diff
>
> ==
> --- subversion/branches/1.14.x/STATUS (original)
> +++ subversion/branches/1.14.x/STATUS Fri Dec 22 09:08:04 2023
> @@ -36,6 +36,15 @@ Candidate changes:
> Votes:
>   +1: futatuki
>
> + * r1912632
> +   Fix `invalid escape sequence` in Python scripts to prevent many
> +   `SyntaxWarning`s since Python 3.12.
> +   Justification:
> + Bare \ in regexps are SyntaxWarning as of Python 3.12, will be
> + SyntaxError in a future release.
> +   Votes:
> + +1: dsahlberg
> +
>  Veto-blocked changes:
>  =
>
>
>
>

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

[Daniel Sahlberg]

Den fre 15 dec. 2023 kl 10:45 skrev :

> 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 completely understand the technical details, but the Swig bindings
([1], lines 201 and below) use svn.diff.file_diff_2 to create a diff.

Would it make sense to use this instead of a hard requirement on a diff
executable?

Kind regards,
Daniel


[1] subversion/bindings/swig/python/svn/fs.py


>
> * tools/hook-scripts/mailer/mailer.py:
>   (DiffGenerator.__getitem__): remove OSError exception, as the diff
> executable must be present.
>   (class DifflibDiffContent): removed.
>
> Modified:
> subversion/trunk/tools/hook-scripts/mailer/mailer.py
>
> Modified: subversion/trunk/tools/hook-scripts/mailer/mailer.py
> URL:
> http://svn.apache.org/viewvc/subversion/trunk/tools/hook-scripts/mailer/mailer.py?rev=1914679=1914678=1914679=diff
>
> ==
> --- subversion/trunk/tools/hook-scripts/mailer/mailer.py (original)
> +++ subversion/trunk/tools/hook-scripts/mailer/mailer.py Fri Dec 15
> 09:44:03 2023
> @@ -1016,17 +1016,13 @@ class DiffGenerator:
>  if binary:
>content = src_fname = dst_fname = None
>  else:
> -  src_fname, dst_fname = diff.get_files()
> -  try:
> +src_fname, dst_fname = diff.get_files()
>  content = DiffContent(self.cfg.get_diff_cmd(self.group, {
>'label_from' : label1,
>'label_to' : label2,
>'from' : src_fname,
>'to' : dst_fname,
>}))
> -  except OSError:
> -# diff command does not exist, try difflib.unified_diff()
> -content = DifflibDiffContent(label1, label2, src_fname,
> dst_fname)
>
># return a data item for this diff
>return _data(
> @@ -1101,36 +1097,6 @@ class DiffContent:
>raise IndexError
>
>  line, ltype, self.seen_change = _classify_diff_line(line,
> self.seen_change)
> -return _data(
> -  raw=line,
> -  text=line[1:-1],  # remove indicator and newline
> -  type=ltype,
> -  )
> -
> -
> -class DifflibDiffContent():
> -  "This is a generator-like object returning annotated lines of a diff."
> -
> -  def __init__(self, label_from, label_to, from_file, to_file):
> -import difflib
> -self.seen_change = False
> -fromlines = open(from_file, 'U').readlines()
> -tolines = open(to_file, 'U').readlines()
> -self.diff = difflib.unified_diff(fromlines, tolines,
> - label_from, label_to)
> -
> -  def __nonzero__(self):
> -# we always have some items
> -return True
> -
> -  def __getitem__(self, idx):
> -
> -try:
> -  line = self.diff.next()
> -except StopIteration:
> -  raise IndexError
> -
> -line, ltype, self.seen_change = _classify_diff_line(line,
> self.seen_change)
>  return _data(
>raw=line,
>text=line[1:-1],  # remove indicator and newline
>
>
>

Re: svn commit: r1913094 - /subversion/branches/1.14.x/STATUS

[Daniel Sahlberg]

Hi,

I might have been a bit harsh here to Veto this merge, after actually
providing a positive note. But I investigated why the merge didn't go
through and I realised there is a digit missing in the nomination for the
first three revisions. I'm fairly sure it should be r1912501, r1912502,
r1912503  instead (missing the third digit).

I'd like someone (Yasuhito?) to crosscheck, if you agree feel free to
modify my vote back to the old +0 with comment and move to approved.

Kind regards,
Daniel

Den tors 19 okt. 2023 kl 02:02 skrev :

> Author: dsahlberg
> Date: Thu Oct 19 00:02:48 2023
> New Revision: 1913094
>
> URL: http://svn.apache.org/viewvc?rev=1913094=rev
> Log:
> In branches/1.14.x:
>
> * STATUS
>   Remove my nomination for the swig-py fixes. Explained on dev@
>
> Modified:
> subversion/branches/1.14.x/STATUS
>
> Modified: subversion/branches/1.14.x/STATUS
> URL:
> http://svn.apache.org/viewvc/subversion/branches/1.14.x/STATUS?rev=1913094=1913093=1913094=diff
>
> ==
> --- subversion/branches/1.14.x/STATUS (original)
> +++ subversion/branches/1.14.x/STATUS Thu Oct 19 00:02:48 2023
> @@ -39,13 +39,14 @@ Candidate changes:
>  Veto-blocked changes:
>  =
>
> -Approved changes:
> -=
> -
>   * r192501, r192502, r192503, r1912500, r1912515, r1912517, r1912691
> swig-py: Use pure Python objects as edit/parse_fns3 and decendant
> batons.
> Justification:
>   Bug fix. Issue #4916, #4917, #4918
> Votes:
>   +1: futatuki
> - +0: dsahlberg (not enough experience for +1, but looks good)
> + -1: dsahlberg Nominated revision numbers doesn't make sense, see dev@
> +
> +Approved changes:
> +=
> +
>
>
>

Re: svn commit: r1913041 - /subversion/site/staging/packages.html

[Daniel Sahlberg]

Den tis 17 okt. 2023 kl 08:50 skrev :

> Author: dsahlberg
> Date: Tue Oct 17 06:50:02 2023
> New Revision: 1913041
>
> URL: http://svn.apache.org/viewvc?rev=1913041=rev
> Log:
> In site/staging:
>
> WANdisco is renaming itself to Cirata. Update links accordingly.
>
> * packages.html
>   (multiple sections): s/wandisco/cirata/
>
> Modified:
> subversion/site/staging/packages.html
>
> Modified: subversion/site/staging/packages.html
> URL:
> http://svn.apache.org/viewvc/subversion/site/staging/packages.html?rev=1913041=1913040=1913041=diff
>
> ==
> --- subversion/site/staging/packages.html (original)
> +++ subversion/site/staging/packages.html Tue Oct 17 06:50:02 2023
>
[...]

> @@ -282,10 +282,10 @@ $ brew install (OPTIONS) subversion  https://ports.macports.org/port/subversion;
> >MacPorts (requires https://www.macports.org/
> ">MacPorts)
>  
> -https://wandisco.com/source-code-management/subversion#mac;>
> -WANdisco (client and server; supported and certified by
> -   https://wandisco.com/source-code-management/subversion;
> -   >WANdisco)
> +https://cirata.com/source-code-management/subversion#mac
> ">
> +Cirata (client and server; supported and certified by
> +   https://cirata.com/source-code-management/subversion;
> +   >Cirata)
>  
>  Older Subversion binaries were provided with Xcode in versions
> of Mac OS X prior to 10.15 (Catalina). See the
>

The website doesn't provide MacOS binaries at this time. I've reached out
to WANdisco to ask if they intend to do this or if we should remove them
from this section.

Kind regards,
Daniel

Re: svn commit: r1912515 - /subversion/trunk/subversion/bindings/swig/python/tests/repository.py

[Daniel Sahlberg]

Hi,

Some minor nits in this commit:

Den sön 24 sep. 2023 kl 11:02 skrev :

> Author: futatuki
> Date: Sun Sep 24 09:02:05 2023
> New Revision: 1912515
>

[...]

> @@ -318,6 +388,36 @@ class SubversionRepositoryTestCase(unitt
>  del subpool
>  self.assertEqual(None, editor_ref())
>
> +  def test_replay_batons_refcounts(self):
> +"""Issue SVN-4917: check ref-count of batons created and used in call
> backs"""
>

I think we mostly write "callback(s)" as a single word. (The only other
cases in the code are in the bindings - also fix? - and when "call" is used
as a verb).


> +root = fs.revision_root(self.fs, self.rev)
> +editor = BatonCollector(self.fs, root)
> +e_ptr, e_baton = delta.make_editor(editor)
> +repos.replay(root, e_ptr, e_baton)
> +for baton in editor.batons:
> +  self.assertEqual(sys.getrefcount(baton[2]), 2,
> +   "leak on baton %s after replay without errors"
> +   % repr(baton))
> +del e_baton
> +self.assertEqual(sys.getrefcount(e_ptr), 2,
> + "leak on editor baton after replay without errors")
> +
> +editor = BatonCollectorErrorOnClose(self.fs, root,
> +error_path=b'branches/v1x')
> +e_ptr, e_baton = delta.make_editor(editor)
> +self.assertRaises(SubversionException, repos.replay, root, e_ptr,
> e_baton)
> +batons= editor.batons
>

Add a space to the left of the equal sign for readability?


> +# As svn_repos_replay calls neigher close_edit callback nor abort_edit
>

Spell fix: "neither"


Kind regards,
Daniel Sahlberg

Re: svn commit: r1911830 - /subversion/branches/1.14.x/STATUS

[Daniel Sahlberg]

ons 23 aug. 2023 kl. 02:54 skrev Nathan Hartman :

> On Tue, Aug 22, 2023 at 7:08 PM Nathan Hartman 
> wrote:
> >
> > On Mon, Aug 21, 2023 at 12:59 PM Daniel Sahlberg <
> daniel.l.sahlb...@gmail.com> wrote:
> >>
> >> I'm at a loss why the backport.pl script doesn't do the backport of
> the approved r1906502. When running the script manually, it reports the
> candidate changes but nothing under Approved.
> >>
> >> [[[
> >> svnsvn@svn-qavm1:~/src/svn/1.14.x$ ../trunk/tools/dist/backport.pl
> >>
> >>
> >> === Candidate changes:
> >>
> >>
> >> >>> The r1890223 group:
> >> r1890223, r1890668, r1890673
> >>
> >> Support building on Win64/ARM64.
> >>
> >> [...]
> >> libsvn_client: Pass redirected URL for file externals.
> >>
> >>   +1: dsahlberg, stsp
> >>
> >> Run a merge? [y,l,v,±1,±0,q,e,a, ,N,?]
> >>
> >>
> >> === Veto-blocked changes:
> >>
> >>
> >> === Approved changes:
> >> svnsvn@svn-qavm1:~/src/svn/1.14.x$
> >> ]]]
> >>
> >> I'm sure there is some subtle formatting error in the approved change,
> but I can't see it.
> >
> >
> >
> > I think it needs one more newline between the row of equal signs and " *
> r1906502"
>
> Added that in r1911850.


That was indeed the issue. Thanks for figuring this out!

Kind regards
Daniel

Re: svn commit: r1911830 - /subversion/branches/1.14.x/STATUS

[Daniel Sahlberg]

I'm at a loss why the backport.pl script doesn't do the backport of the
approved r1906502. When running the script manually, it reports the
candidate changes but nothing under Approved.

[[[
svnsvn@svn-qavm1:~/src/svn/1.14.x$ ../trunk/tools/dist/backport.pl


=== Candidate changes:


>>> The r1890223 group:
r1890223, r1890668, r1890673

Support building on Win64/ARM64.

[...]
libsvn_client: Pass redirected URL for file externals.

  +1: dsahlberg, stsp

Run a merge? [y,l,v,±1,±0,q,e,a, ,N,?]


=== Veto-blocked changes:


=== Approved changes:
svnsvn@svn-qavm1:~/src/svn/1.14.x$
]]]

I'm sure there is some subtle formatting error in the approved change, but
I can't see it.

Kind regards,
Daniel


Den mån 21 aug. 2023 kl 18:49 skrev :

> Author: dsahlberg
> Date: Mon Aug 21 16:49:00 2023
> New Revision: 1911830
>
> URL: http://svn.apache.org/viewvc?rev=1911830=rev
> Log:
> * branches/1.14.x/STATUS:
>   Add ending newline to see if it resolves backport jobs not succeeding
>
> Modified:
> subversion/branches/1.14.x/STATUS
>
> Modified: subversion/branches/1.14.x/STATUS
> URL:
> http://svn.apache.org/viewvc/subversion/branches/1.14.x/STATUS?rev=1911830=1911829=1911830=diff
>
> ==
> --- subversion/branches/1.14.x/STATUS (original)
> +++ subversion/branches/1.14.x/STATUS Mon Aug 21 16:49:00 2023
> @@ -48,3 +48,4 @@ Approved changes:
>   Bug fix. Code to parse forward merges did not work as intended.
> Votes:
>   +1: hartmannathan, stsp, dsahlberg
> +
>
>
>

Re: svn commit: r1911713 - in /subversion/site/publish: ./ docs/community-guide/releasing.part.html

[Daniel Sahlberg]

Cudos to Nathan for authoring, I just did the easy job reviewing and
merging to publish...

/Daniel

Den ons 16 aug. 2023 kl 08:07 skrev :

> Author: dsahlberg
> Date: Wed Aug 16 06:07:27 2023
> New Revision: 1911713
>
> URL: http://svn.apache.org/viewvc?rev=1911713=rev
> Log:
> In site/publish:
>
> Merge 1911705-1911709 from site/staging
>
> * docs/community-guide/releasing.part.html
>   (#releasing, #release-compat, #release-stabilization-how-to-edit): Fix
> typos
>
> Modified:
> subversion/site/publish/   (props changed)
> subversion/site/publish/docs/community-guide/releasing.part.html
>
> Propchange: subversion/site/publish/
>
> --
>   Merged /subversion/site/staging:r1911705-1911709
>
> Modified: subversion/site/publish/docs/community-guide/releasing.part.html
> URL:
> http://svn.apache.org/viewvc/subversion/site/publish/docs/community-guide/releasing.part.html?rev=1911713=1911712=1911713=diff
>
> ==
> --- subversion/site/publish/docs/community-guide/releasing.part.html
> (original)
> +++ subversion/site/publish/docs/community-guide/releasing.part.html Wed
> Aug 16 06:07:27 2023
> @@ -14,7 +14,7 @@ order of specificity:
>  created?" and "What should be the content of a tarball?"
>  What steps to take when it is time to create a release.  This section
>  addresses the question of "How do I manage a release?"
> -How to constructing a set of release tarballs.  This section discusses
> +How to construct a set of release tarballs.  This section discusses
>  the steps required to go from source code in the repository to a set
> of
>  distributable .tar.gz or .zip files with the
>  desired content.
> @@ -228,7 +228,7 @@ client/server interoperability, and make
>  path between MAJOR.MINOR Subversion releases.
>
>  Compatibility can span a number of axes: everything from APIs and ABIs
> to
> -command line output formats.  We try to balance to need to modify the
> existing
> +command line output formats.  We try to balance the need to modify the
> existing
>  architecture to support new features, while still supporting current users
>  to the greatest extent possible.  The general idea is:
>
> @@ -251,7 +251,7 @@ to the greatest extent possible.  The ge
>
>  (Occasionally, bugs are found which require the behavior of old
> APIs
> to be modified slightly.  This typically only manifests itself in
> -   various corner cases and other uncommon area.  These changes are
> +   various corner cases and other uncommon areas.  These changes are
> documented as https://svn.apache.org/repos/asf/subversion/trunk/notes/api-errata/;>API
> errata for each MAJOR.MINOR release.)
>  
>
> @@ -756,8 +756,8 @@ voting, are always kept on the main rele
>  title="Link to this section">
>  
>
> -When adding revisions to a nominations that others have already voted
> on,
> -annotated their entries with "(rX only)" to clarify what parts they have
> and
> +When adding revisions to a nomination that others have already voted
> on,
> +annotate their entries with "(rX only)" to clarify what parts they have
> and
>  haven't voted on, like this:
>
>  
>
>
>

Re: svn commit: r1905663 - in /subversion/branches/pristines-on-demand-on-mwf/subversion: include/ include/private/ libsvn_client/ libsvn_wc/

[Daniel Sahlberg]

Den tors 1 dec. 2022 kl 11:42 skrev :

> Author: kotkov
> Date: Thu Dec  1 10:42:41 2022
> New Revision: 1905663
>

[...]


> Modified:
> subversion/branches/pristines-on-demand-on-mwf/subversion/include/svn_error_codes.h
> URL:
> http://svn.apache.org/viewvc/subversion/branches/pristines-on-demand-on-mwf/subversion/include/svn_error_codes.h?rev=1905663=1905662=1905663=diff
>
> ==
> ---
> subversion/branches/pristines-on-demand-on-mwf/subversion/include/svn_error_codes.h
> (original)
> +++
> subversion/branches/pristines-on-demand-on-mwf/subversion/include/svn_error_codes.h
> Thu Dec  1 10:42:41 2022
> @@ -581,6 +581,12 @@ SVN_ERROR_START
>   SVN_ERR_WC_CATEGORY_START + 42,
>   "Incompatible working copy settings")
>
> +  /** @since New in 1.15 */
> +  SVN_ERRDEF(SVN_ERR_WC_DEPRECATED_API_STORE_PRISTINE,
> + SVN_ERR_WC_CATEGORY_START + 43,
> + "This client was not updated to support working copies "
> + "without local pristines")
> +
>/* fs errors */
>

Is it really "This client"? It looks more to be based on the WC setting.

Kind regards,
/Daniel

Re: svn commit: r1902582 - /subversion/trunk/tools/dist/release.py

[Daniel Sahlberg]

Thanks for the review. I've committed a few changes as r1902722. More below.

Den ons 13 juli 2022 kl 15:57 skrev Daniel Shahaf :

> dsahlb...@apache.org wrote on Fri, Jul 08, 2022 at 20:47:42 -:
> > +++ subversion/trunk/tools/dist/release.py Fri Jul  8 20:47:42 2022
> > @@ -980,7 +979,12 @@ def roll_tarballs(args):
> >  # from a committer's LDAP profile down the road)
> >  basename = 'subversion-%s.KEYS' % (str(args.version),)
> >  filepath = os.path.join(get_tempdir(args.base_dir), basename)
> > -download_file(KEYS, filepath, None)
> > +# The following code require release.py to be executed within a
> > +# complete wc, not a shallow wc as indicated in HACKING as one
> option.
> > +# We /could/ download COMMITTERS from /trunk if it doesn't
> exist...
>
> Well, could you please either change HACKING or download COMMITTERS?
> The code for the latter is basically the tempfile+urlopen mechanics from
> the next hunk of this very diff.
>

I prefer to have less variations in the process to make it easier for new
RMs. I've removed this from HACKING in r1902723 (only on site/staging so
far).

But while I was at it, I changed make-keys.sh to accept the full filename
for the COMMITTERS file, to prepare for someone updating release.py to
download the file to a tempfile.


> > +subprocess.check_call([os.path.dirname(__file__) +
> '/make-keys.sh',
> > +   '-c', os.path.dirname(__file__) +
> '/../..',
> > +   '-o', filepath])
> >  shutil.move(filepath, get_target(args))
> >
> >  # And we're done!
> > @@ -1465,12 +1469,11 @@ def check_sigs(args):
> >
> >  def get_keys(args):
> >  'Import the LDAP-based KEYS file to gpg'
> > -# We use a tempfile because urlopen() objects don't have a .fileno()
> > -with tempfile.SpooledTemporaryFile() as fd:
> > -fd.write(urlopen(KEYS).read())
> > -fd.flush()
> > -fd.seek(0)
> > -subprocess.check_call(['gpg', '--import'], stdin=fd)
> > +with tempfile.NamedTemporaryFile(delete=False) as tmpfile:
> > +  keyspath = tmpfile.name
> > +subprocess.check_call([os.path.dirname(__file__) + '/make-keys.sh',
> '-c', os.path.dirname(__file__) + '/../..', '-o', keyspath])
> > +subprocess.check_call(['gpg', '--import', keyspath])
> > +os.remove(keyspath)
>
> That's not how one uses NamedTemporaryFile().
>
> Generally, all uses of the file should be inside the «with» block, and
> unlinking the file should be left to block's implicit handling
> (tmpfile.__exit__()).
>
> As written, however, NamedTemporaryFile() is used as though it were
> a "generate a safe temporary name" API.  That means the file is not
> created atomically and won't be cleaned up if subprocess.check_call()
> raises an exception.
>
> Could you rewrite so the file isn't used outside its «with» block?
>

Tried my best. I was afraid of the notice in the docs that a opened a
second time, but since we don't support running the RM process on Windows
it should be alright.

Kind regards,
Daniel

Re: svn commit: r1902590 - /subversion/trunk/tools/client-side/store-plaintext-password.py

[Daniel Sahlberg]

Den tors 14 juli 2022 kl 15:52 skrev Daniel Shahaf :

> Nathan Hartman wrote on Wed, 13 Jul 2022 15:29 +00:00:
> > On Wed, Jul 13, 2022 at 10:55 AM Daniel Shahaf 
> wrote:
> >> Should the entry link to the zsh script
> >> (
> https://mail-archives.apache.org/mod_mbox/subversion-dev/202008.mbox/%3C20200816130713.6abca815%40tarpaulin.shahaf.local2%3E
> )
> >> as well, as an alternative?  It might be useful for someone if their
> >> environment doesn't have Python installed or if they find the zsh script
> >> easier to audit.
> >
> > I think it would be useful, and...
> >
> >> (Well, I suppose it might make more sense to copy the script
> >> somewhere than to link to an immutable archives message with that
> >> subject line.)
> >
> > ...the place to put it is probably tools/client-side/ just like the
> > Python script.
>
> Being in tools/ would imply dev@ accepts responsibility for bug reports
> against the zsh script.  Is dev@ happy to do that?  I'm concerned about
> the bus factor.
>

I was just about to say the same thing (and with no intention to discredit
the zsh version). If it is desirable to list all available realms and let
the user choose interactively, I could add that to the Python script.

I was also going to add that I think it is better to provide one tool and
make sure that tool is working well instead of having two tools that differ
only in tiny details, since they might bit-rot in different ways over time
and it might be hard for a newcomer to understand the motivation of having
different tools.

Kind regards,
Daniel

Re: svn commit: r1902582 - /subversion/trunk/tools/dist/release.py

[Daniel Sahlberg]

Den fre 8 juli 2022 kl 22:47 skrev :

> Author: dsahlberg
> Date: Fri Jul  8 20:47:42 2022
> New Revision: 1902582
>
> URL: http://svn.apache.org/viewvc?rev=1902582=rev
> Log:
> ASF no longer provide a aggregated KEYS file, so we need to construct it
> ourselves using the make-keys.sh script.
>
> * tools/dist/release.py
>   (roll_tarballs): Call make-keys.sh to create the KEYS file
>   (get_keys): Call make-keys.sh to create the KEYS file
>
> Modified:
> subversion/trunk/tools/dist/release.py
>
> Modified: subversion/trunk/tools/dist/release.py
> URL:
> http://svn.apache.org/viewvc/subversion/trunk/tools/dist/release.py?rev=1902582=1902581=1902582=diff
>
> ==
> --- subversion/trunk/tools/dist/release.py (original)
> +++ subversion/trunk/tools/dist/release.py Fri Jul  8 20:47:42 2022
> @@ -98,7 +98,6 @@ dist_release_url = dist_repos + '/releas
>  dist_archive_url = 'https://archive.apache.org/dist/subversion'
>  buildbot_repos = os.getenv('SVN_RELEASE_BUILDBOT_REPOS',
> '
> https://svn.apache.org/repos/infra/infrastructure/buildbot/aegis/buildmaster
> ')
> -KEYS = 'https://people.apache.org/keys/group/subversion.asc'
>  extns = ['zip', 'tar.gz', 'tar.bz2']
>
>
> @@ -980,7 +979,12 @@ def roll_tarballs(args):
>  # from a committer's LDAP profile down the road)
>  basename = 'subversion-%s.KEYS' % (str(args.version),)
>  filepath = os.path.join(get_tempdir(args.base_dir), basename)
> -download_file(KEYS, filepath, None)
> +# The following code require release.py to be executed within a
> +# complete wc, not a shallow wc as indicated in HACKING as one
> option.
> +# We /could/ download COMMITTERS from /trunk if it doesn't
> exist...
> +subprocess.check_call([os.path.dirname(__file__) +
> '/make-keys.sh',
> +   '-c', os.path.dirname(__file__) + '/../..',
> +   '-o', filepath])
>  shutil.move(filepath, get_target(args))
>

I have tested the above part but NOT within the full roll_tarballs codepath
since I'm not sure if I might cause changes in the repository. I believe
the change is correct and I don't think things will be worse than trying to
download a non-existing URL but I would appreciate the help from someone
experienced in the release process to review or at least give me the
confidence to roll a tarball locally.

Kind regards,
Daniel


>  # And we're done!
> @@ -1465,12 +1469,11 @@ def check_sigs(args):
>
>  def get_keys(args):
>  'Import the LDAP-based KEYS file to gpg'
> -# We use a tempfile because urlopen() objects don't have a .fileno()
> -with tempfile.SpooledTemporaryFile() as fd:
> -fd.write(urlopen(KEYS).read())
> -fd.flush()
> -fd.seek(0)
> -subprocess.check_call(['gpg', '--import'], stdin=fd)
> +with tempfile.NamedTemporaryFile(delete=False) as tmpfile:
> +  keyspath = tmpfile.name
> +subprocess.check_call([os.path.dirname(__file__) + '/make-keys.sh',
> '-c', os.path.dirname(__file__) + '/../..', '-o', keyspath])
> +subprocess.check_call(['gpg', '--import', keyspath])
> +os.remove(keyspath)
>
>  def add_to_changes_dict(changes_dict, audience, section, change,
> revision):
>  # Normalize arguments
>
>
>

Re: svn commit: r1902364 - /subversion/trunk/build.conf

[Daniel Sahlberg]

Den mån 4 juli 2022 kl 17:09 skrev Bert Huijben :

> That line will add the ./configure time dependencies (or gen-make.py for
> Windows). The dependencies on our own libraries are added by the ‘libs =’
> line right above.
>

The libs at issue (libsvn_delta and libsvn_subr) are already in libs. The
problem seems to be that the linker is looking for these libs in the
install location ($PREFIX/lib) and they are not installed there when it
tries to link libsvn_ra_serf.

libsvn_delta and libsvn_subr seems to be installed by install-fsmod-lib.

 If you don’t get these, then it is most likely because the files don’t
> exist/aren’t build at the right time, and in that case you need to use a
> different make target, like you already suggested.
>

I tried to change the dependency to $(SVN_RA_LIB_INSTALL_DEPS) (as with
libsvn_ra a few lines above), however I get a warning about a circular
dependency. I could also depend directly on install-fsmod but I'm not sure
this is better.

Adding more and more unneeded dependencies will make things far harder to
> diagnose in the future, so we should remove strange inner dependencies for
> just a specific environment, or use the proper systems if we ever want to
> be able to find bugs in this space.
>

Agreed. Thanks for taking your time to explain!

Can you take the time to check the reproduction receipt to see if there is
anything obvious missing? I'm doing this in a fairly clean Ubuntu 21.10 (in
particular, with no SVN packages installed - I removed them before making
the tests and I use the freshly built client whenever need to access the
repo).

Would it be better to factor out libsvn_delta and libsvn_subr to their own
install target and make everything else depend on this new target?
(Grasping for straws here!)

/Daniel

Re: svn commit: r1902364 - /subversion/trunk/build.conf

[Daniel Sahlberg]

Den mån 4 juli 2022 kl 16:07 skrev Bert Huijben :

> >
> ==
> > --- subversion/trunk/build.conf (original)
> > +++ subversion/trunk/build.conf Thu Jun 30 08:10:48 2022
> > @@ -340,6 +340,7 @@ type = ra-module
> >  path = subversion/libsvn_ra_serf
> >  install = serf-lib
> >  libs = libsvn_delta libsvn_subr aprutil apriconv apr serf zlib
> > +add-install-deps = $(SVN_FS_LIB_INSTALL_DEPS)
> >  msvc-static = yes
> >
> >  # Accessing repositories via SVN
>
> Why add this dependency to libsvn_ra_serf?
>
> I think you have a different problem in your build if you need the fs
> libraries for building the serf ra layer.
>

Probably :-). I think I need some pointers where to look to understand the
build system.

The problem (the longer version has been discussed here already here and is
documented in issue #4901) is that make install-serf-lib fail when
linking libtool:
warning: relinking 'libsvn_ra_serf-1.la':
/usr/bin/ld: cannot find -lsvn_delta-1
/usr/bin/ld: cannot find -lsvn_subr-1

As far as I could determine these were installed by make install-fsmod-lib.
But again, I'm new to this...

Kind regards,
Daniel

Re: svn commit: r1900649 - in /subversion/site/publish: ./ docs/community-guide/releasing.part.html roadmap.html

[Daniel Sahlberg]

Den lör 14 maj 2022 kl 15:09 skrev Daniel Shahaf :

> dsahlb...@apache.org wrote on Sat, 07 May 2022 09:52 +00:00:
> > Merge from site/staging: 1900404, 1900405, 1900528, 1900532, 1900561,
> 1900562
> >
> > Document the revised release policy as discussed on dev@ [1].
> >
> > * publish/docs/community-guide/releasing.part.html,
> >   publish/roadmap.html:
> >   Changes in several sections related to release process, see merged
> >   revisions for details.
> >
> > [1] https://lists.apache.org/thread/17v36gol5vltyx3pv9z4wskftq7hn4zb
>
> Both docs/release-notes/index.html and the download page have
> noticebox talking about a "6-month regular and 2-year LTS release
> schedule".  The constant is wrong (need s/2/4/), as well as the term
> "schedule", I believe,
>
> (I found these by grepping for links to roadmap.html#release-planning.)
>

I suppose you were grepping in publish? Unless I missed something, those
were already committed in a second batch of updates in staging.

Thanks for the changes in r1900884, I hadn't come around to do it yet.

Anyone feel free to merge the eligible changes in staging to publish,
otherwise I'll do it later in the week. Please be careful since there are a
bunch of changes concerning the future 1.15.

Kind regards,
Daniel

Re: svn commit: r1900404 - in /subversion/site/staging: docs/community-guide/releasing.part.html roadmap.html

[Daniel Sahlberg]

Den mån 2 maj 2022 kl 23:01 skrev Daniel Shahaf :

> Also, to answer your question in the OP, we'll want to remove 1.10 from
> the download page and from dist/release/.
>

Done in r1900661 (only in staging so far) and r54361.

Thanks!

/Daniel

Re: svn commit: r1900404 - in /subversion/site/staging: docs/community-guide/releasing.part.html roadmap.html

[Daniel Sahlberg]

Den tis 3 maj 2022 kl 22:39 skrev Daniel Sahlberg <
daniel.l.sahlb...@gmail.com>:

> Den mån 2 maj 2022 23:01Daniel Shahaf  skrev:
>
>> Daniel Sahlberg wrote on Mon, 02 May 2022 20:12 +00:00:
>> > Thanks to everyone for discussing this and moving it forward! I'm sorry
>> I
>> > wasn't able to be more active last week but life got in the way.
>> >
>> > One small point below...
>> >
>> > Den lör 30 apr. 2022 kl 00:04 skrev :
>> > [...]
>> >
>> >> +LTS releases are supported for four years from the date
>> of
>> >> their
>> >> +initial release.  For instance, 1.15.x will supported until four years
>> >> after
>> >> +the announcement of 1.15.0.
>> >>
>> >
>> > Should we really declare 1.15 an LTS release at this stage?
>>
>> No.  Deciding whether 1.15 should be LTS or Regular deserves a thread of
>> its own.  As far as this thread is concerned, the documentation should
>> reflect the status quo: that it has not been decided yet whether 1.15
>> will be LTS or Regular.
>>
>> Good catch.
>>
>> If someone could please update the text staging/ that would be great.
>>
>
> r1900528
>
>
>> > I would also suggest to remove the "Transition to LTS and Regular
>> > Releases"
>> > section (
>> >
>> https://subversion-staging.apache.org/roadmap.html#transition-lts-regular-releases
>> )
>> > since it seems to concern the fixed-time release schedule. I can do
>> > this,
>> > just wanting to check that I don't missread something.
>>
>> The description of what we backport is "general backports and thereafter
>> high priority fixes" in this section, and "high priority issues such as
>> … and sometimes also other issues" in the section above.  We might want
>> to clarify the "other issues" part of the latter sentence when we delete
>> this section.
>>
>
> Oh. I read this too quick and skipped over this part of the mail in the
> commit above. I'll circle back on this tomorrow.
>

r1900561. I mostly copied from the old text describing why to do regular
releases, while reusing the old rules what kind of backports should go into
"lastest" and "older" releases.


>
>> Also, might want to explicitly spell out that 1.10 is now EOL: someone
>> might think that 1.10 would be supported with security fixes until the
>> LTS _after 1.14_ is released, as that would have been the case under our
>> pre-1.11 policy if there hadn't been Regular releases at all.
>>
>
> Did we reach consensus on this yet? Of course it follows the new policy,
> on the other hand 1.10 predates even the fixed time release policy.
>
>
>> Also, to answer your question in the OP, we'll want to remove 1.10 from
>> the download page and from dist/release/.
>>
>
> Will do, after some input on the point above.
>
>
>> Cheers,
>>
>> Daniel
>>
>

Re: svn commit: r1900404 - in /subversion/site/staging: docs/community-guide/releasing.part.html roadmap.html

[Daniel Sahlberg]

Den mån 2 maj 2022 23:01Daniel Shahaf  skrev:

> Daniel Sahlberg wrote on Mon, 02 May 2022 20:12 +00:00:
> > Thanks to everyone for discussing this and moving it forward! I'm sorry I
> > wasn't able to be more active last week but life got in the way.
> >
> > One small point below...
> >
> > Den lör 30 apr. 2022 kl 00:04 skrev :
> > [...]
> >
> >> +LTS releases are supported for four years from the date
> of
> >> their
> >> +initial release.  For instance, 1.15.x will supported until four years
> >> after
> >> +the announcement of 1.15.0.
> >>
> >
> > Should we really declare 1.15 an LTS release at this stage?
>
> No.  Deciding whether 1.15 should be LTS or Regular deserves a thread of
> its own.  As far as this thread is concerned, the documentation should
> reflect the status quo: that it has not been decided yet whether 1.15
> will be LTS or Regular.
>
> Good catch.
>
> If someone could please update the text staging/ that would be great.
>

r1900528


> > I would also suggest to remove the "Transition to LTS and Regular
> > Releases"
> > section (
> >
> https://subversion-staging.apache.org/roadmap.html#transition-lts-regular-releases
> )
> > since it seems to concern the fixed-time release schedule. I can do
> > this,
> > just wanting to check that I don't missread something.
>
> The description of what we backport is "general backports and thereafter
> high priority fixes" in this section, and "high priority issues such as
> … and sometimes also other issues" in the section above.  We might want
> to clarify the "other issues" part of the latter sentence when we delete
> this section.
>

Oh. I read this too quick and skipped over this part of the mail in the
commit above. I'll circle back on this tomorrow.


> Also, might want to explicitly spell out that 1.10 is now EOL: someone
> might think that 1.10 would be supported with security fixes until the
> LTS _after 1.14_ is released, as that would have been the case under our
> pre-1.11 policy if there hadn't been Regular releases at all.
>

Did we reach consensus on this yet? Of course it follows the new policy, on
the other hand 1.10 predates even the fixed time release policy.


> Also, to answer your question in the OP, we'll want to remove 1.10 from
> the download page and from dist/release/.
>

Will do, after some input on the point above.


> Cheers,
>
> Daniel
>

Re: svn commit: r1900404 - in /subversion/site/staging: docs/community-guide/releasing.part.html roadmap.html

[Daniel Sahlberg]

Thanks to everyone for discussing this and moving it forward! I'm sorry I
wasn't able to be more active last week but life got in the way.

One small point below...

Den lör 30 apr. 2022 kl 00:04 skrev :
[...]

> +LTS releases are supported for four years from the date of
> their
> +initial release.  For instance, 1.15.x will supported until four years
> after
> +the announcement of 1.15.0.
>

Should we really declare 1.15 an LTS release at this stage? One point is
that 1.14.0 is already two years old at this stage and it is probably time
to consider another LTS release. On the other hand, we might want to
release Julian's work as an experimental feature in a Regular release to
avoid having to support it for four years if it turns out to have issues.

I would also suggest to remove the "Transition to LTS and Regular Releases"
section (
https://subversion-staging.apache.org/roadmap.html#transition-lts-regular-releases)
since it seems to concern the fixed-time release schedule. I can do this,
just wanting to check that I don't missread something.

Kind regards,
Daniel

Re: svn commit: r1899276 - /subversion/site/publish/upcoming.part.html

[Daniel Sahlberg]

Den mån 11 apr. 2022 kl 13:27 skrev Mark Phippard :

> On Sun, Apr 10, 2022 at 9:45 PM Daniel Shahaf 
> wrote:
> >
> > Daniel Sahlberg wrote on Mon, Mar 28, 2022 at 21:55:36 +0200:
> > > Den mån 28 mars 2022 kl 09:55 skrev Daniel Sahlberg <
> > > daniel.l.sahlb...@gmail.com>:
> > >
> > > > This commit doesn't look correct.
> > > >
> > > > I executed the generate-upcoming-changes-log.sh manually yesterday
> and it
> > > > created r1899244, removing a lot of log entries belonging to 1.14.1.
> This
> > > > commit (which was executed by cron) restores them.
> > > >
> > > > The crontab entry is:
> > > > [[[
> > > > # Puppet Name: Update our upcoming changes list
> > > > SVN=svn
> > > > 15 4 * * * chronic
> ~/src/svn/site/tools/generate-upcoming-changes-log.sh
> > > > ]]]
> > > >
> > > > The script begins with a comment
> > > > [[[
> > > > # This should be run from the root of a branches/1.{9,10,11}.x
> working
> > > > copy.
> > > > ]]]
> > > >
> > > > I suppose the crontab command should be changed to:
> > > > cd ~/src/svn/1.14.x && chronic
> > > > ~/src/svn/site/tools/generate-upcoming-changes-log.sh
> > > >
> > >
> > > So I've investigated this further and my initial analysis seems
> correct.
> > >
> > > This is what happens:
> > > * generate-upcoming-changes-log.sh determines last patch release
> number and
> > > generates upcoming.part.html based on all commits since that patch
> release
> > > was tagged.
> > > * It has two different ways to determine "the last patch release":
> > >* If `cwd` is a WC it look in the subversion/include/svn_version.h
> > >* Else look in
> https://dist.apache.org/repos/dist/release/subversion/
> > > * The logic looking at dists.a.o selected the oldest patch release
> > > available on dists.a.o, in case there are more than one.
> > > * The crontab entry executed generate-upcoming-changes-log.sh from ~,
> thus
> > > forcing a lookup from dists.a.o
> > >
> > > Currently, both 1.14.0 and 1.14.1 are available on dists.a.o. Thus it
> > > emitted all merged changes since 1.14.0, while expected behaviour (of
> > > upcoming.part.html) would be to only display merged changes since
> 1.14.1.
> > >
> >
> > dist/ should only contain the latest release from each supported minor
> > line, except when a release is being staged.  I.e., today it should
> > contain 1.14.2 and 1.14.1 since we're in the process of staging 1.14.2;
> > but by Friday it should contain 1.14.2 and 1.10.8 and only those two.
> >
> > The script relies on this.  Thus, if we'd deleted 1.14.0's artifacts
> > when we released 1.14.1 and kept the cron job as it was, the output
> > would then have been correct (and we wouldn't have had an extra manual
> > step in our create-a-A.B.x-branch workflow).
>
> I am guessing he just did not realize this was the root cause. It
> makes sense now what was happening.
>

I realized this and I figured the chance/risk of RM forgetting to cleanup
justified to use the first way of detecting "latest patch release" (through
svn_version.h). Part of my investigation was to look at the log of dist/
and finding that this wasn't the first time that old releases were laying
around for a long time.

I agree that it makes sense to display the upcoming changes until the
release has been announced, in which case the change in puppet should be
reverted (or we should adjust the script for a better way detect "lastest
patch release". More below.

You probably all saw I cleaned up those old releases and then put them
> back. I was following the instructions in HACKING. I am not sure if
> previous RM's decided to leave those behind or just did not follow
> HACKING to the letter.
>

> Anyway, I thought the documentation was ambiguous about WHEN you
> should do this cleanup. I decided it should be done after the release
> is announced which is why I put them back.
>

As I read the documentation, you should cleanup as soon as the release is
uploaded, but hold back the announcement for 24 hours until the mirrors
have picked up the release. As far as I understand the mirror system at ASF
has been deprecated in favour of a CDN [1], where the CDN is supposed to
pick up the files "within 15 minutes" [2].

It is not immediately clear to me if cleaning up also disables downloading
the old release. If so, we have a 24 hour window when there are no
(annou

Re: svn commit: r1899714 - /subversion/trunk/tools/buildbot/master/README

[Daniel Sahlberg]

Den sön 10 apr. 2022 kl 21:11 skrev :

> Author: dsahlberg
> Date: Sun Apr 10 19:11:45 2022
> New Revision: 1899714
>
> URL: http://svn.apache.org/viewvc?rev=1899714=rev
> Log:
> Update url to buildbot config repo
>
> * tools/buildbot/master/README:
>   Switch to buildbot2, buildbot doesn't exist anymore
>
> Modified:
> subversion/trunk/tools/buildbot/master/README
>
> Modified: subversion/trunk/tools/buildbot/master/README
> URL:
> http://svn.apache.org/viewvc/subversion/trunk/tools/buildbot/master/README?rev=1899714=1899713=1899714=diff
>
> ==
> --- subversion/trunk/tools/buildbot/master/README (original)
> +++ subversion/trunk/tools/buildbot/master/README Sun Apr 10 19:11:45 2022
> @@ -4,4 +4,4 @@ This was announced per this email:
>
> https://mail-archives.apache.org/mod_mbox/subversion-dev/201005.mbox/%3caanlktilvspswjhlljvpkpgvai2-jqygqlqcn1sjgo...@mail.gmail.com%3E
>
>  The new BuildBot Master configuration is maintained here:
> -
> https://svn.apache.org/repos/infra/infrastructure/buildbot/aegis/buildmaster/master1/
> +https://svn.apache.org/repos/infra/infrastructure/buildbot2/projects/
>
>
>
I think we could also remove the link to a decade-old e-mail, but I'm open
to opinions.

/Daniel

Re: svn commit: r1899431 - /subversion/trunk/tools/dist/README.backport

[Daniel Sahlberg]

Den tors 31 mars 2022 kl 15:24 skrev :

> Author: hartmannathan
> Date: Thu Mar 31 13:24:23 2022
> New Revision: 1899431
>
> URL: http://svn.apache.org/viewvc?rev=1899431=rev
> Log:
> * tools/dist/README.backport: Update name of machine to svn-qavm.
>
> Modified:
> subversion/trunk/tools/dist/README.backport
>
> Modified: subversion/trunk/tools/dist/README.backport
> URL:
> http://svn.apache.org/viewvc/subversion/trunk/tools/dist/README.backport?rev=1899431=1899430=1899431=diff
>
> ==
> --- subversion/trunk/tools/dist/README.backport (original)
> +++ subversion/trunk/tools/dist/README.backport Thu Mar 31 13:24:23 2022
> @@ -19,7 +19,7 @@ The scripts are:
>
>  backport.pl:
>  oldest script, implements [F1], [F2], and [F3].  As of Feb 2018, used
> in
>

We could change this to As of March 2022.


> -production by svn-role (running on svn-qavm3) and by
> svn-backport-conflicts-1.9.x
> +production by svn-role (running on svn-qavm) and by
> svn-backport-conflicts-1.9.x
>  (a buildbot job).
>

I'm guessing the svn-backports-conflicts-1.9.x job isn't run anymore and it
should be reflected somehow.

I'm holding back to changing the date until we've figured out the
buildbots. And I'm holding that back until after 1.14.2.

/Daniel

Re: svn commit: r1899311 - /subversion/branches/1.14.x/STATUS

[Daniel Sahlberg]

Hi,

The backport below is stuck. backport.pl reports:

[[[
Warning summary
===

1.14.x-r1881534-no-crlf (Fix issue #4864 "build/ac-macros/macosx.m4:
workaround AC_RUN_IFELSE"): Revisions 'r1881534' nominated but not included
in branch
]]]

/Daniel

Den mån 28 mars 2022 kl 16:22 skrev :

> Author: markphip
> Date: Mon Mar 28 14:22:47 2022
> New Revision: 1899311
>
> URL: http://svn.apache.org/viewvc?rev=1899311=rev
> Log:
> * STATUS: Vote for r1881534 approving (remove previous nomination)
>
> Modified:
> subversion/branches/1.14.x/STATUS
>
> Modified: subversion/branches/1.14.x/STATUS
> URL:
> http://svn.apache.org/viewvc/subversion/branches/1.14.x/STATUS?rev=1899311=1899310=1899311=diff
>
> ==
> --- subversion/branches/1.14.x/STATUS (original)
> +++ subversion/branches/1.14.x/STATUS Mon Mar 28 14:22:47 2022
> @@ -32,18 +32,6 @@ Candidate changes:
> Votes:
>   +1: futatuki, stsp
>
> - * r1881534
> -   Fix issue #4864 "build/ac-macros/macosx.m4: workaround AC_RUN_IFELSE"
> -   Justification:
> - Unblocks cross-compiling SVN.
> -   Notes:
> - Replacement for veto-blocked r1881534 group (see below) without the
> - inconsistent line endings that instigated said veto blockage.
> -   Branch:
> - 1.14.x-r1881534-no-crlf
> -   Votes:
> - +1: hartmannathan, stsp
> -
>   * r1890223, r1890668, r1890673
> Support building on Win64/ARM64.
> Justification:
> @@ -64,17 +52,6 @@ Candidate changes:
>  Veto-blocked changes:
>  =
>
> - * r1881534, r1883388
> -   Fix issue #4864 "build/ac-macros/macosx.m4: workaround AC_RUN_IFELSE"
> -   Justification:
> - Unblocks cross-compiling SVN.
> -   Notes:
> - Replacement nomination above (the 1.14.x-r1881534-no-crlf branch)
> -   Votes:
> - +1: hartmannathan
> - -1: brane (contains CRLF line endings, needs svn:eol-style + fixup)
> -   (+1 once that is fixed)
> -
>   * r1897441
> swig-py: Fix cleanup failing in unit tests with Python 3 on Windows.
> Justification:
> @@ -122,3 +99,15 @@ Approved changes:
>   Reduce code duplication between APR and SVN.
> Votes:
>   +1: brane, jun66j5, markphip
> +
> + * r1881534
> +   Fix issue #4864 "build/ac-macros/macosx.m4: workaround AC_RUN_IFELSE"
> +   Justification:
> + Unblocks cross-compiling SVN.
> +   Notes:
> + Replacement for veto-blocked r1881534 group (see below) without the
> + inconsistent line endings that instigated said veto blockage.
> +   Branch:
> + 1.14.x-r1881534-no-crlf
> +   Votes:
> + +1: hartmannathan, stsp, markphip
>
>
>

Re: svn commit: r1899373 - /subversion/branches/1.14.x/STATUS

[Daniel Sahlberg]

So.. backports failed today as well. After some digging I realised
backport.pl didn't pick up the branch in this nomination due to a
whitespace issue in STATUS. I removed one space character on each line and
the backport worked.

However one backport remains in STATUS:

svnsvn@svn-qavm1:~/src/svn/1.14.x$ for i in ~/src/svn/1.*.x; do cd $i &&
$SVN up -q --non-interactive && YES=1 MAY_COMMIT=1 ../trunk/tools/dist/
backport.pl; done
Warning summary
===

1.14.x-r1881534-no-crlf (Fix issue #4864 "build/ac-macros/macosx.m4:
workaround AC_RUN_IFELSE"): Revisions 'r1881534' nominated but not included
in branch
svnsvn@svn-qavm1:~/src/svn/1.14.x$

Can someone check it? I'm ENOTIME to dig into it.

Kind regards,
Daniel


Den ons 30 mars 2022 kl 07:41 skrev :

> Author: dsahlberg
> Date: Wed Mar 30 05:41:19 2022
> New Revision: 1899373
>
> URL: http://svn.apache.org/viewvc?rev=1899373=rev
> Log:
> * STATUS: Adjust whitespace to see if it resolves backport issues
>
> Modified:
> subversion/branches/1.14.x/STATUS
>
> Modified: subversion/branches/1.14.x/STATUS
> URL:
> http://svn.apache.org/viewvc/subversion/branches/1.14.x/STATUS?rev=1899373=1899372=1899373=diff
>
> ==
> --- subversion/branches/1.14.x/STATUS (original)
> +++ subversion/branches/1.14.x/STATUS Wed Mar 30 05:41:19 2022
> @@ -46,13 +46,13 @@ Approved changes:
>  =
>
>   * r1899227
> -Don't show unreadable copyfrom paths in 'svn log -v'
> -Justification:
> -  Makes 'svn log -v' consistent with spec.
> -Branch:
> -  1.14.x-r1899227
> -Votes:
> -  +1: hartmannathan, dsahlberg, rhuijben
> +   Don't show unreadable copyfrom paths in 'svn log -v'
> +   Justification:
> + Makes 'svn log -v' consistent with spec.
> +   Branch:
> + 1.14.x-r1899227
> +   Votes:
> + +1: hartmannathan, dsahlberg, rhuijben
>
>   * r1898633
> Fix sporadic testCrash_RequestChannel_nativeRead_AfterException failure
>
>
>

Re: svn commit: r1899342 - /subversion/site/publish/upcoming.part.html

[Daniel Sahlberg]

Seems Infra didn't manage to merge #1015 before the night jobs. If using
this file as basis of CHANGES, please verify what changes was already done
in 1.14.1.

On the bright side, it seems that all cronjobs are actually running as
expected on the new svn-qavm instance.

/Daniel


Den tis 29 mars 2022 kl 06:15 skrev :

> Author: svn-role
> Date: Tue Mar 29 04:15:02 2022
> New Revision: 1899342
>
> URL: http://svn.apache.org/viewvc?rev=1899342=rev
> Log:
> * upcoming.part.html: Automatically regenerated
>
> Modified:
> subversion/site/publish/upcoming.part.html
>
> Modified: subversion/site/publish/upcoming.part.html
> URL:
> http://svn.apache.org/viewvc/subversion/site/publish/upcoming.part.html?rev=1899342=1899341=1899342=diff
>
> ==
> --- subversion/site/publish/upcoming.part.html (original)
> +++ subversion/site/publish/upcoming.part.html Tue Mar 29 04:15:02 2022
> @@ -2,6 +2,470 @@
>  
>  Changes in ^/subversion/branches/1.14.x:
>  
> +https://svn.apache.org/r1877978;>r1877978 | svn-role |
> 2020-05-21 04:00:13 + (Thu, 21 May 2020) | 7 lines
> +
> +Merge https://svn.apache.org/r1877788;>r1877788 from trunk:
> +
> + * https://svn.apache.org/r1877788;>r1877788
> +   Fix a broken link in a docstring.
> +   Votes:
> + +1: danielsh, stsp
> +
> +
> +https://svn.apache.org/r1878211;>r1878211 | svn-role |
> 2020-05-28 04:00:12 + (Thu, 28 May 2020) | 10 lines
> +
> +Merge https://svn.apache.org/r1877072;>r1877072 from trunk:
> +
> + * https://svn.apache.org/r1877072;>r1877072
> +   svnmucc: Change an error message to state another possible cause of the
> +   error.
> +   Justification:
> + Error messages should be accurate.  User reported ( href="/issue-4854">issue #4854).
> +   Votes:
> + +1: danielsh, stsp, jcorvel
> +
> +
> +https://svn.apache.org/r1878213;>r1878213 | svn-role |
> 2020-05-28 04:00:16 + (Thu, 28 May 2020) | 11 lines
> +
> +Merge https://svn.apache.org/r1877259;>r1877259 from trunk:
> +
> +* https://svn.apache.org/r1877259;>r1877259
> +Move variable declarations to the start of block the to fix
> +syntax errors with VC9 (Visual Studio 2008).
> +  Justification:
> +Our code should be C90.
> +  Votes:
> ++1: brane, stsp, jcorvel
> ++0: danielsh (from dev@)
> +
> +
> +https://svn.apache.org/r1878415;>r1878415 | svn-role |
> 2020-06-03 04:00:20 + (Wed, 03 Jun 2020) | 12 lines
> +
> +Merge the https://svn.apache.org/r1876707;>r1876707 group
> from trunk:
> +
> + * https://svn.apache.org/r1876707;>r1876707, https://svn.apache.org/r1876734;>r1876734, https://svn.apache.org/r1877318;>r1877318, https://svn.apache.org/r1877712;>r1877712, https://svn.apache.org/r1878141;>r1878141, https://svn.apache.org/r1878142;>r1878142, https://svn.apache.org/r1878143;>r1878143,
> +   https://svn.apache.org/r1878144;>r1878144
> +   Various fixes for making the test suite run correctly with Python 3 on
> +   Windows.
> +   Justification:
> + Our test suite should test Subversion correctly also on Windows with
> + Python 3
> +   Votes:
> + +1: futatuki, jcorvel, stsp
> +
> +
> +https://svn.apache.org/r1879245;>r1879245 | svn-role |
> 2020-06-27 04:00:12 + (Sat, 27 Jun 2020) | 11 lines
> +
> +Merge https://svn.apache.org/r1876662;>r1876662 from trunk:
> +
> + * https://svn.apache.org/r1876662;>r1876662
> +   Avoid check for SWIG version for Python bindings when --without-swig is
> +   passed.
> +   Justification:
> + SWIG python bindings should be able to be built without SWIG when we
> use
> + the release tarball
> +   Votes:
> + +1: futatuki, stsp, rhuijben
> +
> +
> +https://svn.apache.org/r1879246;>r1879246 | svn-role |
> 2020-06-27 04:00:17 + (Sat, 27 Jun 2020) | 10 lines
> +
> +Merge https://svn.apache.org/r1876906;>r1876906 from trunk:
> +
> + * https://svn.apache.org/r1876906;>r1876906
> +   Make gen-make.py --debug work with Python 3
> +   Justification:
> + We should also be able to build in Debug configuration with Python 3
> + on Windows.
> +   Votes:
> + +1: jcorvel, stsp, rhuijben
> +
> +
> +https://svn.apache.org/r1879797;>r1879797 | svn-role |
> 2020-07-12 04:00:12 + (Sun, 12 Jul 2020) | 10 lines
> +
> +Merge https://svn.apache.org/r1876410;>r1876410 from trunk:
> +
> + * https://svn.apache.org/r1876410;>r1876410
> +   Fix the .editorconfig stanza for Makefiles.
> +   Justification:
> + Make $EDITOR do the right thing on any backport 

Re: svn commit: r1899324 - /subversion/site/publish/upcoming.part.html

[Daniel Sahlberg]

Den mån 28 mars 2022 kl 22:04 skrev Mark Phippard :

> What is this file used for? Is it displayed on the website somewhere?
>

Yes, it is included in the release-notes page (via an SSI #include):
https://subversion.apache.org/docs/release-notes/

It is just showing merged changes since the last release? So I guess
> could help us write CHANGES?
>

Yes, it should only show merged changes since last release. It didn't work
properly and showed changes since 1.14.0 but I hope it should be alright
now. It is generated by site/tools/generate-upcoming-changes-log.sh (you
should be able to run it locally, but make sure that `cwd` is in the 1.14.x
branch). And yes, it would probably be a good starting point for CHANGES.

/Daniel

Re: svn commit: r1899324 - /subversion/site/publish/upcoming.part.html

[Daniel Sahlberg]

Once again I've executed this manually to make sure it correctly reflects
the upcoming changes between 1.14.1 and 1.14.2. I hope infra will be able
to merge my PR before 04.00Z tomorrow when the cronjobs are executed.

Den mån 28 mars 2022 kl 21:56 skrev :

> Author: svn-role
> Date: Mon Mar 28 19:56:19 2022
> New Revision: 1899324
>
> URL: http://svn.apache.org/viewvc?rev=1899324=rev
> Log:
> * upcoming.part.html: Automatically regenerated
>
> Modified:
> subversion/site/publish/upcoming.part.html
>
> Modified: subversion/site/publish/upcoming.part.html
> URL:
> http://svn.apache.org/viewvc/subversion/site/publish/upcoming.part.html?rev=1899324=1899323=1899324=diff
>
> ==
> --- subversion/site/publish/upcoming.part.html (original)
> +++ subversion/site/publish/upcoming.part.html Mon Mar 28 19:56:19 2022
> @@ -2,470 +2,6 @@
>  
>  Changes in ^/subversion/branches/1.14.x:
>  
> -https://svn.apache.org/r1877978;>r1877978 | svn-role |
> 2020-05-21 04:00:13 + (Thu, 21 May 2020) | 7 lines
> -
> -Merge https://svn.apache.org/r1877788;>r1877788 from trunk:
> -
> - * https://svn.apache.org/r1877788;>r1877788
> -   Fix a broken link in a docstring.
> -   Votes:
> - +1: danielsh, stsp
> -
> -
> -https://svn.apache.org/r1878211;>r1878211 | svn-role |
> 2020-05-28 04:00:12 + (Thu, 28 May 2020) | 10 lines
> -
> -Merge https://svn.apache.org/r1877072;>r1877072 from trunk:
> -
> - * https://svn.apache.org/r1877072;>r1877072
> -   svnmucc: Change an error message to state another possible cause of the
> -   error.
> -   Justification:
> - Error messages should be accurate.  User reported ( href="/issue-4854">issue #4854).
> -   Votes:
> - +1: danielsh, stsp, jcorvel
> -
> -
> -https://svn.apache.org/r1878213;>r1878213 | svn-role |
> 2020-05-28 04:00:16 + (Thu, 28 May 2020) | 11 lines
> -
> -Merge https://svn.apache.org/r1877259;>r1877259 from trunk:
> -
> -* https://svn.apache.org/r1877259;>r1877259
> -Move variable declarations to the start of block the to fix
> -syntax errors with VC9 (Visual Studio 2008).
> -  Justification:
> -Our code should be C90.
> -  Votes:
> -+1: brane, stsp, jcorvel
> -+0: danielsh (from dev@)
> -
> -
> -https://svn.apache.org/r1878415;>r1878415 | svn-role |
> 2020-06-03 04:00:20 + (Wed, 03 Jun 2020) | 12 lines
> -
> -Merge the https://svn.apache.org/r1876707;>r1876707 group
> from trunk:
> -
> - * https://svn.apache.org/r1876707;>r1876707, https://svn.apache.org/r1876734;>r1876734, https://svn.apache.org/r1877318;>r1877318, https://svn.apache.org/r1877712;>r1877712, https://svn.apache.org/r1878141;>r1878141, https://svn.apache.org/r1878142;>r1878142, https://svn.apache.org/r1878143;>r1878143,
> -   https://svn.apache.org/r1878144;>r1878144
> -   Various fixes for making the test suite run correctly with Python 3 on
> -   Windows.
> -   Justification:
> - Our test suite should test Subversion correctly also on Windows with
> - Python 3
> -   Votes:
> - +1: futatuki, jcorvel, stsp
> -
> -
> -https://svn.apache.org/r1879245;>r1879245 | svn-role |
> 2020-06-27 04:00:12 + (Sat, 27 Jun 2020) | 11 lines
> -
> -Merge https://svn.apache.org/r1876662;>r1876662 from trunk:
> -
> - * https://svn.apache.org/r1876662;>r1876662
> -   Avoid check for SWIG version for Python bindings when --without-swig is
> -   passed.
> -   Justification:
> - SWIG python bindings should be able to be built without SWIG when we
> use
> - the release tarball
> -   Votes:
> - +1: futatuki, stsp, rhuijben
> -
> -
> -https://svn.apache.org/r1879246;>r1879246 | svn-role |
> 2020-06-27 04:00:17 + (Sat, 27 Jun 2020) | 10 lines
> -
> -Merge https://svn.apache.org/r1876906;>r1876906 from trunk:
> -
> - * https://svn.apache.org/r1876906;>r1876906
> -   Make gen-make.py --debug work with Python 3
> -   Justification:
> - We should also be able to build in Debug configuration with Python 3
> - on Windows.
> -   Votes:
> - +1: jcorvel, stsp, rhuijben
> -
> -
> -https://svn.apache.org/r1879797;>r1879797 | svn-role |
> 2020-07-12 04:00:12 + (Sun, 12 Jul 2020) | 10 lines
> -
> -Merge https://svn.apache.org/r1876410;>r1876410 from trunk:
> -
> - * https://svn.apache.org/r1876410;>r1876410
> -   Fix the .editorconfig stanza for Makefiles.
> -   Justification:
> - Make $EDITOR do the right thing on any backport branches we may
> create
> - off this stabilization 

Re: svn commit: r1899276 - /subversion/site/publish/upcoming.part.html

[Daniel Sahlberg]

Den mån 28 mars 2022 kl 09:55 skrev Daniel Sahlberg <
daniel.l.sahlb...@gmail.com>:

> This commit doesn't look correct.
>
> I executed the generate-upcoming-changes-log.sh manually yesterday and it
> created r1899244, removing a lot of log entries belonging to 1.14.1. This
> commit (which was executed by cron) restores them.
>
> The crontab entry is:
> [[[
> # Puppet Name: Update our upcoming changes list
> SVN=svn
> 15 4 * * * chronic ~/src/svn/site/tools/generate-upcoming-changes-log.sh
> ]]]
>
> The script begins with a comment
> [[[
> # This should be run from the root of a branches/1.{9,10,11}.x working
> copy.
> ]]]
>
> I suppose the crontab command should be changed to:
> cd ~/src/svn/1.14.x && chronic
> ~/src/svn/site/tools/generate-upcoming-changes-log.sh
>

So I've investigated this further and my initial analysis seems correct.

This is what happens:
* generate-upcoming-changes-log.sh determines last patch release number and
generates upcoming.part.html based on all commits since that patch release
was tagged.
* It has two different ways to determine "the last patch release":
   * If `cwd` is a WC it look in the subversion/include/svn_version.h
   * Else look in https://dist.apache.org/repos/dist/release/subversion/
* The logic looking at dists.a.o selected the oldest patch release
available on dists.a.o, in case there are more than one.
* The crontab entry executed generate-upcoming-changes-log.sh from ~, thus
forcing a lookup from dists.a.o

Currently, both 1.14.0 and 1.14.1 are available on dists.a.o. Thus it
emitted all merged changes since 1.14.0, while expected behaviour (of
upcoming.part.html) would be to only display merged changes since 1.14.1.

I've pushed a change in puppet to the crontab entry as suggested above.
This should solve the problem for now. When branching 1.15.x, we need to
update this crontab entry.

I don't have time right now to look at generating separate
upcoming.$VERSION.part.html files for the supported versions, but I will
leave it on the todo list.

/Daniel

Re: svn commit: r1899276 - /subversion/site/publish/upcoming.part.html

[Daniel Sahlberg]

Den mån 28 mars 2022 kl 13:29 skrev Nathan Hartman :

> On Mon, Mar 28, 2022 at 3:55 AM Daniel Sahlberg <
> daniel.l.sahlb...@gmail.com> wrote:
>
>> This commit doesn't look correct.
>>
>> I executed the generate-upcoming-changes-log.sh manually yesterday and it
>> created r1899244, removing a lot of log entries belonging to 1.14.1. This
>> commit (which was executed by cron) restores them.
>>
>> The crontab entry is:
>> [[[
>> # Puppet Name: Update our upcoming changes list
>> SVN=svn
>> 15 4 * * * chronic ~/src/svn/site/tools/generate-upcoming-changes-log.sh
>> ]]]
>>
>> The script begins with a comment
>> [[[
>> # This should be run from the root of a branches/1.{9,10,11}.x working
>> copy.
>> ]]]
>>
>> I suppose the crontab command should be changed to:
>> cd ~/src/svn/1.14.x && chronic
>> ~/src/svn/site/tools/generate-upcoming-changes-log.sh
>>
>> However that will create an "upcoming" only for 1.14 and not for 1.10.
>> Any thoughts
>>
>
>
> We don't really have a place on the release notes page for "upcoming" for
> two different major lines. For now it probably makes sense to show it for
> 1.14.x only, but when 1.15 is released we'll have to decide whether to show
> "upcoming" for just 1.15 or separately for 1.14 and 1.15.
>

(y)

It should be fairly simple to run the script twice (with a version
argument) and generate two separate upcoming.$VERSION.part.html and
referencing from the website. I feel this being an itch for me and I'll see
if I can find some time to scratch for 1.10 and 1.14. It might be good to
have a framework for the future even if 1.10 is approaching EOL.


> Regarding things disappearing and reappearing, some time ago I noticed
> that if an error occurs in the script, such as it can't reach the repo,
> then it fails to generate any text but proceeds to commit unconditionally.
> I don't remember if that was ever fixed.
>

I saw that as well but in this case there are merges from 2020 showing up
in "upcoming". These changes were part of 1.14.1.

I'll try again to run the script manually, noting the `cwd` each time and
see what happens. There may be some spurious commit messages while I'm
doing this.

I'll also try to figure out what to do in case of problems reaching the
repo.

Kind regards,
Daniel

Re: svn commit: r1899247 - /subversion/branches/1.13.x/STATUS

[Daniel Sahlberg]

Den mån 28 mars 2022 kl 02:33 skrev Daniel Shahaf :

> Daniel Sahlberg wrote on Sun, 27 Mar 2022 23:30 +00:00:
> > Den sön 27 mars 2022 kl 19:37 skrev Daniel Shahaf <
> d...@daniel.shahaf.name>:
> >
> >> Thanks for these two changes!  The information is duplicated in
> >> <https://subversion.apache.org/docs/release-notes/#supported-versions>;
> >> anyone wants to fix that, too?  (Also, 1.14.x is absent from there.)
> >>
> >
> > Done (r1899267). This should be quite straight forward and could be
> merged
> > right away. Thanks for pointing out!
> >
>
> Thanks for fixing it.
>
> I wonder whether we should add "1.15.x | Not yet supported" to that table.
>

-0:  1.15 doesn't even exist yet and /trunk is never "supported". I think
we can add it when we branch.

> I also made some additional changes in roadmap.html (r1899268). This could
> > probably be discussed a bit more but the "out of date" and eted
> > sections doesn't look nice.
>
> All I have to say is that it'd be nice to keep somewhere either
> a working example of those CSS classes or documentation of them… even if
> it's just "Refer to roadmap.html@r1899267" :-)
>

#todo is used in several other places. I don't know if we have specific CSS
for .

This was a little bit of a flame bait to see if anyone else has an opinion
on the eted table.

Kind regards,
Daniel

Re: svn commit: r1899276 - /subversion/site/publish/upcoming.part.html

[Daniel Sahlberg]

This commit doesn't look correct.

I executed the generate-upcoming-changes-log.sh manually yesterday and it
created r1899244, removing a lot of log entries belonging to 1.14.1. This
commit (which was executed by cron) restores them.

The crontab entry is:
[[[
# Puppet Name: Update our upcoming changes list
SVN=svn
15 4 * * * chronic ~/src/svn/site/tools/generate-upcoming-changes-log.sh
]]]

The script begins with a comment
[[[
# This should be run from the root of a branches/1.{9,10,11}.x working copy.
]]]

I suppose the crontab command should be changed to:
cd ~/src/svn/1.14.x && chronic
~/src/svn/site/tools/generate-upcoming-changes-log.sh

However that will create an "upcoming" only for 1.14 and not for 1.10. Any
thoughts?

Kind regards,
Daniel


Den mån 28 mars 2022 kl 06:15 skrev :

> Author: svn-role
> Date: Mon Mar 28 04:15:01 2022
> New Revision: 1899276
>
> URL: http://svn.apache.org/viewvc?rev=1899276=rev
> Log:
> * upcoming.part.html: Automatically regenerated
>
> Modified:
> subversion/site/publish/upcoming.part.html
>
> Modified: subversion/site/publish/upcoming.part.html
> URL:
> http://svn.apache.org/viewvc/subversion/site/publish/upcoming.part.html?rev=1899276=1899275=1899276=diff
>
> ==
> --- subversion/site/publish/upcoming.part.html (original)
> +++ subversion/site/publish/upcoming.part.html Mon Mar 28 04:15:01 2022
> @@ -2,6 +2,470 @@
>  
>  Changes in ^/subversion/branches/1.14.x:
>  
> +https://svn.apache.org/r1877978;>r1877978 | svn-role |
> 2020-05-21 04:00:13 + (Thu, 21 May 2020) | 7 lines
> +
> +Merge https://svn.apache.org/r1877788;>r1877788 from trunk:
> +
> + * https://svn.apache.org/r1877788;>r1877788
> +   Fix a broken link in a docstring.
> +   Votes:
> + +1: danielsh, stsp
> +
> +
> +https://svn.apache.org/r1878211;>r1878211 | svn-role |
> 2020-05-28 04:00:12 + (Thu, 28 May 2020) | 10 lines
> +
> +Merge https://svn.apache.org/r1877072;>r1877072 from trunk:
> +
> + * https://svn.apache.org/r1877072;>r1877072
> +   svnmucc: Change an error message to state another possible cause of the
> +   error.
> +   Justification:
> + Error messages should be accurate.  User reported ( href="/issue-4854">issue #4854).
> +   Votes:
> + +1: danielsh, stsp, jcorvel
> +
> +
> +https://svn.apache.org/r1878213;>r1878213 | svn-role |
> 2020-05-28 04:00:16 + (Thu, 28 May 2020) | 11 lines
> +
> +Merge https://svn.apache.org/r1877259;>r1877259 from trunk:
> +
> +* https://svn.apache.org/r1877259;>r1877259
> +Move variable declarations to the start of block the to fix
> +syntax errors with VC9 (Visual Studio 2008).
> +  Justification:
> +Our code should be C90.
> +  Votes:
> ++1: brane, stsp, jcorvel
> ++0: danielsh (from dev@)
> +
> +
> +https://svn.apache.org/r1878415;>r1878415 | svn-role |
> 2020-06-03 04:00:20 + (Wed, 03 Jun 2020) | 12 lines
> +
> +Merge the https://svn.apache.org/r1876707;>r1876707 group
> from trunk:
> +
> + * https://svn.apache.org/r1876707;>r1876707, https://svn.apache.org/r1876734;>r1876734, https://svn.apache.org/r1877318;>r1877318, https://svn.apache.org/r1877712;>r1877712, https://svn.apache.org/r1878141;>r1878141, https://svn.apache.org/r1878142;>r1878142, https://svn.apache.org/r1878143;>r1878143,
> +   https://svn.apache.org/r1878144;>r1878144
> +   Various fixes for making the test suite run correctly with Python 3 on
> +   Windows.
> +   Justification:
> + Our test suite should test Subversion correctly also on Windows with
> + Python 3
> +   Votes:
> + +1: futatuki, jcorvel, stsp
> +
> +
> +https://svn.apache.org/r1879245;>r1879245 | svn-role |
> 2020-06-27 04:00:12 + (Sat, 27 Jun 2020) | 11 lines
> +
> +Merge https://svn.apache.org/r1876662;>r1876662 from trunk:
> +
> + * https://svn.apache.org/r1876662;>r1876662
> +   Avoid check for SWIG version for Python bindings when --without-swig is
> +   passed.
> +   Justification:
> + SWIG python bindings should be able to be built without SWIG when we
> use
> + the release tarball
> +   Votes:
> + +1: futatuki, stsp, rhuijben
> +
> +
> +https://svn.apache.org/r1879246;>r1879246 | svn-role |
> 2020-06-27 04:00:17 + (Sat, 27 Jun 2020) | 10 lines
> +
> +Merge https://svn.apache.org/r1876906;>r1876906 from trunk:
> +
> + * https://svn.apache.org/r1876906;>r1876906
> +   Make gen-make.py --debug work with Python 3
> +   Justification:
> + We should also be able to build in Debug configuration with Python 3
> + on Windows.
> +   

Re: svn commit: r1899275 - /subversion/site/publish/.message-ids.tsv

[Daniel Sahlberg]

Anyone got an idea why the URL list was sorted in a different way on the
new svn-qavm? Not that it is a big difference, but I don't like loose ends.

In either case, I updated the source to use https on the offending link to
(r1899280) so we should see another update tomorrow.

/Daniel

Den mån 28 mars 2022 kl 06:00 skrev :

> Author: svn-role
> Date: Mon Mar 28 04:00:20 2022
> New Revision: 1899275
>
> URL: http://svn.apache.org/viewvc?rev=1899275=rev
> Log:
> * publish/.message-ids.tsv: Automatically regenerated.
>
> Modified:
> subversion/site/publish/.message-ids.tsv
>
> Modified: subversion/site/publish/.message-ids.tsv
> URL:
> http://svn.apache.org/viewvc/subversion/site/publish/.message-ids.tsv?rev=1899275=1899274=1899275=diff
>
> ==
> --- subversion/site/publish/.message-ids.tsv (original)
> +++ subversion/site/publish/.message-ids.tsv Mon Mar 28 04:00:20 2022
> @@ -1,5 +1,6 @@
>  # Message-ids of archived emails that are referenced by a svn.haxx.se
> URL.
> -# Generated by tools/haxx-url-to-message-id.sh on 2021-07-04
> +# Generated by tools/haxx-url-to-message-id.sh on 2022-03-28
> +http://svn.haxx.se/dev/archive-2010-08/0362.shtml
> 4c65756c.8070...@collab.net
>  https://svn.haxx.se/dev/archive-2003-01/1125.shtml
> 20030116213052.314004c1.tt...@idsoftware.com
>  https://svn.haxx.se/dev/archive-2003-02/0068.shtml
> 87wuki4fpy@codematters.co.uk
>  https://svn.haxx.se/dev/archive-2003-10/0136.shtml
> 200310031235.h93czgiv064...@bigtex.jrv.org
> @@ -55,4 +56,3 @@ https://svn.haxx.se/users/archive-2012-0
>  https://svn.haxx.se/users/archive-2012-09/0236.shtml
> 20120921085850.gg24...@ted.stsp.name
>  https://svn.haxx.se/users/archive-2019-04/0041.shtml
> 9739e241-f88c-8a79-11f5-783a7f119...@neuf.fr
>  https://svn.haxx.se/users/archive-2020-04/0040.shtml
> 20200422065424.gl81...@ted.stsp.name
> -http://svn.haxx.se/dev/archive-2010-08/0362.shtml
> 4c65756c.8070...@collab.net
>
>
>

Re: svn commit: r1899247 - /subversion/branches/1.13.x/STATUS

[Daniel Sahlberg]

Den sön 27 mars 2022 kl 19:37 skrev Daniel Shahaf :

> Thanks for these two changes!  The information is duplicated in
> ;
> anyone wants to fix that, too?  (Also, 1.14.x is absent from there.)
>

Done (r1899267). This should be quite straight forward and could be merged
right away. Thanks for pointing out!

I also made some additional changes in roadmap.html (r1899268). This could
probably be discussed a bit more but the "out of date" and eted
sections doesn't look nice.

/Daniel

Re: svn commit: r1899249 - /subversion/branches/1.14.x/STATUS

[Daniel Sahlberg]

Den sön 27 mars 2022 kl 19:00 skrev :

> Author: dsahlberg
> Date: Sun Mar 27 16:59:59 2022
> New Revision: 1899249
>
> URL: http://svn.apache.org/viewvc?rev=1899249=rev
> Log:
> * STATUS: Block r1897441 since it doesn't apply cleanly
>
> Modified:
> subversion/branches/1.14.x/STATUS
>
> Modified: subversion/branches/1.14.x/STATUS
> URL:
> http://svn.apache.org/viewvc/subversion/branches/1.14.x/STATUS?rev=1899249=1899248=1899249=diff
>
> ==
> --- subversion/branches/1.14.x/STATUS (original)
> +++ subversion/branches/1.14.x/STATUS Sun Mar 27 16:59:59 2022
> @@ -105,15 +105,16 @@ Veto-blocked changes:
>   -1: brane (contains CRLF line endings, needs svn:eol-style + fixup)
> (+1 once that is fixed)
>
> -Approved changes:
> -=
> -
>   * r1897441
> swig-py: Fix cleanup failing in unit tests with Python 3 on Windows.
> Justification:
>   Make check-swig-py passed.
> Votes:
>   +1: jun66j5, markphip
> + -1: dsahlberg (doesn't apply cleanly, +0 once fixed)
> +
> +Approved changes:
> +=
>
>   * r1886708
> swig-py: Fix dependency of make copy-swig-py target.
>
>
It seems that r1897441 require at least r1885008 (I havn't analyzed
r1886858 and r1886872) since the test fixed in r1897441 was added in
r1885008.

/Daniel

Re: svn commit: r1898524 - in /subversion/trunk/subversion: svn/help-cmd.c tests/cmdline/getopt_tests_data/svn--version--verbose_stdout tests/cmdline/getopt_tests_data/svn--version_stdout

[Daniel Sahlberg]

Den ons 2 mars 2022 12:04  skrev:

> Modified:
> subversion/trunk/subversion/tests/cmdline/getopt_tests_data/svn--version_stdout
> URL:
> http://svn.apache.org/viewvc/subversion/trunk/subversion/tests/cmdline/getopt_tests_data/svn--version_stdout?rev=1898524=1898523=1898524=diff
>
> ==
> ---
> subversion/trunk/subversion/tests/cmdline/getopt_tests_data/svn--version_stdout
> (original)
> +++
> subversion/trunk/subversion/tests/cmdline/getopt_tests_data/svn--version_stdout
> Wed Mar  2 11:04:31 2022
> @@ -1,15 +1,15 @@
>  svn, version 1.9.0-dev (under development)
> compiled Feb 26 2014, 15:15:42 on x86_64-unknown-openbsd5.5
>
> -Copyright (C) 2014 The Apache Software Foundation.
> +Copyright (C) 2012 The Apache Software Foundation.
>  This software consists of contributions made by many people;
>  see the NOTICE file for more information.
>  Subversion is open source software, see http://subversion.apache.org/
>
>  Supported working copy (WC) formats:
>
> -* compatible with Subversion v1.8 to v1.15 (WC format 31)
> -* compatible with Subversion v1.15 (WC format 32)
> +* WC format 31, compatible with Subversion v1.8 and newer
> +* WC format 32, compatible with Subversion v1.15 and newer
>
>  The following repository access (RA) modules are available:
>

Should the following lines also be removed from
subversion/tests/cmdline/getopt_tests.py (line numbers as of r1898187)? It
seems this was in the output previously but was remove a few revisions ago
so I dont think it has to be in the regex

103  # In svn --version, the supported WC versions vary.
104  (re.compile(r'^Supported working copy (WC)
version.*$'),
105       'Supported working copy (WC) versions: from X.Y to
X.Y')

Kind regards
Daniel Sahlberg

(This was not strictly caused by this commit but I couldnt find the
original mail right now)

>

Re: svn commit: r1897133 - /subversion/trunk/subversion/tests/cmdline/log_tests.py

[Daniel Sahlberg]

Den tis 25 jan. 2022 kl 15:40 skrev Daniel Shahaf :

> Daniel Sahlberg wrote on Tue, 25 Jan 2022 13:29 +00:00:
> > Oh. That is interesting, I never thought about running the checks on svn
> > and dav. Is there a way to flag the test as "only xfails on local", and
> can
> > someone help me do this? I'm a bit short on time right now.
>
> r1897457.
>

Thanks!

/Daniel

Re: svn commit: r1897133 - /subversion/trunk/subversion/tests/cmdline/log_tests.py

[Daniel Sahlberg]

Den tis 25 jan. 2022 kl 14:21 skrev Julian Foad :

>
>
> On Jan 25 2022, at 1:15 pm, Julian Foad  wrote:
>
> > Daniel Shahaf wrote:
> >> dsahlb...@apache.org wrote on Sun, 16 Jan 2022 19:19 +00:00:
> >>> Add a test for issue #4856, "invalid xml file produced by: svn log
> --xml
> >>> --use-merge-history".
> >>
> >> The new test XFails for me over ra_local but XPasses over
> >> svnserveautocheck and davautocheck.
> >
> > On the 'pristines-on-demand' branch I get XFAIL over all three
>
> Oops, no, that was the wrong test ('log --use-merge-history --search
> [#4711]').
>
> I DO confirm
>
> XPASS: log_tests.py 47: log --use-merge-history --xml


> with RA-svn/serf on trunk.
>

Oh. That is interesting, I never thought about running the checks on svn
and dav. Is there a way to flag the test as "only xfails on local", and can
someone help me do this? I'm a bit short on time right now.

Thanks,
Daniel Sahlberg

Re: svn commit: r1896898 - /subversion/branches/1.14.x/STATUS

[Daniel Sahlberg]

Den mån 10 jan. 2022 kl 22:45 skrev :

> Author: dsahlberg
> Date: Mon Jan 10 21:45:27 2022
> New Revision: 1896898
>
> URL: http://svn.apache.org/viewvc?rev=1896898=rev
> Log:
> * STATUS: Vote for r1896877
>
>
> Modified:
> subversion/branches/1.14.x/STATUS
>
> Modified: subversion/branches/1.14.x/STATUS
> URL:
> http://svn.apache.org/viewvc/subversion/branches/1.14.x/STATUS?rev=1896898=1896897=1896898=diff
>
> ==
> --- subversion/branches/1.14.x/STATUS (original)
> +++ subversion/branches/1.14.x/STATUS Mon Jan 10 21:45:27 2022
> @@ -120,7 +120,7 @@ Candidate changes:
>  Justification:
>Documentation should be correct.
>  Votes:
> -  +1: stsp
> +  +1: stsp, dsahlberg
>
>  Veto-blocked changes:
>  =
>
>
>
As far as I understand it, this change require three (or two, for a
non-LTS) votes, even though this is only a documentation fix, right?

/Daniel

Re: svn commit: r1896485 - /subversion/site/staging/download.html

[Daniel Sahlberg]

Den ons 5 jan. 2022 kl 16:22 skrev Nathan Hartman :

> Interesting. On publish, previously the "Other mirrors" list was
> showing me dlcdn.a.o for both the main and backup.
>
> As of right now, I am getting two options on publish:
> https://dlcdn.apache.org/
> https://downloads.apache.org/ (backup)
>
> While on staging, I am only getting
> https://dlcdn.apache.org/
>
> So, I think it might be a good idea to revert this change and let
> Infra manage how they supply those arrays; if it seems as though
> they're providing an incorrect listing, it should be fixed on their
> end because that will affect all projects, not just Subversion.
>

Done, in r1896725.


> The removal of "You may consult the complete list of mirrors" link
> should *not* be reverted. That page is now a 404.
>

That was a separate commit (for easy reverting :-) ).

I think we should now merge staging => publish, everything looks good to
me. Do you want to check and do the honors?

/Daniel

Re: svn commit: r1896485 - /subversion/site/staging/download.html

[Daniel Sahlberg]

Den tis 28 dec. 2021 kl 21:14 skrev :

> Author: dsahlberg
> Date: Tue Dec 28 20:14:17 2021
> New Revision: 1896485
>
> URL: http://svn.apache.org/viewvc?rev=1896485=rev
> Log:
> In site/staging: The ASF download script currently return the same site
> for both "http" and "backup" (after the migration to dlcdn.a.o).
>
> * download.html: Avoid displaying the same URL twice in the 
>
> Modified:
> subversion/site/staging/download.html
>
> Modified: subversion/site/staging/download.html
> URL:
> http://svn.apache.org/viewvc/subversion/site/staging/download.html?rev=1896485=1896484=1896485=diff
>
> ==
> --- subversion/site/staging/download.html (original)
> +++ subversion/site/staging/download.html Tue Dec 28 20:14:17 2021
> @@ -73,9 +73,9 @@ Other mirrors:
>[if-any ftp]
>  [for ftp] selected="selected"[end]>[ftp][end]
>[end]
> -  [if-any backup]
> +  [if-any backup][is backup http][else][# Only show backup if different
> from http ]
>  [for backup] selected="selected"[end]>[backup] (backup)[end]
> -  [end]
> +  [end][end]
>  
>  
>  
>

The reasoning behind this change is described in the log message but I'm
not happy about it for a few reasons:
* [http] and [backup] are arrays, so comparing these are probably not a
good idea. I can't come up with anything reasonably simple though.
* The lua version of EZT doesn't seem to support [else] at all. The fact
that it works for me is probably purely accidental.

I have a strong feeling that the download page will not work in case
different URLs are returned from the "closer.lua" script. Please check if
you are getting different lists in [http] and [backup] from
https://subversion-staging.apache.org/download.cgi?as_json=1 (I'm getting
https://dlcdn.apache.org/ on both of these). In that case check if the
 looks reasonable at
https://subversion-staging.apache.org/download.cgi. Also compare with our
published download page at https://subversion.apache.org/download.cgi.

I'm inclined to revert this change and live with the fact that the download
page can look slightly silly (displaying dlcdn.a.o as both the main and the
backup mirror) until ASF Infra check on closer.lua (or someone else find a
more clever way of writing the EZT comparison code).

Kind regards,
Daniel

Re: svn commit: r1892471 - in /subversion/trunk/subversion: libsvn_client/conflicts.c libsvn_wc/wc_db.c tests/cmdline/merge_tree_conflict_tests.py

[Daniel Sahlberg]

Den mån 23 aug. 2021 kl 11:16 skrev Stefan Sperling :

> On Sat, Aug 21, 2021 at 09:38:56PM +0200, Daniel Sahlberg wrote:
> > > @@ -3028,12 +3028,12 @@ conflict_tree_get_details_local_missing(
> > >
> deleted_basename,
> > >conflict->pool);
> > >details->moves = moves;
> > > +  details->wc_move_targets = apr_hash_make(conflict->pool);
> > >if (details->moves != NULL)
> > >  {
> > >apr_pool_t *iterpool;
> > >int i;
> > >
> > > -  details->wc_move_targets = apr_hash_make(conflict->pool);
> > >iterpool = svn_pool_create(scratch_pool);
> > >for (i = 0; i < details->moves->nelts; i++)
> > >  {
> > >
> >
> > I have not investigated further (ENOTIME right now) but I presume some
> > other part of the code expects wc_move_targets to be NULL.
>
> The problem is that some parts of the code try to search the now non-NULL
> hash map with a NULL key because they lack checks for NULL keys.
> I will commit a fix shortly.
>

Thanks!

I can confirm that the test suite now passes.

I'm going to upgrade my vote to +0, not because I have any concerns but
because I don't feel confident enough reviewing the C code to vote +1.

Kind regards,
Daniel Sahlberg

Re: svn commit: r1892471 - in /subversion/trunk/subversion: libsvn_client/conflicts.c libsvn_wc/wc_db.c tests/cmdline/merge_tree_conflict_tests.py

[Daniel Sahlberg]

 conflict->pool);
>details->moves = moves;
> +  details->wc_move_targets = apr_hash_make(conflict->pool);
>if (details->moves != NULL)
>  {
>apr_pool_t *iterpool;
>int i;
>
> -  details->wc_move_targets = apr_hash_make(conflict->pool);
>iterpool = svn_pool_create(scratch_pool);
>for (i = 0; i < details->moves->nelts; i++)
>  {
>

I have not investigated further (ENOTIME right now) but I presume some
other part of the code expects wc_move_targets to be NULL.


> Modified: subversion/trunk/subversion/libsvn_wc/wc_db.c
> URL:
> http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_wc/wc_db.c?rev=1892471=1892470=1892471=diff
>
> ==
> --- subversion/trunk/subversion/libsvn_wc/wc_db.c (original)
> +++ subversion/trunk/subversion/libsvn_wc/wc_db.c Fri Aug 20 12:39:20 2021
> @@ -16732,7 +16732,7 @@ svn_wc__db_find_working_nodes_with_basen
>SVN_ERR(svn_sqlite__get_statement(, wcroot->sdb,
>
>  STMT_SELECT_PRESENT_HIGHEST_WORKING_NODES_BY_BASENAME_AND_KIND));
>SVN_ERR(svn_sqlite__bindf(stmt, "ist", wcroot->wc_id, basename,
> -kind_map, kind));
> +kind_map_none, kind));
>SVN_ERR(svn_sqlite__step(_row, stmt));
>
>*local_abspaths = apr_array_make(result_pool, 1, sizeof(const char *));
> @@ -16776,7 +16776,7 @@ svn_wc__db_find_copies_of_repos_path(apr
>SVN_ERR(svn_sqlite__get_statement(, wcroot->sdb,
>  STMT_SELECT_COPIES_OF_REPOS_RELPATH));
>SVN_ERR(svn_sqlite__bindf(stmt, "ist", wcroot->wc_id, repos_relpath,
> -kind_map, kind));
> +kind_map_none, kind));
>SVN_ERR(svn_sqlite__step(_row, stmt));
>
>*local_abspaths = apr_array_make(result_pool, 1, sizeof(const char *));
>
> Modified:
> subversion/trunk/subversion/tests/cmdline/merge_tree_conflict_tests.py
> URL:
> http://svn.apache.org/viewvc/subversion/trunk/subversion/tests/cmdline/merge_tree_conflict_tests.py?rev=1892471=1892470=1892471=diff
>
> ==
> --- subversion/trunk/subversion/tests/cmdline/merge_tree_conflict_tests.py
> (original)
> +++ subversion/trunk/subversion/tests/cmdline/merge_tree_conflict_tests.py
> Fri Aug 20 12:39:20 2021
> @@ -2364,7 +2364,6 @@ def spurios_tree_conflict_with_added_fil
> [], False, True, '--reintegrate',
> sbox.ospath('A_branch'))
>
> -@XFail()
>  def merge_local_missing_node_kind_none(sbox):
>"crash in resolver triggered by none-type node"
>


Kind regards,
Daniel Sahlberg

Re: svn commit: r1891998 - /subversion/branches/1.14.x/STATUS

[Daniel Sahlberg]

Den lör 14 aug. 2021 14:43Daniel Shahaf  skrev:

> Daniel Sahlberg wrote on Tue, Aug 03, 2021 at 23:44:53 +0200:
> > Den tis 3 aug. 2021 kl 23:40 skrev :
> >
> > > Author: dsahlberg
> > > Date: Tue Aug  3 21:40:40 2021
> > > New Revision: 1891998
> > >
> > > URL: http://svn.apache.org/viewvc?rev=1891998=rev
> > > Log:
> > > * STATUS: Upgrading my vote for r1891908 (now being a full committer).
> > >
> > > Modified:
> > > subversion/branches/1.14.x/STATUS
> > >
> > > Modified: subversion/branches/1.14.x/STATUS
> > > URL:
> > >
> http://svn.apache.org/viewvc/subversion/branches/1.14.x/STATUS?rev=1891998=1891997=1891998=diff
> > >
> > >
> ==
> > > --- subversion/branches/1.14.x/STATUS (original)
> > > +++ subversion/branches/1.14.x/STATUS Tue Aug  3 21:40:40 2021
> > > @@ -96,8 +96,7 @@ Candidate changes:
> > > Justification:
> > >   Small fix.  Prevents spurious hard fails of 'make davautocheck'.
> > > Votes:
> > > - +1: danielsh
> > > - +1 (non-binding): dsahlberg
> > > + +1: danielsh, dsahlberg
> > >
> > >  Veto-blocked changes:
> > >  =
> > >
> >
> >  @Daniel Shahaf  Should this be backported also to
> > 1.10.x? It exhibits the same problem and the same fix applies there. If
> so,
> > I can copy over the same backporting proposal.
>
> Yes.  As you say, mod_dontdothat is a hard dependency of the test suite
> in 1.10.x too, so adding the dependency in Makefile shouldn't break
> anything, even in an LTS branch.  I've taken your email as a +1 to
> backport and added the nomination with both of our votes.
>

Yes, +1 from me. Thanks!

/dsahlberg

Re: svn commit: r1891998 - /subversion/branches/1.14.x/STATUS

[Daniel Sahlberg]

Den tis 3 aug. 2021 kl 23:40 skrev :

> Author: dsahlberg
> Date: Tue Aug  3 21:40:40 2021
> New Revision: 1891998
>
> URL: http://svn.apache.org/viewvc?rev=1891998=rev
> Log:
> * STATUS: Upgrading my vote for r1891908 (now being a full committer).
>
> Modified:
> subversion/branches/1.14.x/STATUS
>
> Modified: subversion/branches/1.14.x/STATUS
> URL:
> http://svn.apache.org/viewvc/subversion/branches/1.14.x/STATUS?rev=1891998=1891997=1891998=diff
>
> ==
> --- subversion/branches/1.14.x/STATUS (original)
> +++ subversion/branches/1.14.x/STATUS Tue Aug  3 21:40:40 2021
> @@ -96,8 +96,7 @@ Candidate changes:
> Justification:
>   Small fix.  Prevents spurious hard fails of 'make davautocheck'.
> Votes:
> - +1: danielsh
> - +1 (non-binding): dsahlberg
> + +1: danielsh, dsahlberg
>
>  Veto-blocked changes:
>  =
>

 @Daniel Shahaf  Should this be backported also to
1.10.x? It exhibits the same problem and the same fix applies there. If so,
I can copy over the same backporting proposal.

Kind regards,
Daniel Sahlberg

Re: svn commit: r1891570 - /subversion/site/staging/style/site.css

[Daniel Sahlberg]

Den fre 16 juli 2021 kl 12:37 skrev Daniel Shahaf :

> dsahlb...@apache.org wrote on Thu, 15 Jul 2021 11:25 +00:00:
> > Found-by: hartmannathan
>
> For future reference, the syntax is "Found by", with a space as opposed
> to a hyphen/minus.  contribulyze.py relies on that space (see «field_re»),
> and we rely on contribulyze.py to track contributions by people
> other than full committers.
>

Fixed, thanks for reminding me. I've reviewed the Crediting section of
HACKING [1], where these are documented.

(In this case it didn't matter since Nathan is full committer, but I have
corrected the log message of a few commits to make sure it is correct in
case anyone else copy the log messages).

[1]
http://subversion.apache.org/docs/community-guide/community-guide.html#crediting

Kind regards,
Daniel Sahlberg

Re: svn commit: r1891237 - in /subversion/site/staging/docs: ./ api/ api/1.13/ api/1.13/search/ api/1.14/ api/1.14/search/ javahl/ javahl/1.13/ javahl/1.13/org/ javahl/1.13/org/apache/ javahl/1.13/org

[Daniel Sahlberg]

Den tis 6 juli 2021 kl 04:25 skrev Nathan Hartman :

> On Mon, Jul 5, 2021 at 9:27 PM Daniel Shahaf 
> wrote:
>
>> Daniel Sahlberg wrote on Sat, Jul 03, 2021 at 23:45:01 +0200:
>> > It seems that the API and JavaHL docs for 1.13 and 1.14 are missing. I
>> have
>> > generated them from the branches.
>>
>> Are there any relevant differences between the branches (@HEAD) and the
>> latest tags on each branch?
>>
> Oh, they probably should have been generated from the latest tags, not the
> branches.
>

Oh, [invective], my bad!

>From my memory, I think all the recent JavaHL work was released and the new
> C APIs (e.g. the parallelization ones) aren't on any release branch. But I
> can verify that when I next reach a real computer unless someone beats me
> to it.
>

I have regenerated the API docs and checked for differences.

In the C API there is one difference: r1881958 (Restore support for
building with APR 1.4) (re-)added a few functions from APR 1.5.0
(apr_hash_this_key, apr_hash_this_key_len, apr_hash_this_val). I'm leaning
towards keeping this because:
- Building with APR >= 1.5.0, the functions are there
- Building with APR < 1.5.0 was not possible in 1.14.0, but builds using
1.14.1 will have these functions.

In Javahl there are no differences.

Thanks for pointing that out.
>

Yes, thanks, and sorry!

Kind regards,
Daniel Sahlberg

Re: svn commit: r1891237 - in /subversion/site/staging/docs: ./ api/ api/1.13/ api/1.13/search/ api/1.14/ api/1.14/search/ javahl/ javahl/1.13/ javahl/1.13/org/ javahl/1.13/org/apache/ javahl/1.13/org

[Daniel Sahlberg]

It seems that the API and JavaHL docs for 1.13 and 1.14 are missing. I have
generated them from the branches.
If it was intentional then this can be reverted.

Kind regards,
Daniel Sahlberg

Den lör 3 juli 2021 kl 23:35 skrev :

> Author: dsahlberg
> Date: Sat Jul  3 21:35:05 2021
> New Revision: 1891237
>
> URL: http://svn.apache.org/viewvc?rev=1891237=rev
> Log:
> In site/staging:
>
> Add API and JavaHL documentation for 1.13 and 1.14
>
>
> [This commit notification would consist of 604 parts,
> which exceeds the limit of 50 ones, so it was shortened to the summary.]
>

Re: svn commit: r1891065 - in /subversion/site/staging-ng: ./ docs/community-guide/ docs/release-notes/ security/

[Daniel Sahlberg]

I think these catchup merges are quite fun to watch since they make a nice
summary of the events that has been going on. :-)

For a summer project I will do some (minor) design work on the website.
Nothing big and professional like  but
at least try to make the site a little bit more mobile friendly. I'm
thinking about adding a responsive stylesheet to fold the menu into a
hamburger on narrow viewports.

I will do this on the staging-ng branch to keep staging open for regular
work and anyone interested would have to setup their own mirror (
http://subversion-staging.apache.org/docs/community-guide/web.html#web_mirror
).

Feel free to comment if you have any ideas of what to do (and not to do)!

Kind regards,
Daniel

Re: svn commit: r1886494 - /subversion/site/staging/docs/community-guide/releasing.part.html

[Daniel Sahlberg]

Den tis 16 feb. 2021 kl 16:20 skrev Daniel Sahlberg <
daniel.l.sahlb...@gmail.com>:

> Den tis 16 feb. 2021 kl 12:44 skrev Daniel Sahlberg
> :
> >> P.S.  While reviewing this I noticed that
> >> https://subversion-staging.apache.org/favicon.ico is different to
> >> https://svn.apache.org/repos/asf/subversion/site/staging/favicon.ico:
> an Apache
> >> feather v. a Subversion logo.
> >
> >
> > Hmm. That is very strange. I've pinged infra on Slack.
>
> Infra says:
> > looks like it's an overall override for "generic sites" that they all
> have the ASF favicon due to the dash in subversion-staging it gets
> overridden
>
> Ie, it is not a fault in our repository but an httpd.conf thing for the
> site.
>
> I asked to have this removed and was requested to add it to Jira:
> https://issues.apache.org/jira/browse/INFRA-21429


It took just short of two months but Infra has changed the override and the
staging site is showing the correct favicon, ie the one in the repository.

Kind regards
Daniel

Re: svn commit: r1886877 - in /subversion/site/staging: index.html news.html

[Daniel Sahlberg]

Hi,
I think this is a fairly obvious fix, but I'd appreciate if someone can
doublecheck the links and give me a +1 for merge.
Kind regards
Daniel

Den ons 24 feb. 2021 kl 10:21 skrev :

> Author: dsahlberg
> Date: Wed Feb 24 09:21:20 2021
> New Revision: 1886877
>
> URL: http://svn.apache.org/viewvc?rev=1886877=rev
> Log:
> In site/staging:
>
> https://lists.apache.org/list.html?annou...@subversion.apache.org will
> show
> announcements made the current month. Thus the links to old release
> announcements doesn't work as expected. Add :-MM at the end of the link
> to show the expected month (in case of multiple announcements) or link to
> the permalink of an individual mail.
>
> * index.html,
>   news.html: Change links
>
> Modified:
> subversion/site/staging/index.html
> subversion/site/staging/news.html
>
> Modified: subversion/site/staging/index.html
> URL:
> http://svn.apache.org/viewvc/subversion/site/staging/index.html?rev=1886877=1886876=1886877=diff
>
> ==
> --- subversion/site/staging/index.html (original)
> +++ subversion/site/staging/index.html Wed Feb 24 09:21:20 2021
> @@ -79,7 +79,7 @@
>   to upgrade to the latest appropriate version as soon as reasonable.
>
>   Please see the  - href="https://lists.apache.org/list.html?annou...@subversion.apache.org;
> + href="
> https://lists.apache.org/list.html?annou...@subversion.apache.org:2021-02;
>   >release announcements for more information about the releases.
>
>  To get the latest release from the nearest mirror, please visit our
> @@ -178,7 +178,7 @@
>   to upgrade to the latest appropriate version as soon as reasonable.
>
>   Please see the  - href="https://lists.apache.org/list.html?annou...@subversion.apache.org;
> + href="
> https://lists.apache.org/list.html?annou...@subversion.apache.org:2019-07;
>   >release announcements for more information about the releases.
>
>  To get the latest release from the nearest mirror, please visit our
>
> Modified: subversion/site/staging/news.html
> URL:
> http://svn.apache.org/viewvc/subversion/site/staging/news.html?rev=1886877=1886876=1886877=diff
>
> ==
> --- subversion/site/staging/news.html (original)
> +++ subversion/site/staging/news.html Wed Feb 24 09:21:20 2021
> @@ -35,7 +35,7 @@
>   to upgrade to the latest appropriate version as soon as reasonable.
>
>   Please see the  - href="https://lists.apache.org/list.html?annou...@subversion.apache.org;
> + href="
> https://lists.apache.org/list.html?annou...@subversion.apache.org:2021-02;
>   >release announcements for more information about the releases.
>
>  To get the latest release from the nearest mirror, please visit our
> @@ -153,7 +153,7 @@
>   This is the most complete Subversion release to date, and we encourage
>   users of Subversion to upgrade as soon as reasonable.
>   Please see the
> - https://lists.apache.org/list.html?annou...@subversion.apache.org;
> + https://lists.apache.org/thread.html/d733f432caa4c629766e8cadb4a35eec25e1362480c883f4132b1522%40%3Cannounce.subversion.apache.org%3E
> "
>   >release announcement and the
>  >release notes for more information about this release.
> @@ -173,7 +173,7 @@
>   release is not intended for production use, but is provided as a
> milestone
>   to encourage wider testing and feedback from intrepid users and
> maintainers.
>   Please see the
> - https://lists.apache.org/list.html?annou...@subversion.apache.org;>release
> + https://lists.apache.org/thread.html/7e9a2e4fec844334d6a3eb4dfcd936e22f0a0883755a9bd1423d1251%40%3Cannounce.subversion.apache.org%3E
> ">release
>   announcement for more information about this release, and the
>   release notes and
>   https://svn.apache.org/repos/asf/subversion/tags/1.13.0-rc1/CHANGES;>
> @@ -199,7 +199,7 @@
>   to upgrade to the latest appropriate version as soon as reasonable.
>
>   Please see the  - href="https://lists.apache.org/list.html?annou...@subversion.apache.org;
> + href="
> https://lists.apache.org/list.html?annou...@subversion.apache.org:2019-07;
>   >release announcements for more information about the releases.
>
>  To get the latest release from the nearest mirror, please visit our
> @@ -217,8 +217,8 @@
>   This is the most complete release of the 1.12.x line to date,
>   and we encourage all users to upgrade as soon as reasonable.
>   Please see the
> - https://lists.apache.org/list.html?annou...@subversion.apache.org;
> - >release announcement and the release notes (
> + https://lists.apache.org/list.html?annou...@subversion.apache.org:2019-07;
> + >release announcements and the release notes (
>   1.12,
>   1.10,
>   1.9)
> @@ -239,7 +239,7 @@
>   This is the most complete release of the 1.12.x line to date,
>   and we encourage all users to upgrade as soon as reasonable.
>   Please see the
> - https://lists.apache.org/list.html?annou...@subversion.apache.org;
> + 

Re: svn commit: r1886396 - in /subversion/site/publish: ./ doap.rdf docs/release-notes/release-history.html download.html

[Daniel Sahlberg]

Den ons 17 feb. 2021 19:42Daniel Shahaf  skrev:

> Daniel Sahlberg wrote on Wed, Feb 17, 2021 at 09:46:54 +0100:
> > Den tis 16 feb. 2021 kl 21:37 skrev Daniel Shahaf <
> d...@daniel.shahaf.name>:
> > > Is it worthwhile to automate this step?  doap.rdf changes rarely enough
> > > that we needn't bother with "edit part of a file" logic; we can just
> > > regenerate the entire file and «svnmucc put» it into place, with a
> > > comment indicating it's a generated file.
> >
> > The doap.rdf contain references to two separate releases (at least
> > right now) and when running release.py you are working on one release
> > at a time. So we can't just have a template and add the current
> > release number, we also need to know the other release (which could
> > have been a year ago or the same day).
>
> Well, yes, and «release.py clean-dist» already has logic to determine
> the other release's version number.
>
> > To automate "edit part of file", we would need to search for the same
> > major.minor and replace with current relase, but when there is a new
> > minor (1.15..) we would have to edit manually anyway.
>
> I don't think so.
>
> We could generate subversion-%(version)s.rdf-excerpt files, drop them in
> dist/, and then use clean_dist()-like logic to cat the right subset of
> them, adding a fixed header and trailer.  This way, we wouldn't need to
> splice lines out of and into the file, and we wouldn't need to special-case
> the first release of a minor line or the EOLing of a minor line in the
> logic.
>
> > It's a balance between the amount of work done by RM, the downside of
> > having different processes for new minor and new patch release and the
> > work to code to automate. I'm leaning towards having it as it is, but
> > I would listen to Stefan's opinion (since he did the most recent RM).
>
> By and large, agreed, but see above for the details.
>

All this sounds good. However I'm not fluent in Python and even though
learning is on my to-do, it is not high enough right now so I'll leave it
to someone else.

Kind regards
Daniel Sahlberg

>

Re: svn commit: r1886396 - in /subversion/site/publish: ./ doap.rdf docs/release-notes/release-history.html download.html

[Daniel Sahlberg]

Den tis 16 feb. 2021 kl 21:37 skrev Daniel Shahaf :
> Is it worthwhile to automate this step?  doap.rdf changes rarely enough
> that we needn't bother with "edit part of a file" logic; we can just
> regenerate the entire file and «svnmucc put» it into place, with a
> comment indicating it's a generated file.

The doap.rdf contain references to two separate releases (at least
right now) and when running release.py you are working on one release
at a time. So we can't just have a template and add the current
release number, we also need to know the other release (which could
have been a year ago or the same day).

To automate "edit part of file", we would need to search for the same
major.minor and replace with current relase, but when there is a new
minor (1.15..) we would have to edit manually anyway.

It's a balance between the amount of work done by RM, the downside of
having different processes for new minor and new patch release and the
work to code to automate. I'm leaning towards having it as it is, but
I would listen to Stefan's opinion (since he did the most recent RM).

Kind regards,
Daniel

Re: svn commit: r1886494 - /subversion/site/staging/docs/community-guide/releasing.part.html

[Daniel Sahlberg]

Den tis 16 feb. 2021 kl 12:44 skrev Daniel Sahlberg
:
>> P.S.  While reviewing this I noticed that
>> https://subversion-staging.apache.org/favicon.ico is different to
>> https://svn.apache.org/repos/asf/subversion/site/staging/favicon.ico: an 
>> Apache
>> feather v. a Subversion logo.
>
>
> Hmm. That is very strange. I've pinged infra on Slack.

Infra says:
> looks like it's an overall override for "generic sites" that they all have 
> the ASF favicon due to the dash in subversion-staging it gets overridden

Ie, it is not a fault in our repository but an httpd.conf thing for the site.

I asked to have this removed and was requested to add it to Jira:
https://issues.apache.org/jira/browse/INFRA-21429

Kind regards,
Daniel Sahlberg

Re: svn commit: r1886396 - in /subversion/site/publish: ./ doap.rdf docs/release-notes/release-history.html download.html

[Daniel Sahlberg]

Den tis 16 feb. 2021 kl 13:15 skrev Stefan Sperling :
>
> On Tue, Feb 16, 2021 at 01:05:32PM +0100, Daniel Sahlberg wrote:
> > Den tis 16 feb. 2021 kl 11:34 skrev Stefan Sperling :
> > > On Mon, Feb 15, 2021 at 07:46:08PM +, Daniel Shahaf wrote:
> > > > The entity referred to by the  tag wasn't created in 2021.  
> > > > So,
> > > > I think the hunk is incorrect… but so was the original value, which 
> > > > referred to
> > > > the _file_'s creation date (r1053461), rather than to the date 
> > > > Subversion was
> > > > founded (2000), the date it was accepted into the Incubator, or the 
> > > > date it was
> > > > promoted to TLP.
> >
> > Should this be reverted, maybe even back to the proper creation date
> > (2000-02-29)?
>
> Yes please. I'm sorry for my mistake.
> Could you handle that as well while committing the change below?

r1886588

I've done this as a separate commit because I think we should merge
this to publish quite quickly. I'll leave it until tomorrow in case
someone has objections. The other changes can wait for a little bit
more discussion.

>
> > What do you think about this?
> > [[[
> > List the new release on ^/subversion/site/publish/doap.rdf
> > There should be a  section for each supported minor release
> > with the  and  being updated to the current release
> > date and patch release number.
> > Do not change anything else in the file (in particular the 
> > under  is the date when the Subversion project was created).
> > ]]]
>
> That is crystal clear and should avoid mistakes going forward. Thank you!

r1886589

/Daniel

Re: svn commit: r1886396 - in /subversion/site/publish: ./ doap.rdf docs/release-notes/release-history.html download.html

[Daniel Sahlberg]

Den tis 16 feb. 2021 kl 11:34 skrev Stefan Sperling :
>
> On Mon, Feb 15, 2021 at 07:46:08PM +, Daniel Shahaf wrote:
> > s...@apache.org wrote on Wed, Feb 10, 2021 at 20:39:23 -:
> > > Author: stsp
> > > Date: Wed Feb 10 20:39:22 2021
> > > New Revision: 1886396
> > >
> > > URL: http://svn.apache.org/viewvc?rev=1886396=rev
> > > Log:
> > > site/publish: Merge from staging area.
> >
> > For future reference, this commit should have used the "less than 24 hours 
> > ago" syntax:
> >
> > % cd site/publish
> > % grep -R -h -9  | vipe
> >   
> > %
> >
> > More below.
> >
> > > +++ subversion/site/publish/doap.rdf Wed Feb 10 20:39:22 2021
> > > @@ -22,7 +22,7 @@
> > >  limitations under the License.
> > >  -->
> > >http://subversion.apache.org/;>
> > > -2010-12-28
> > > +2021-02-10
> >
> > Huh?
> >
> > Quoting http://usefulinc.com/ns/doap:
> >
> > > > http://usefulinc.com/ns/doap#created;>
> > > >   http://usefulinc.com/ns/doap#; />
> > > >   created
> > > >   Date when something was created, in 
> > > > -MM-DD form. e.g. 2004-04-05
> > > > ⋮
> > > > 
> >
> > The entity referred to by the  tag wasn't created in 2021.  So,
> > I think the hunk is incorrect… but so was the original value, which 
> > referred to
> > the _file_'s creation date (r1053461), rather than to the date Subversion 
> > was
> > founded (2000), the date it was accepted into the Incubator, or the date it 
> > was
> > promoted to TLP.

Should this be reverted, maybe even back to the proper creation date
(2000-02-29)?

> >
> > Thanks for RMing,
> >
> > Daniel
> >
>
> Thanks for checking.
>
> I think in both of these cases it would have helped to have more specific
> instructions for how to update these files in our release manager's manual
> of the community guide.

What do you think about this?
[[[
List the new release on ^/subversion/site/publish/doap.rdf
There should be a  section for each supported minor release
with the  and  being updated to the current release
date and patch release number.
Do not change anything else in the file (in particular the 
under  is the date when the Subversion project was created).
]]]

Kind regards,
Daniel Sahlberg

Re: svn commit: r1886494 - /subversion/site/staging/docs/community-guide/releasing.part.html

[Daniel Sahlberg]

Thanks for your review!

Den mån 15 feb. 2021 kl 21:07 skrev Daniel Shahaf :

> dsahlb...@apache.org wrote on Sat, Feb 13, 2021 at 21:41:10 -:
> > +++ subversion/site/staging/docs/community-guide/releasing.part.html Sat
> Feb 13 21:41:10 2021
> > @@ -1255,80 +1255,24 @@ href="https://reporter.apache.org/addrel
> >
> >   
> >
> > -
>
> Here, you moved some 70 lines and also made a change between the pre-move
> and
> post-move form.  First, here's the delta for ease of review:
>

Sorry, should have done it in two commits.


> [[[
> -NOTE: We announce the release before updating the website since the
> website
> -update links to the release announcement sent to the announce@ mailing
> list.
> +NOTE: We update the website before announce the release to make sure
> any
> +links in the release announcement are valid. After announcing the release,
> +links to the release announcement e-mail are added to the website.
> ]]]
>
> On the first added line, "before announce the release" is ungrammatical.
>

Fixed (I hope..), r1886586.

(Also, with some archives it's possible to generate the links in advance;
> for
> example, this message's permalink is
> <
> https://mail-archives.apache.org/mod_mbox/subversion-dev/202102.mbox/%3C9761a2ec-aab5-409d-ba23-4f519c76a03c@tarpaulin.shahaf.local2%3E
> >.)
>
> >  
> >  Update the website
> > -->#releasing-update-website"
> >  title="Link to this section">
> >  
> >
> > +Even though the steps below indicate to update the published website
> > +directly, you may prepare the changes on
> ^/subversion/site/staging.
> > +In that case:
> > +
> > +  Do a catch-up merge from
> ^/subversion/site/publish.
> > +  Commit any changes to ^/subversion/site/staging and
> > +check the results on https://subversion-staging.apache.org
> "
> > +>https://subversion-staging.apache.org.
> > +  When ready to publish, merge the changes back to
> > +^/subversion/site/publish.
>
> Suggest to remind here to review the merge results in case there are other
> changes on staging at the time «svn merge» is run.
>

Added, r1886586.


>
> > +
>
> > @@ -1344,9 +1288,9 @@ the oldest supported LTS branch's ST
> >  ^/subversion/site/publish/index.html, also removing the
> >  oldest News item from that page.  Use release.py
> write-news to
> >  generate a template news item, which should then be customized.
> > -At least fill in the URL to the archived announcement email, and
> check
> > -that the date is correct if you generated the template in advance
> of the
> > -release date.
> > +For now, comment out the link to the release announcement e-mail.
> > +Check that the date is correct if you generated the template in
> advance of
> > +the release date.
>
> Sounds like we should make write-news generate the HTML comment marker in
> advance, and only ask the RM to remove them.  (The RM has a fair amount of
> work
> as it is; every little bit helps.)
>

Very reasonable, patch below. I'm adding the comment unless there is an
announcement url in command line arguments. I'm not happy about the
[if-any][else] construct but I couldn't find a way to check "if not any",
from a quick glance at the documentation in gsteins gihub repo. I took the
liberty of updating releasing.part.html as if the change below (or similar)
will go through.

[[[
Index: tools/dist/templates/rc-news.ezt
===
--- tools/dist/templates/rc-news.ezt(revision 1886582)
+++ tools/dist/templates/rc-news.ezt(working copy)
@@ -8,8 +8,18 @@
release is not intended for production use, but is provided as a
milestone
to encourage wider testing and feedback from intrepid users and
maintainers.
Please see the
+[if-any announcement_url]
+[else]
+
+[end]
release notes and
https://svn.apache.org/repos/asf/subversion/tags/[version]/CHANGES;>
change log for information about what will eventually be
Index: tools/dist/templates/stable-news.ezt
===
--- tools/dist/templates/stable-news.ezt(revision 1886582)
+++ tools/dist/templates/stable-news.ezt(working copy)
@@ -10,8 +10,18 @@
 [else]   This is the most complete release of the [major-minor].x line to
date,
and we encourage all users to upgrade as soon as reasonable.
 [end]   Please see the
+[if-any announcement_url]
+[else]
+
+[end]
release notes for more information about this release.
]]]


> Cheers,
>
> Daniel
>
> P.S.  While reviewing this I noticed that
> https://subversion-staging.apache.org/favicon.ico is different to
> https://svn.apache.org/repos/asf/subversion/site/staging/favicon.ico: an
> Apache
> feather v. a Subversion logo.
>

Hmm. That is very strange. I've pinged infra on Slack.

Kind regards,
Daniel Sahlberg

Re: svn commit: r1886389 - in /subversion/site/publish: ./ index.html

[Daniel Sahlberg]

Den ons 10 feb. 2021 21:42Stefan Sperling  skrev:

> Indeed. I had missed some of the necessary web site updates, going over the
> release process docs too quickly. I have done the missing updates just now.
> Hopefully everything is now in order.
>

Looks fine to me. Maybe with this the announcement at announce@a.o could go
though?

Thank you for your work to push the release!

/Daniel

>

Re: svn commit: r1886389 - in /subversion/site/publish: ./ index.html

[Daniel Sahlberg]

*grabbing a commit in the pile*

Is it intentional that the download page still links to 1.14.0 (and 1.10.6)?

(I'm not familiar with the relase workflow and I realise this may be a soak
for all mirrors to pick up the relase, just wanted to make sure it has not
been forgotten).

Kind regards
Daniel Sahlberg


Den ons 10 feb. 2021 kl 14:43 skrev :

> Author: stsp
> Date: Wed Feb 10 13:43:32 2021
> New Revision: 1886389
>
> URL: http://svn.apache.org/viewvc?rev=1886389=rev
> Log:
> * site/publish: merge from staging area
>
> Modified:
> subversion/site/publish/   (props changed)
> subversion/site/publish/index.html   (contents, props changed)
>
> Propchange: subversion/site/publish/
>
> --
>   Merged /subversion/site/staging:r1886387-1886388
>
> Modified: subversion/site/publish/index.html
> URL:
> http://svn.apache.org/viewvc/subversion/site/publish/index.html?rev=1886389=1886388=1886389=diff
>
> ==
> --- subversion/site/publish/index.html (original)
> +++ subversion/site/publish/index.html Wed Feb 10 13:43:32 2021
> @@ -66,6 +66,27 @@
>
>  
>
> +
> +2021-02-10  Apache Subversion Security Advisory
> + +   title="Link to this section">
> +
> +
> +The recent releases of Apache Subversion 1.14.1 and 1.10.7 contain
> + a fix for a security issue:  + href="/security/CVE-2020-17525-advisory.txt">CVE-2020-17525. This
> issue
> + affect Subversion 'mod_dav_svn' servers only. We encourage server
> operators
> + to upgrade to the latest appropriate version as soon as reasonable.
> +
> + Please see the  + href="https://lists.apache.org/list.html?annou...@subversion.apache.org;
> + >release announcements for more information about the releases.
> +
> +To get the latest release from the nearest mirror, please visit our
> + download page.
> +
> + 
> +
>  
>  2021-02-10  Apache Subversion 1.14.1 Released
>   
> Propchange: subversion/site/publish/index.html
>
> --
>   Merged /subversion/site/staging/index.html:r1886387-1886388
>
>
>

Re: svn commit: r1885120 - /subversion/site/publish/contributing.html

[Daniel Sahlberg]

Dear Daniel,

I've updated the commit message, hope it is better now. Thanks for your
feedback!

/Daniel

(No worries about the wait, my wife keeps reminding me I've got a family to
hang out with)

Den ons 6 jan. 2021 kl 16:45 skrev Daniel Shahaf :

> Good morning Daniel,
>
> dsahlb...@apache.org wrote on Mon, 04 Jan 2021 18:17 +00:00:
> > Author: dsahlberg
> > Date: Mon Jan  4 18:17:01 2021
> > New Revision: 1885120
> >
> > URL: http://svn.apache.org/viewvc?rev=1885120=rev
> > Log:
> > * publish/contributing.html:
> >   (#code/Become a committer): Remove links to Fitz' articles altogether
>
> Log messages should answer "Why?", not "What?" (the unidiff itself does
> that), and this one doesn't.  Could you extend it, please?  See r1884997
> for an example.
>
> A pointer to the dev@ thread would be fine, too.  The pointer should be
> long-lived; generally that means it should spell out the message-id.  (As
> to me, usually I either copy the Date/From/To/Cc/Subject/Message-ID
> headers in this order, or give a mail-archives.a.o link, which
> identifies the List-ID and Message-ID.  My email client is set up so
> I can generate either kind of pointer easily.)
>
> Cheers,
>
> Daniel
>
> P.S.  We still owe you an answer on your other thread, I know.  Sorry
>   for the delay.  I've pinged the private@ thread for you.
>
> > Modified:
> > subversion/site/publish/contributing.html
> >
> > Modified: subversion/site/publish/contributing.html
> > URL:
> >
> http://svn.apache.org/viewvc/subversion/site/publish/contributing.html?rev=1885120=1885119=1885120=diff
> >
> ==
> > --- subversion/site/publish/contributing.html (original)
> > +++ subversion/site/publish/contributing.html Mon Jan  4 18:17:01 2021
> > @@ -222,11 +222,7 @@
> > beneficial to the developer community  where quality
> > developers are concerned, "the more, the merrier"!  But never
> > underestimate how valuable this experience can be to you
> > -   personally
> > -   and  > href="
> https://web.archive.org/web/20050803084234/http://onlamp.com/pub/a/onlamp/2005/07/14/osdevelopers.html
> "
> > -   >professionally,
> > -> href="
> https://web.archive.org/web/20051214172122/http://onlamp.com/pub/a/onlamp/2005/08/01/opensourcedevelopers.html
> "
> > -   >too.
> > +   personally and professionally.
> >  
> >  
> >
> >
> >
> >
>

Re: svn commit: r1884661 [1/3] - in /subversion/site/staging-ng: ./ docs/community-guide/ docs/release-notes/

[Daniel Sahlberg]

Den sön 20 dec. 2020 kl 21:53 skrev :

> Author: dsahlberg
> Date: Sun Dec 20 20:53:05 2020
> New Revision: 1884661
>

My first (proper) commit. But only a merge to a testing branch and I even
stole the commit message :-)

/Dsahlberg