On Aug 28, 2012, at 15:57, "Q. Chap" wrote:
> When I merge the updates from "/vendor/libcomplex/2.0" to my project
> trunk/branch I will have many updated files in that working copy prior to
> commit.
>
> Most of these updates I'd like to accept as-is, because they reflect the
> vendor's changes. However, I'd like carefully examine the files that I've
> previously patched just to ensure things still make sense or are required.
> (Even if SVN can "successfully" merge the changes.)
>
> What command(s) should I use to bring in the "libcomplex/2.0" changes but
> identify the all files I ever messed with?
These are two separate operations.
Merging is as in the book:
$ cd working-copies/calc
$ svn merge ^/vendor/libcomplex/1.0 \
^/vendor/libcomplex/current \
libcomplex
… # resolve all the conflicts between their changes and our changes
$ svn commit -m "merging libcomplex-1.1 into the main branch"
…
In fact I prefer to be explicit about what I'm merging, so if I'm upgrading my
copy of the code from 1.0 to 2.0 then I do:
$ svn merge ^/vendor/libcomplex/1.0 \
^/vendor/libcomplex/2.0 \
libcomplex
And if you want to figure out what files you've modified in your copy of the
code, that's a different separate command. Assuming you originally copied
libcomplex 1.0 into your "calc" project as the book shows:
$ svn copy http://svn.example.com/repos/vendor/libcomplex/1.0 \
http://svn.example.com/repos/calc/libcomplex \
-m "bringing libcomplex-1.0 into the main branch"
And then subsequently modified your copy in "calc" in some way and committed
those changes, you can see which files you changed using this command:
$ svn diff --summarize \
http://svn.example.com/repos/vendor/libcomplex/1.0 \
http://svn.example.com/repos/calc/libcomplex
If you want to see the actual diffs, not just the names of the files, omit the
--summarize flag.
