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
