I'd like to put a feature request out there for a --dry-run option to 'svn up'.
There are two things that this would accomplish over 'svn stat --show-updates'.
First, it seems like a natural thing to do; in particular, 'merge'
supports --dry-run and after using Git for a while my mental model of
update is it's just a special case of merge. IMO at least, two ways of
doing the same thing isn't necessarily a bad thing.
But even more to the point, 'svn stat --show-updates' *doesn't work*
for many of the times when I want 'svn up --dry-run', because it
doesn't accept a -r argument. Here's a common scenario:
1. I have revision 1000 checked out and am editing foo.txt
2. Other people make a few commits to other files
3. I commit foo.txt as revision 1010
[note that I now have a mixed-revision working copy where foo.txt is
on 1010 and everything else on 1000]
4. Other people make more commits to files, e.g. up to 1020
5. I do something that makes svn complain about the fact that I'm on a
mixed-revision copy
Now I have two reasonable options to clear that error: update to the
current head (1020) or update to the most recent version of anything I
have checked out (1010). A lot of the time I want to do the *second*
of those two options, because it's more likely to just give me small
updates and less likely to update a file that will prompt a
45-minute-or-more rebuild. It's also less likely to result in merge
conflicts. (Yeah they might have to be dealt with eventually, but (i)
not necessarily and (ii) I might not want to deal with those later.)
So what I would *like* to do is something like:
6. See what would be changed if I update to 1010
7a. If it looks like it'll be a big update, just update to HEAD
7b. If it looks like a small update, update to 1010
But I don't know any way to do #6 in Subversion, and this is exactly
what 'svn up --dry-run' would provide.
(If there *is* actually a way to do #6, I'm all ears.)
Evan
Received on 2015-04-03 21:29:02 CEST