Re: svn commit: r1196005 - in /subversion/trunk/subversion/svn: cl.h copy-cmd.c util.c

["C. Michael Pilato" <cm...@collab.net>]

On 11/01/2011 10:20 AM, julianfoad@apache.org wrote:
> Author: julianfoad
> Date: Tue Nov  1 14:20:28 2011
> New Revision: 1196005
> 
> URL: http://svn.apache.org/viewvc?rev=1196005&view=rev
> Log:
> Make 'svn' reject a non-empty peg revision specifier where a peg revision
> does not make sense, such as on targets of 'svn add'. Allow the 'copy'
> subcommand to accept '@HEAD' on the destination path as a special exemption
> because that usage appears in the test suite.

Do you get the sense that this usage in the test suite for 'svn copy' was
anything beyond a mere accident?

-- 
C. Michael Pilato <cm...@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Re: svn commit: r1196005 - in /subversion/trunk/subversion/svn: cl.h copy-cmd.c util.c

[Julian Foad <ju...@btopenworld.com>]

I (Julian Foad) wrote:
> I'll remove the exception, and change the test for a
> destination path ending in '@HEAD' to one ending in '@' so
> that it still tests the ignoring of an empty peg revision
> specifier.

r1196050.

- Julian

Re: svn commit: r1196005 - in /subversion/trunk/subversion/svn: cl.h copy-cmd.c util.c

[Julian Foad <ju...@btopenworld.com>]

C. Michael Pilato wrote:
> On 11/01/2011 10:20 AM, julianfoad@apache.org wrote:
> > Make 'svn' reject a non-empty peg revision specifier where
> > a peg revision does not make sense, such as on targets of
> > 'svn add'. Allow the 'copy' subcommand to accept '@HEAD' on
> > the destination path as a special exemption
> > because that usage appears in the test suite.
> 
> Do you get the sense that this usage in the test suite for
> 'svn copy' was anything beyond a mere accident?

Now I've taken a look... no, actually it appears to have been an assumption made in issue #3416 "Cannot add or commit 'dir/@file.txt'" and more specifically in issue #3651 "svn copy does not eat peg revision within copy target path".  Those issues were resolved by making the target ignore ("eat") unwanted peg revisions, but what we should have done instead is reject any unexpected peg revision, which is what my patch does now.

A test run indicates there's only one such test, copy_tests.py 62.

Since these are relatively new issues (2009/2010) and the test for a target ending with "@HEAD" was only introduced then, I think we are safe to remove that special case.

Thanks for querying.

I'll remove the exception, and change the test for a destination path ending in '@HEAD' to one ending in '@' so that it still tests the ignoring of an empty peg revision specifier.

- Julian