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)