On Thu, Jan 26, 2017 at 08:54:52PM +0000, Julian Foad wrote:
> When I "svn rename" one or a few files,
> svn mv foo.txt foo2.txt
> svn mv dir/bar.txt bar.txt
> and want to commit just these files (not a whole subtree), I can write the
> new filenames easily by using the shell's filename completion or copying
> them from a directory listing.
> svn commit foo2.txt bar.txt
> But svn currently complains that as these files are moved I also need to
> list their *old* names.
> svn: E200009: Commit failed (details follow):
> svn: E200009: Cannot commit '/home/julianfoad/tmp/svn/mv-commit/wc/foo2'
> because it was moved from '/home/julianfoad/tmp/svn/mv-commit/wc/foo' which
> is not part of the commit; both sides of the move must be committed together
> svn commit foo2.txt bar.txt foo.txt dir/bar.txt
> Is it time to make 'svn' offer to find and commit the corresponding old
> names, without making me do it manually?
> I was doing this in my real-life filing of documents at home the other day,
> and it seemed unnecessarily obstructive and cumbersome.
> (There are several details we can bikeshed about what it should do exactly
> -- such as what if we only specify the old path, and should it prompt
> interactively, or need a new option, or do it by default -- but first do we
> agree that a change in this direction would be good?)
Yes, I agree it would. And I think we should expand on this idea and
start looking for more ways of making SVN easier to use with respect
For instance, since 1.8 SVN asks whether local moves should be updated or
be broken. I believe breaking moves on updates is never what users want.
As far as I recall, the concern here has always been about cases where
the user is passing specific arguments, e.g. should 'svn up dir', where
'dir/child' was moved to 'otherdir/child', update just 'dir' or both 'dir'
and 'otherdir/child'? SVN asks users to make this decision at the conflict
I think such questions simply boil down to whether we expect path arguments
to represent working copy "paths" or working copy "nodes" addressed by path.
My impression is that many of our users expect SVN to handle such details
for them, let them worry about their code, and worry less about how SVN's
working copy works and how SVN represents moves.
Received on 2017-01-27 10:18:32 CET