[ANNOUNCE] Apache Subversion 1.9.9 released
I'm happy to announce the release of Apache Subversion 1.9.9. Please choose the mirror closest to you by visiting: https://subversion.apache.org/download.cgi#supported-releases This is a stable bugfix release of the Apache Subversion open source version control system. The SHA1 checksums are: b8d410d5146e914bc2a72cd8957f6d3b68c4ac52 subversion-1.9.9.tar.bz2 acfa91d5151bd2a80808fbebe86c25dce9fbd698 subversion-1.9.9.tar.gz 9ed6108e015551efa1704c76617f81e8a048fcd3 subversion-1.9.9.zip SHA-512 checksums are available at: https://www.apache.org/dist/subversion/subversion-1.9.9.tar.bz2.sha512 https://www.apache.org/dist/subversion/subversion-1.9.9.tar.gz.sha512 https://www.apache.org/dist/subversion/subversion-1.9.9.zip.sha512 PGP Signatures are available at: https://www.apache.org/dist/subversion/subversion-1.9.9.tar.bz2.asc https://www.apache.org/dist/subversion/subversion-1.9.9.tar.gz.asc https://www.apache.org/dist/subversion/subversion-1.9.9.zip.asc For this release, the following people have provided PGP signatures: Julian Foad [4096R/1FB064B84EECC493] with fingerprint: 6011 63CF 9D49 9FD7 18CF 582D 1FB0 64B8 4EEC C493 Branko Čibej [4096R/1BCA6586A347943F] with fingerprint: BA3C 15B1 337C F0FB 222B D41A 1BCA 6586 A347 943F Johan Corveleyn [4096R/B59CE6D6010C8AAD] with fingerprint: 8AA2 C10E EAAD 44F9 6972 7AEA B59C E6D6 010C 8AAD Release notes for the 1.9.x release series may be found at: https://subversion.apache.org/docs/release-notes/1.9.html You can find the list of changes between 1.9.9 and earlier versions at: https://svn.apache.org/repos/asf/subversion/tags/1.9.9/CHANGES Questions, comments, and bug reports to users@subversion.apache.org. Thanks, - The Subversion Team -- To unsubscribe, please see: https://subversion.apache.org/mailing-lists.html#unsubscribing
[ANNOUNCE] Apache Subversion 1.10.2 released
I'm happy to announce the release of Apache Subversion 1.10.2. Please choose the mirror closest to you by visiting: https://subversion.apache.org/download.cgi#recommended-release This is a stable bugfix release of the Apache Subversion open source version control system. The SHA1 checksums are: bc52ef2e671f821998ac9a5f7ebecbbcaaef83b8 subversion-1.10.2.tar.bz2 4c127b751c7804ec21a3942131467e721febc83f subversion-1.10.2.tar.gz c85c11a21ac97e3734a7064b00ac962a2008e50a subversion-1.10.2.zip SHA-512 checksums are available at: https://www.apache.org/dist/subversion/subversion-1.10.2.tar.bz2.sha512 https://www.apache.org/dist/subversion/subversion-1.10.2.tar.gz.sha512 https://www.apache.org/dist/subversion/subversion-1.10.2.zip.sha512 PGP Signatures are available at: https://www.apache.org/dist/subversion/subversion-1.10.2.tar.bz2.asc https://www.apache.org/dist/subversion/subversion-1.10.2.tar.gz.asc https://www.apache.org/dist/subversion/subversion-1.10.2.zip.asc For this release, the following people have provided PGP signatures: Julian Foad [4096R/1FB064B84EECC493] with fingerprint: 6011 63CF 9D49 9FD7 18CF 582D 1FB0 64B8 4EEC C493 Branko Čibej [4096R/1BCA6586A347943F] with fingerprint: BA3C 15B1 337C F0FB 222B D41A 1BCA 6586 A347 943F Johan Corveleyn [4096R/B59CE6D6010C8AAD] with fingerprint: 8AA2 C10E EAAD 44F9 6972 7AEA B59C E6D6 010C 8AAD Release notes for the 1.10.x release series may be found at: https://subversion.apache.org/docs/release-notes/1.10.html You can find the list of changes between 1.10.2 and earlier versions at: https://svn.apache.org/repos/asf/subversion/tags/1.10.2/CHANGES Questions, comments, and bug reports to users@subversion.apache.org. Thanks, - The Subversion Team -- To unsubscribe, please see: https://subversion.apache.org/mailing-lists.html#unsubscribing
Some files stay at an too new revision when updating the working copy to an old revision
Hi,
this already happened a few times here, but now I managed to re-create
it reliably.
This happens at least on Linux with subversion-1.8/subversion-1.10 and
on Windows
with TortoiseSVN-1.9, didn't test older versions yet. Server is
subversion-1.9.5
on Linux, a "svnadmin verify" of a repository hotcopy showed no problems
This slightly obfuscated transcript shows the problem:
-->
$ rm -rf myrepo.wc
$ svn co https://svnserver/svn/myrepo/trunk/some/path/src myrepo.wc/
...
Checked out revision 98863.
$ svn status --verbose myrepo.wc/mysrc[34].c
98867 93474 user1 myrepo.wc/mysrc3.c
98867 87357 user2 myrepo.wc/mysrc4.c
$ svn up -r 85950 myrepo.wc
...
At revision 85950.
$ svn status --verbose myrepo.wc/mysrc[34].c
85950 93474 user1 myrepo.wc/mysrc3.c
85950 83501 user3 myrepo.wc/mysrc4.c
--<
As you can see, mysrc3.c has a too high last_commit revision and also
the content
of the file is too new after the first downgrading with "svn up -r 85950
myrepo.wc".
The following procedure fixes the problem:
-->
$ svn update -r85950 myrepo.wc/mysrc3.c
Updating 'myrepo.wc/mysrc3.c':
At revision 85950.
$ svn status --verbose myrepo.wc/mysrc[34].c
85950 93474 user1 myrepo.wc/mysrc3.c
85950 83501 user3 myrepo.wc/mysrc4.c
$ svn update -rPREV myrepo.wc/mysrc3.c
Updating 'myrepo.wc/mysrc3.c':
U myrepo.wc/mysrc3.c
Updated to revision 93473.
$ svn status --verbose myrepo.wc/mysrc[34].c
93473 87225 user2 myrepo.wc/mysrc3.c
85950 83501 user3 myrepo.wc/mysrc4.c
$ svn update -r85950 myrepo.wc/mysrc3.c
Updating 'myrepo.wc/mysrc3.c':
U myrepo.wc/mysrc3.c
Updated to revision 85950.
$ svn status --verbose myrepo.wc/mysrc[34].c
85950 83501 user3 myrepo.wc/mysrc3.c
85950 83501 user3 myrepo.wc/mysrc4.c
--<
Is this a known problem? Could it be server-related? IOW, should I try
to upgrade
the server to 1.10?
This is a simple oneliner to find affected files:
$ svn status --verbose --ignore-externals myrepo.wc/ | gawk '{
FIELDWIDTHS = "1 1 1 1 1 1 1 1 1 1 8 1 8 1 5000"; if ($13 > $11) print
$11 " " $13 " " $15 }'
Let me know if there is anything I should try or if you need more details.
Franz
Re: Some files stay at an too new revision when updating the working copy to an old revision
On 20.07.2018 15:37, Franz Sirl wrote:
> Hi,
>
> this already happened a few times here, but now I managed to re-create
> it reliably.
> This happens at least on Linux with subversion-1.8/subversion-1.10 and
> on Windows
> with TortoiseSVN-1.9, didn't test older versions yet. Server is
> subversion-1.9.5
> on Linux, a "svnadmin verify" of a repository hotcopy showed no problems
>
> This slightly obfuscated transcript shows the problem:
>
> -->
> $ rm -rf myrepo.wc
> $ svn co https://svnserver/svn/myrepo/trunk/some/path/src myrepo.wc/
> ...
> Checked out revision 98863.
> $ svn status --verbose myrepo.wc/mysrc[34].c
> 98867 93474 user1 myrepo.wc/mysrc3.c
> 98867 87357 user2 myrepo.wc/mysrc4.c
> $ svn up -r 85950 myrepo.wc
> ...
> At revision 85950.
> $ svn status --verbose myrepo.wc/mysrc[34].c
> 85950 93474 user1 myrepo.wc/mysrc3.c
> 85950 83501 user3 myrepo.wc/mysrc4.c
> --<
>
> As you can see, mysrc3.c has a too high last_commit revision and also
> the content
> of the file is too new after the first downgrading with "svn up -r
> 85950 myrepo.wc".
This does look strange.
Is myrepo.wc/mysrc3.c a file external by any chance? Try:
$ svn propget svn:externals --show-inherited-props myrepo.wc
If it isn't could you show us an (obfuscated) log of that file?
$ svn log --verbose -r93474:85950 myrepo.wc/mysrc3.c
(the actual log messages are not important, only the list of changes to
the file)
-- Brane
>
> The following procedure fixes the problem:
>
> -->
> $ svn update -r85950 myrepo.wc/mysrc3.c
> Updating 'myrepo.wc/mysrc3.c':
> At revision 85950.
> $ svn status --verbose myrepo.wc/mysrc[34].c
> 85950 93474 user1 myrepo.wc/mysrc3.c
> 85950 83501 user3 myrepo.wc/mysrc4.c
> $ svn update -rPREV myrepo.wc/mysrc3.c
> Updating 'myrepo.wc/mysrc3.c':
> U myrepo.wc/mysrc3.c
> Updated to revision 93473.
> $ svn status --verbose myrepo.wc/mysrc[34].c
> 93473 87225 user2 myrepo.wc/mysrc3.c
> 85950 83501 user3 myrepo.wc/mysrc4.c
> $ svn update -r85950 myrepo.wc/mysrc3.c
> Updating 'myrepo.wc/mysrc3.c':
> U myrepo.wc/mysrc3.c
> Updated to revision 85950.
> $ svn status --verbose myrepo.wc/mysrc[34].c
> 85950 83501 user3 myrepo.wc/mysrc3.c
> 85950 83501 user3 myrepo.wc/mysrc4.c
> --<
>
> Is this a known problem? Could it be server-related? IOW, should I try
> to upgrade
> the server to 1.10?
>
> This is a simple oneliner to find affected files:
>
> $ svn status --verbose --ignore-externals myrepo.wc/ | gawk '{
> FIELDWIDTHS = "1 1 1 1 1 1 1 1 1 1 8 1 8 1 5000"; if ($13 > $11) print
> $11 " " $13 " " $15 }'
>
> Let me know if there is anything I should try or if you need more
> details.
>
> Franz
>
>
Re: Some files stay at an too new revision when updating the working copy to an old revision
Am 2018-07-20 um 15:55 schrieb Branko Čibej: On 20.07.2018 15:37, Franz Sirl wrote: Hi, this already happened a few times here, but now I managed to re-create it reliably. This happens at least on Linux with subversion-1.8/subversion-1.10 and on Windows with TortoiseSVN-1.9, didn't test older versions yet. Server is subversion-1.9.5 on Linux, a "svnadmin verify" of a repository hotcopy showed no problems This slightly obfuscated transcript shows the problem: --> $ rm -rf myrepo.wc $ svn co https://svnserver/svn/myrepo/trunk/some/path/src myrepo.wc/ ... Checked out revision 98863. $ svn status --verbose myrepo.wc/mysrc[34].c 98867 93474 user1 myrepo.wc/mysrc3.c 98867 87357 user2 myrepo.wc/mysrc4.c $ svn up -r 85950 myrepo.wc ... At revision 85950. $ svn status --verbose myrepo.wc/mysrc[34].c 85950 93474 user1 myrepo.wc/mysrc3.c 85950 83501 user3 myrepo.wc/mysrc4.c --< As you can see, mysrc3.c has a too high last_commit revision and also the content of the file is too new after the first downgrading with "svn up -r 85950 myrepo.wc". This does look strange. Is myrepo.wc/mysrc3.c a file external by any chance? Try: $ svn propget svn:externals --show-inherited-props myrepo.wc This command returns empty. There doesn't seem to be anything special about this file, except that it is one of the oldest in the repository. It was imported from CVS with history in 2005 (subversion-1.2), but so was mysrc4.c. Also there have been not any properties set to the parent directory ever AFAICS. If it isn't could you show us an (obfuscated) log of that file? $ svn log --verbose -r93474:85950 myrepo.wc/mysrc3.c r93474 | user1 | 2018-02-07 16:21:20 +0100 (Wed, 07 Feb 2018) | 9 lines Changed paths: M /trunk/some/path/src/mysrc-defines.h M /trunk/some/path/src/mysrc1.c M /trunk/some/path/src/mysrc3.c M /trunk/some/path/src/mysrc5.c M /trunk/some/path/src/mysrc6.c ChangeLog... r87225 | user2 | 2017-08-03 11:28:11 +0200 (Thu, 03 Aug 2017) | 1 line Changed paths: M /trunk/some/path/src/mysrc-defines.h M /trunk/some/path/src/mysrc1.c M /trunk/some/path/src/mysrc3.c M /trunk/some/path/src/mysrc5.c M /trunk/some/path/src/mysrc6.c ChangeLog... r87201 | user1 | 2017-08-02 16:58:50 +0200 (Wed, 02 Aug 2017) | 14 lines Changed paths: M /trunk/some/path/src/mysrc-defines.h M /trunk/some/path/src/mysrc1.c M /trunk/some/path/src/mysrc3.c M /trunk/some/path/src/mysrc5.c M /trunk/some/path/src/mysrc6.c ChangeLog... Looks innocent to me... Deleted some "M" lines pointing to files in other directories, but that's it. Franz.
Subversion 1.10.x and svnkit compatibility?
Greetings to all, Can anyone tell me if svnkit is compatible with subversion 1.10.x? Or if there's a particular svnkit dev branch that's in the works, so to speak? I've attempted mailing both the svnkit mailing lists themselves as well as the svnkit main email address, but all of them are bouncing as NDR. When responding, could you please reply to me directly as I am not a current subscriber to the list. Thanks in advance
Re: using -F fails using bash process substitution. bug?
Philip Martin wrote on Thu, 19 Jul 2018 23:07 +0100: > Daniel Shahaf writes: > > >> The workaround is to use: > >> > >> echo -ne "ignorethis\n" | svn ps svn:ignore -F - . > > > > By the way, an even simpler workaround in this case is > > > > svn ps svn:ignore -m $'ignorethis\n' ./ > > No. In this case -F specifies the property value, not the log message. > Ah, my bad. In that case, just drop the -m: svn ps svn:ignore $'line1\nline2\nline3\n' ./ This also shows one way to propset a multiline value. > Something like this may work: > >svn ps svn:ignore $(echo -ne "ignorethis\n") . > > but quoting multiple line values can be tricky. This should work: svn ps svn:ignore "$(printf '%s\n' 'line1' 'line2' 'line3' ...)" (up to trailing newlines) Cheers, Daniel
Re: using -F fails using bash process substitution. bug?
Philip Martin wrote on Thu, 19 Jul 2018 16:16 +0100: > We might be able to fix the code that uses stat() > by having it check for EOF as well. I see you've now done this in r1836306. Any reason not to backport that? (Feel free to add my +1)
