Disabling plain-text password storage by defult
Given that we support a number of secure credentials stores, I propose that, starting with 1.14.0 LTS, we disable the on-disk plain-text password store by default. I've prepared a patch for configure.ac to issue appropriate warnings before that time. If we decide to do this, we should also mention it in our roadmap on the site. -- Brane Index: configure.ac === --- configure.ac(revision 1845215) +++ configure.ac(working copy) @@ -866,6 +866,35 @@ fi dnl plaintext passwords --- +dnl FIXME: warn when we're at version 1.14 +ifelse(1, regexp(AC_PACKAGE_VERSION, [^\([0-9]*\)\..*], [\1]), +ifelse(14, regexp(AC_PACKAGE_VERSION, [^[0-9]*\.\([0-9]*\)\..*], [\1]), +AC_MSG_WARN([ +== + +Remember to make --disable-plaintext-password-storage the default! + +==]))) +dnl +dnl TODO: After 1.14.0: +dnl AC_ARG_ENABLE(plaintext-password-storage, +dnl AS_HELP_STRING([--enable-plaintext-password-storage], +dnl[Enable on-disk caching of plaintext passwords and passphrases. +dnl (Enabling this functionality will not force Subversion +dnl to store passwords in plaintext, but does permit users to +dnl explicitly allow that behavior via runtime configuration.)]), +dnl [plaintext_passwd_storage="$enableval"], +dnl [plaintext_passwd_storage="no"]) +dnl +dnl if test "$plaintext_passwd_storage" = "yes"; then +dnl AC_MSG_WARN([Enabling plaintext password/passphrase storage]) +dnl else +dnl AC_MSG_NOTICE([Disabling plaintext password/passphrase storage]) +dnl AC_DEFINE(SVN_DISABLE_PLAINTEXT_PASSWORD_STORAGE, 1, +dnl [Defined if plaintext password/passphrase storage is disabled]) +dnl fi +dnl +dnl Before 1.14.0: AC_ARG_ENABLE(plaintext-password-storage, AS_HELP_STRING([--disable-plaintext-password-storage], [Disable on-disk caching of plaintext passwords and passphrases. @@ -872,14 +901,24 @@ (Leaving this functionality enabled will not force Subversion to store passwords in plaintext, but does permit users to explicitly allow that behavior via runtime configuration.)]), -[ - if test "$enableval" = "no"; then - AC_MSG_NOTICE([Disabling plaintext password/passphrase storage]) - AC_DEFINE(SVN_DISABLE_PLAINTEXT_PASSWORD_STORAGE, 1, -[Defined if plaintext password/passphrase storage is disabled]) - fi -]) +[plaintext_passwd_storage="$enableval"], +[plaintext_passwd_storage="yes"]) +if test "$plaintext_passwd_storage" = "no"; then + AC_MSG_NOTICE([Disabling plaintext password/passphrase storage]) + AC_DEFINE(SVN_DISABLE_PLAINTEXT_PASSWORD_STORAGE, 1, +[Defined if plaintext password/passphrase storage is disabled]) +else + AC_MSG_WARN([ +== + +Plaintext password/passphrase storage is enabled. +Consider using the --disable-plaintext-password-storage option to +disable it. This will become the default in Subversion 1.14.0 LTS. + +==]) +fi + dnl Build and install rules --- INSTALL_STATIC_RULES="install-bin install-docs"
Re: Staging the 1.11.0 website updates
On 30.10.2018 22:32, Julian Foad wrote: > Branko Čibej wrote: >> Oops. I was just reminded in IRC that we did not update the API doc >> links in the last two .0 releases: >> >> https://subversion-staging.apache.org/docs/ >> >> We should have statically generated pages for the API docs committed to >> the site tree. > I'm doing that right now: adding 1.10 in 'publish' and 1.11 in 'staging'. > > I commented out your section of links to latest trunk docs ( > http://subversion.a.o.local/docs/#next-release ), as those are currently not > being built. Perfect, thanks ... I'd started setting that up on svn-qavm3, but ... well, let's say I got sidetracked, eh. -- Brane
[ANNOUNCE] Apache Subversion 1.11.0 released
I'm happy to announce the release of Apache Subversion 1.11.0. Please choose the mirror closest to you by visiting: https://subversion.apache.org/download.cgi#recommended-release This is a stable feature release of the Apache Subversion open source version control system. SHA-512 checksums are available at: https://www.apache.org/dist/subversion/subversion-1.11.0.tar.bz2.sha512 https://www.apache.org/dist/subversion/subversion-1.11.0.tar.gz.sha512 https://www.apache.org/dist/subversion/subversion-1.11.0.zip.sha512 PGP Signatures are available at: https://www.apache.org/dist/subversion/subversion-1.11.0.tar.bz2.asc https://www.apache.org/dist/subversion/subversion-1.11.0.tar.gz.asc https://www.apache.org/dist/subversion/subversion-1.11.0.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 Stefan Sperling [2048R/4F7DBAA99A59B973] with fingerprint: 8BC4 DAE0 C5A4 D65F 4044 0107 4F7D BAA9 9A59 B973 Daniel Shahaf [3072R/A5FEEE3AC7937444] with fingerprint: E966 46BE 08C0 AF0A A0F9 0788 A5FE EE3A C793 7444 Johan Corveleyn [4096R/B59CE6D6010C8AAD] with fingerprint: 8AA2 C10E EAAD 44F9 6972 7AEA B59C E6D6 010C 8AAD Release notes for the 1.11.x release series may be found at: https://subversion.apache.org/docs/release-notes/1.11.html You can find the list of changes between 1.11.0 and earlier versions at: https://svn.apache.org/repos/asf/subversion/tags/1.11.0/CHANGES Questions, comments, and bug reports to us...@subversion.apache.org. Thanks, - The Subversion Team -- To unsubscribe, please see: https://subversion.apache.org/mailing-lists.html#unsubscribing
Re: Staging the 1.11.0 website updates
Branko Čibej wrote: > Oops. I was just reminded in IRC that we did not update the API doc > links in the last two .0 releases: > > https://subversion-staging.apache.org/docs/ > > We should have statically generated pages for the API docs committed to > the site tree. I'm doing that right now: adding 1.10 in 'publish' and 1.11 in 'staging'. I commented out your section of links to latest trunk docs ( http://subversion.a.o.local/docs/#next-release ), as those are currently not being built. -- - Julian
Re: svn commit: r1845204 - in /subversion/trunk/subversion: mod_authz_svn/mod_authz_svn.c mod_dav_svn/mod_dav_svn.c
Ruediger Pluem wrote on Tue, Oct 30, 2018 at 19:57:58 -:
> BTW, I had to apply the following patch to nominate.pl to get it running with
> perl 5.16.3 on CentOS 7:
>
> Index: tools/dist/backport.pl
> ===
> --- tools/dist/backport.pl (revision 1845203)
> +++ tools/dist/backport.pl (working copy)
> @@ -791,8 +791,8 @@
>
> # Add to state votes that aren't '+0' or 'edit'
> $state->{$_->{digest}}++ for grep
> - ($_->{approval} or $_->{vote} =~
> /^(-1|-0|[+]1)$/),
> - @votesarray;
> + (($_->{approval} or $_->{vote} =~
> /^(-1|-0|[+]1)$/),
> + @votesarray);
>}
> }
>
> I am happy to commit this if this is fine with later versions of perl which I
> have not at hand for testing.
Works for me with and without the change, Perl 5.24.1 on Debian stretch.
+1 to commit.
Consider using «grep +(foo), @bar» or «grep { foo } @bar» instead of
«grep ((foo), bar»: the three alternatives are equivalent, so it's just
a question of which one is more readable/idiomatic.
Cheers,
Daniel
(Feel free to join us on IRC, by the way. #svn-dev on freenode)
Re: svn commit: r1845204 - in /subversion/trunk/subversion: mod_authz_svn/mod_authz_svn.c mod_dav_svn/mod_dav_svn.c
Ruediger Pluem wrote on Tue, Oct 30, 2018 at 20:00:01 -: > > > On 2018/10/30 18:09:42, Daniel Shahaf wrote: > > Branko Čibej wrote on Tue, 30 Oct 2018 10:22 +0100: > > > It's important enough to be added to CHANGES, in the server-side > > > bugfixes section, so please add a line there, for 1.12.0. > > > > Since we'll have to add this revision four times to CHANGES (on for each > > of 1.9, 1.10, 1.11, 1.12), perhaps we should start using the CHANGES-in-log- > > message convention a bit more? In this case, it would be something like > > . > > [U:server] mod_dav_svn, mod_authz_svn: Fix segfault under mod_http2 > > (SVN-4782) > > . > > Should I add the above to the commit log? Or should I add an entry to CHANGES > directly? > I can do either way whatever you prefer. In the log message please; release.py write-changelog will pick it from there when we roll 1.12.0-alpha1.
Re: Staging the 1.11.0 website updates
On 30.10.2018 17:11, Branko Čibej wrote: > On 29.10.2018 18:43, Julian Foad wrote: >> I just pushed the website updates for 1.11.0 to staging: >> >> https://subversion-staging.apache.org/ >> https://subversion-staging.apache.org/news >> https://subversion-staging.apache.org/download >> https://subversion-staging.apache.org/docs/release-notes/release-history.html >> https://subversion-staging.apache.org/doap (is not HTML) >> >> Please review if you have a mind to. >> >> I hope to be able to publish tomorrow 30th Oct (that's the date I've put in >> the website and CHANGES file in the tarball) which would be possible if we >> can get 3 signatures today, or at the very latest the day after (which would >> be close enough for the discrepancy not to matter, and would still achieve >> our stated October release date target). > > Looks good, after a rather cursory glance. Oops. I was just reminded in IRC that we did not update the API doc links in the last two .0 releases: https://subversion-staging.apache.org/docs/ We should have statically generated pages for the API docs committed to the site tree. -- Brane
Re: svn commit: r1845204 - in /subversion/trunk/subversion: mod_authz_svn/mod_authz_svn.c mod_dav_svn/mod_dav_svn.c
On 2018/10/30 18:09:42, Daniel Shahaf wrote: > Branko Čibej wrote on Tue, 30 Oct 2018 10:22 +0100: > > It's important enough to be added to CHANGES, in the server-side > > bugfixes section, so please add a line there, for 1.12.0. > > Since we'll have to add this revision four times to CHANGES (on for each > of 1.9, 1.10, 1.11, 1.12), perhaps we should start using the CHANGES-in-log- > message convention a bit more? In this case, it would be something like > . > [U:server] mod_dav_svn, mod_authz_svn: Fix segfault under mod_http2 > (SVN-4782) > . Should I add the above to the commit log? Or should I add an entry to CHANGES directly? I can do either way whatever you prefer. Regards Rüdiger
Re: svn commit: r1845204 - in /subversion/trunk/subversion: mod_authz_svn/mod_authz_svn.c mod_dav_svn/mod_dav_svn.c
On 2018/10/30 09:22:56, Branko Čibej wrote:
>
> [[[
> .../repos/1.11.x$ ../trunk/tools/dist/nominate.pl r1845204 "Prevents a crash
> in mod_http2."
> Index: STATUS
> ===
> --- STATUS(revision 1845205)
> +++ STATUS(working copy)
> @@ -48,6 +48,14 @@ Candidate changes:
> Votes:
> +1: brane
>
> + * r1845204
> + Fix issue SVN-4782: Do not use (const char*)1 in httpd modules as value
> for
> + r->notes.
> + Justification:
> + Prevents a crash in mod_http2.
> + Votes:
> + +1: brane
> +
> Veto-blocked changes:
> =
>
> Commit this nomination?
> ]]]
>
> (typing y will commit, anything else will revert the change to
> STATUS).
>
> Our currently maintained branches are 1.9.x, 1.10.x and 1.11.x; fixing a
Done for all 3 branches via the perl script as shown above
BTW, I had to apply the following patch to nominate.pl to get it running with
perl 5.16.3 on CentOS 7:
Index: tools/dist/backport.pl
===
--- tools/dist/backport.pl (revision 1845203)
+++ tools/dist/backport.pl (working copy)
@@ -791,8 +791,8 @@
# Add to state votes that aren't '+0' or 'edit'
$state->{$_->{digest}}++ for grep
- ($_->{approval} or $_->{vote} =~
/^(-1|-0|[+]1)$/),
- @votesarray;
+ (($_->{approval} or $_->{vote} =~
/^(-1|-0|[+]1)$/),
+ @votesarray);
}
}
I am happy to commit this if this is fine with later versions of perl which I
have not at hand for testing.
Regards
Rüdiger
[PATCH] Suppress conflict resolver in dry-run merge
[[[ *subversion/svn/merge-cmd.c (svn_cl__merge): Suppress the interactive conflict resolver if a merge has been performed with the dry-run option. ]]] merge-cmd.c.patch Description: Binary data
Re: svn commit: r1845204 - in /subversion/trunk/subversion: mod_authz_svn/mod_authz_svn.c mod_dav_svn/mod_dav_svn.c
Branko Čibej wrote on Tue, 30 Oct 2018 10:22 +0100: > It's important enough to be added to CHANGES, in the server-side > bugfixes section, so please add a line there, for 1.12.0. Since we'll have to add this revision four times to CHANGES (on for each of 1.9, 1.10, 1.11, 1.12), perhaps we should start using the CHANGES-in-log- message convention a bit more? In this case, it would be something like . [U:server] mod_dav_svn, mod_authz_svn: Fix segfault under mod_http2 (SVN-4782) . added to the the log message (as documented in tools/dist/release.py:write_changelog()). (Rüdiger, this isn't something you could've known. It so happens that today we start, for the first time in our history, to support three minor lines in parallel; that's why I'm bringing up streamlining the CHANGES process.) > The backport process is similar to APR's and I assume httpd's, we use a > STATUS file for nominations with 3 PMC +1 required for core changes. We > have a script for proposing backports, here's an example: We also have a script for automatically merging backports that have received the required number of votes, which might be of interest to apr/httpd's RM's. (See commits by the role account 'svn-role' to our tree.) Cheers, Daniel
Re: Staging the 1.11.0 website updates
> > On 29.10.2018 18:43, Julian Foad wrote: > > I just pushed the website updates for 1.11.0 to staging: > > > > https://subversion-staging.apache.org/ > > https://subversion-staging.apache.org/news > > https://subversion-staging.apache.org/download > > > https://subversion-staging.apache.org/docs/release-notes/release-history.html > > https://subversion-staging.apache.org/doap (is not HTML) > > > > Please review if you have a mind to. > > > > I hope to be able to publish tomorrow 30th Oct (that's the date I've put > in the website and CHANGES file in the tarball) which would be possible if > we can get 3 signatures today, or at the very latest the day after (which > would be close enough for the discrepancy not to matter, and would still > achieve our stated October release date target). Not a showstopper, but "Founded in 2000 by CollabNet, Inc., the Subversion project and software have seen incredible success over the past decade" should be changed to "last two decades" one of these days, no? Especially as someone pointed out earlier that Subversion is now of legal age. :-)
Re: Staging the 1.11.0 website updates
On 29.10.2018 18:43, Julian Foad wrote: > I just pushed the website updates for 1.11.0 to staging: > > https://subversion-staging.apache.org/ > https://subversion-staging.apache.org/news > https://subversion-staging.apache.org/download > https://subversion-staging.apache.org/docs/release-notes/release-history.html > https://subversion-staging.apache.org/doap (is not HTML) > > Please review if you have a mind to. > > I hope to be able to publish tomorrow 30th Oct (that's the date I've put in > the website and CHANGES file in the tarball) which would be possible if we > can get 3 signatures today, or at the very latest the day after (which would > be close enough for the discrepancy not to matter, and would still achieve > our stated October release date target). Looks good, after a rather cursory glance. -- Brane
Re: Merge dry-run and conflict resolution
On Tue, Oct 30, 2018 at 10:27:28AM +0100, Branko Čibej wrote: > [Moving to dev@ as this is more of a development question.] > > On 30.10.2018 09:35, Jonathan Guy wrote: > > Hi all > > Just looking over the code for the interactive conflict resolution. > > This is just an initial observation but in merge_cmd.c the function > > svn_cl__merge calls run_merge then checks for a merge tracking error and > > then checks for conflicts. If there were conflicts it runs the interactive > > conflict resolver. My question is should the resolver be running if this is > > a dry-run? > > Thanks for any clarification on this. > > > I think you're correct, since a dry run doesn't (or shouldn't) produce > any changes in the working copy, it makes no sense to run the resolver. > > -- Brane > Agreed. Jonathan, would you be able to submit a patch for this issue?
Re: The future of the Subversion book
On 30.10.2018 14:33, Michael Pilato wrote: > On 10/27/18 1:12 PM, Branko Čibej wrote: >> On 18.10.2018 20:40, Branko Čibej wrote: >>> On 06.09.2018 15:25, Branko Čibej wrote: On 06.09.2018 15:10, C. Michael Pilato wrote: > > The book carries a cc-by-2.0 license, with Ben, Fitz and myself named as > the copyright holders. I suspect that in order to be absorbed by the > PMC, that licensing would have to change to an Apache License. Does that > mean that the three primary authors would need to officially re-license > it somehow? Or maybe it's a software grant to the ASF (rather like > Subversion itself was)? > >>> We'd have to ask legal@ but I'd be surprised if we'd be required to re-license the book; it's not code, and the Apache license isn't really suitable. Also we wouldn't really be making releases of it, just updates on the web. >>> I didn't quite forget about this: LEGAL-421 >> The answer to this question appears to be that we should relicense the >> book before importing it into our repository. I suppose that means the >> original authors, and any other major contributors, should create a >> Software Grant. > I don't expect that there would be any problem getting Fitz and Ben to > join me in such an exercise. There's no question in my mind that we > hold between the three of us the lion's (and tiger's, and bear's, oh > my!) share of the authorship of the English text of the book. > > How does this affect the translations, though? Besides the old > translations long since completed (or abandoned), we have a handful of > active translations ongoing -- some doing their initial passes over the > text, some simply touching up their translations as changes are made in > the English originals. What is the impact on translators in the event > that the book's development moves into the Apache Subversion repository? I'm sure we can give them (partial) commit access to the book, if they're willing to relicense in the same way. We'll need an ICLA from any of them who're not Apache committers yet, of course. I don't see that contributing to book translations is any different from contributing to other parts of our source tree. We've been doing something similar for message translators for ... what is it now, 18 years and counting? (Yes, Subversion is now of "legal age," whatever that means...) -- Brane
Re: The future of the Subversion book
On 10/27/18 1:12 PM, Branko Čibej wrote: > On 18.10.2018 20:40, Branko Čibej wrote: >> On 06.09.2018 15:25, Branko Čibej wrote: >>> On 06.09.2018 15:10, C. Michael Pilato wrote: The book carries a cc-by-2.0 license, with Ben, Fitz and myself named as the copyright holders. I suspect that in order to be absorbed by the PMC, that licensing would have to change to an Apache License. Does that mean that the three primary authors would need to officially re-license it somehow? Or maybe it's a software grant to the ASF (rather like Subversion itself was)? >>> >>> We'd have to ask legal@ but I'd be surprised if we'd be required to >>> re-license the book; it's not code, and the Apache license isn't really >>> suitable. Also we wouldn't really be making releases of it, just updates >>> on the web. >> >> I didn't quite forget about this: LEGAL-421 > > The answer to this question appears to be that we should relicense the > book before importing it into our repository. I suppose that means the > original authors, and any other major contributors, should create a > Software Grant. I don't expect that there would be any problem getting Fitz and Ben to join me in such an exercise. There's no question in my mind that we hold between the three of us the lion's (and tiger's, and bear's, oh my!) share of the authorship of the English text of the book. How does this affect the translations, though? Besides the old translations long since completed (or abandoned), we have a handful of active translations ongoing -- some doing their initial passes over the text, some simply touching up their translations as changes are made in the English originals. What is the impact on translators in the event that the book's development moves into the Apache Subversion repository? -- Mike
Re: Merge dry-run and conflict resolution
[Moving to dev@ as this is more of a development question.] On 30.10.2018 09:35, Jonathan Guy wrote: > Hi all > Just looking over the code for the interactive conflict resolution. > This is just an initial observation but in merge_cmd.c the function > svn_cl__merge calls run_merge then checks for a merge tracking error and then > checks for conflicts. If there were conflicts it runs the interactive > conflict resolver. My question is should the resolver be running if this is a > dry-run? > Thanks for any clarification on this. I think you're correct, since a dry run doesn't (or shouldn't) produce any changes in the working copy, it makes no sense to run the resolver. -- Brane
Re: svn commit: r1845204 - in /subversion/trunk/subversion: mod_authz_svn/mod_authz_svn.c mod_dav_svn/mod_dav_svn.c
On 30.10.2018 10:04, rpl...@apache.org wrote: > Author: rpluem > Date: Tue Oct 30 09:04:14 2018 > New Revision: 1845204 > > URL: http://svn.apache.org/viewvc?rev=1845204=rev > Log: > Fix issue SVN-4782: Do not use (const char*)1 in httpd modules as value for > r->notes. > > mod_authz_svn.c and mod_dav_svn.c add keys to r->notes to memorize boolean > states (FORCE_AUTHN_NOTE, IN_SOME_AUTHN_NOTE, authz_svn-anon-ok, > NO_MAP_TO_STORAGE_NOTE). They use (const char*)1 as values for the keys. This > causes any call to apr_table_clone for r->notes to crash with a SEGFAULT, > because (const char*)1 is an invalid address. mod_http2 in httpd calls > apr_table_clone for r->notes and hence the httpd process crashes. > Hence replace the value of (const char*)1 in these cases with a value of "1". > > * subversion/mod_authz_svn/mod_authz_svn.c > (access_checker, check_user_id): Replace value of (const char*)1 with "1" >in apr_table_setn calls for r->notes table for keys FORCE_AUTHN_NOTE, >IN_SOME_AUTHN_NOTE, authz_svn-anon-ok to set a value with an valid address. > > * subversion/mod_authz_svn/mod_dav_svn.c > (dav_svn__translate_name): Replace value of (const char*)1 with "1" >in apr_table_setn calls for r->notes table for keys NO_MAP_TO_STORAGE_NOTE >to set a value with an valid address. Hi Ruediger, This looks perfect, thank you. It's important enough to be added to CHANGES, in the server-side bugfixes section, so please add a line there, for 1.12.0. The backport process is similar to APR's and I assume httpd's, we use a STATUS file for nominations with 3 PMC +1 required for core changes. We have a script for proposing backports, here's an example: [[[ .../repos/1.11.x$ ../trunk/tools/dist/nominate.pl r1845204 "Prevents a crash in mod_http2." Index: STATUS === --- STATUS (revision 1845205) +++ STATUS (working copy) @@ -48,6 +48,14 @@ Candidate changes: Votes: +1: brane + * r1845204 + Fix issue SVN-4782: Do not use (const char*)1 in httpd modules as value for + r->notes. + Justification: + Prevents a crash in mod_http2. + Votes: + +1: brane + Veto-blocked changes: = Commit this nomination? ]]] (typing y will commit, anything else will revert the change to STATUS). Our currently maintained branches are 1.9.x, 1.10.x and 1.11.x; fixing a crash is important enough to backport to all of them. Your vote won't be binding since you're not a PMC member, but there's nothing wrong with keeping it there. Also, please always use the trunk version of the nominate.pl script. -- Brane
Re: Subversion 1.11.0 up for testing/signing
Thank you all for signing. I published the tarballs now and may be able to announce late this evening if most of the mirrors have caught up ( https://mirror-vm.apache.org/~henkp/cgi-bin/utd.cgi?DATE=2018-10-30:09 ), else tomorrow morning. -- - Julian
Re: svn commit: r1845013 - /subversion/trunk/subversion/tests/cmdline/basic_tests.py
On 30.10.2018 05:51, Daniel Shahaf wrote:
> Branko Čibej wrote on Tue, 30 Oct 2018 01:04 +0100:
>> On 29.10.2018 19:08, Daniel Shahaf wrote:
>>> Good morning Brane,
>>>
>>> br...@apache.org wrote on Sun, 28 Oct 2018 10:40 +:
Add XFAIL tests for issue #4530.
+++ subversion/trunk/subversion/tests/cmdline/basic_tests.py Sun Oct 28
10:40:04 2018
@@ -3050,6 +3050,33 @@ def peg_rev_on_non_existent_wc_path(sbox
+def do_move_with_at_signs(sbox, src, dst, dst_cmdline):
+ sbox.build()
+
+ expected_status = svntest.actions.get_virginal_state(sbox.wc_dir, 1)
+ expected_status.tweak(src, status='D ', moved_to=dst)
+ expected_status.add({dst: Item(status='A ', copied='+',
+ moved_from=src, wc_rev='-')})
+
+ sbox.simple_move(src, dst_cmdline)
+ svntest.actions.run_and_verify_status(sbox.wc_dir, expected_status)
+
+@Issue(4530)
+@XFail()
+def move_to_target_with_leading_at_sign(sbox):
+ "rename to dir/@file"
+
+ do_move_with_at_signs(sbox, 'iota', 'A/@upsilon', 'A/@upsilon')
+
+
+@Issue(4530)
+@XFail()
+def move_to_target_with_leading_and_trailing_at_sign(sbox):
+ "rename to dir/@file@"
+
+ do_move_with_at_signs(sbox, 'iota', 'A/@upsilon', 'A/@upsilon@')
>>> I'm not actually sure these are supposed to work as these tests expect:
>>> supporting A/@upsilon as the first argument like this would prevent us
>>> from adding "foo@upsilon" as a command-line syntax for '"foo" at peg
>>> revision svn_opt_revision_working' in a future minor release. I think
>>> this line of thought applies to the second argument as well.
>> You must have misread what the test does. A/@upsilon (and A/@upsilon@)
>> are the _second_ arguments to 'svn rename'.
> Indeed I have. Apologies.
>
>> The command tested is one of:
>>
>> * 'svn rename iota A/@upsilon' (whch creates A@upsilon, which is wrong)
> Agreed.
>
>> * 'svn rename iota A/@upsilont@' (which creates A/@upsilon@ which is
>> also wrong)
>>
> Agreed.
>
>> So there's no way to rename iota to A/@upsilon. We effectively forbd
>> renames to fiels with leading @-signs, unless one jumps through a lot of
>> hoops. Consider this case, trying to do the rename in the same directory:
>> $ svn mv @bar@ @qux
>> svn: E125001: '@qux' is just a peg revision. Maybe try '@qux@' instead?
>> $ svn mv @bar@ @qux@
>> A @qux@
>> D @bar
>>
>>
>> Notice how the code complains about bare '@qux' but doesn't about
>> 'foo/@qux'. There are so many bugs in those few lines of code that I've
>> not even counted them all yet.
> "@qux" should be equivalent to ".@qux", I assume? Since "." is canonicalized
> to "".
Actually, as the code currently stands, it will error out for "@qux"
("'@qux' is just a peg revision ...") but not for ".@qux" because
canonicalization happens later.
Actually it does error out for ".@qux":
$ svn mkdir .@brl
svn: E29: '@brl': a peg revision is not allowed here
but this happens later, after canonicalisation, yet still before it
tries to create the current directory. This seems to go through the same
code path as 'svn add'.
>>> I can see a number of options:
>>>
>>> - All PATH arguments (and all TARGET formal arguments when the actual
>>> argument isn't a URI) are parsed for peg revisions, no exceptions.
>> They seem to be, but edge cases are handled incorrectly.
> +1
>
> Thanks for the patient answer.
Oh come, you know it wasn't really all that patient, this is me after
all. :)
Truthfully I'm just a bit angry at myself for not adding a bunch of
tests (or insisting they be added) when the peg-revision syntax was
first implemented.
-- Brane
