Thomas Orgis created SVN-4844:
---------------------------------

             Summary: Avoid copies in mixed-revision working copies by default 
and add --allow-mixed-revisions for copy
                 Key: SVN-4844
                 URL: https://issues.apache.org/jira/browse/SVN-4844
             Project: Subversion
          Issue Type: Improvement
          Components: cmdline client
    Affects Versions: 1.13.0
         Environment: Any platform, testing on GNU/Linux command line.
            Reporter: Thomas Orgis


As agreed in the [IRC 
discussion|https://colabti.org/irclogger/irclogger_log/svn?date=2020-01-15#l78],
 I hereby suggest adding a check to the {{copy}} command for a mixed-revision 
working copy just like for the {{merge}} command, including the switch 
{{--allow-mixed-revisions}} with the same semantics.

The motivation is that this procedure will break on the merge with a bogus tree 
conflict:
{code:sh}
svnadmin create repo
svn co file://`pwd`/repo wc
cd wc
svn mkdir A
svn commit -m m
echo content > A/file
svn add A/file
svn commit -m m
# An svn up here would fix things.
svn copy A B
svn commit -m m
# Merge would also fail without any change to merge.
echo content >> A/file
svn commit -m m
svn merge ^/A B
{code}
If the {{copy}} operation would check for the mixed-revision working copy and 
bail out like {{merge}} does, the user might think again and do {{svn up}}, 
then {{svn copy}} and have no unjustified tree conflict in the merge.

Of course {{svn copy ^/A B}} would also work, but I do see no value in the 
inconsistency of having to use URLs for an operation that has all paths in the 
current wc, especially when in the current situation, the simpler alternative 
just works without further notice and shoots you in the foot only when you 
attempt to merge later on.

The implementation is hopefully easy, lifting the operation from {{svn merge}}.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to