OK, so how do I do the merge? I tried using the following in a fresh checkout of the staging branch:
svn merge ^/subversion/site/publish However it showed changes I have not made, so I am loath to commit them: $ svn -u st M 1839421 roadmap.html M 1839421 quick-start.html M 1839421 faq.html M 1839421 . Status against revision: 1839421 Is this normal? On 25 August 2018 at 22:18, Stefan <luke1...@posteo.de> wrote: > On 25/08/2018 18:06, sebb AT ASF wrote: >> On 25 August 2018 at 13:44, Stefan <luke1...@posteo.de> wrote: >>> On 25/08/2018 14:37, Stefan wrote: >>>> On 23/08/2018 20:01, s...@apache.org wrote: >>>>> Author: sebb >>>>> Date: Thu Aug 23 18:01:30 2018 >>>>> New Revision: 1838746 >>>>> >>>>> URL: http://svn.apache.org/viewvc?rev=1838746&view=rev >>>>> Log: >>>>> SVN-4736 - fix gpg command >>>>> >>>>> Modified: >>>>> subversion/site/staging/download.html >>>>> >>>>> Modified: subversion/site/staging/download.html >>>>> URL: >>>>> http://svn.apache.org/viewvc/subversion/site/staging/download.html?rev=1838746&r1=1838745&r2=1838746&view=diff >>>>> ============================================================================== >>>>> --- subversion/site/staging/download.html (original) >>>>> +++ subversion/site/staging/download.html Thu Aug 23 18:01:30 2018 >>>>> @@ -253,7 +253,7 @@ Other mirrors: >>>>> <em>or</em><br /> >>>>> <code> >>>>> % gpg --import subversion.asc<br /> >>>>> -% gpg --verify subversion-[version].tar.gz.asc >>>>> +% gpg --verify subversion-[version].tar.gz.asc >>>>> subversion-[version].tar.gz >>>> Testing GPG locally (2.2.8 - Windows 10 - bundled version with Gpg4Win >>>> 3.1.2) running the command w/o specifying the filename of the gz archive >>>> works fine: >>>> "gpg: assuming signed data in 'subversion-1.10.2.tar.bz2' [...]" >>>> >>>> Is this command problematic with older GPG versions? If not, why not >>>> keep the command as short as possible and rely on the default resolution >>>> of the archive name? >>> Just saw the referenced SVN issue with the link which gives the missing >>> rational for that change. Thanks for that (should have spotted it before >>> replying). For the record: >> Would it be useful to link to the explanation from the download page? > I would not think so. The target audience of that article is primarily > the user who's downloading the package. We'd provide him with proper > details about how to verify the download, but anything which explains > the rational behind how the tech side of the verification works and why > the command should be written the way it's presented in the example > would be out of scope for that page, IMO. The rational why something was > done the way it was should be in the log (and there it's already present > via the Jira issue link). > >> >>> "If the release file is omitted, GPG will only check the signature >>> against the release file if the signature is a detached signature. If >>> the .asc file is a self-contained signed file, GPG will only check that, >>> and will not verify the release. (This should not happen if the >>> signature file was downloaded from an ASF server, but it is safer to >>> always specify the release filename)" [1] >>> >>> That said, +1 on that change. Feel free to merge it to publish. >>> >>> [1] https://www.apache.org/info/verification.html#CheckingSignatures >>>>> </code></p> >>>>> >>>>> <p>Alternatively, you can verify the checksums on the >>>>> >>> Regards, >>> Stefan >>> > Regards, > Stefan > >
