On Aug 29, 2012, at 13:08, Q. Chap wrote: >>> [SNIP] >> I think that last command needs the 2nd form of 'svn diff' syntax, >> because you're comparing an (arbitrary) url with a working copy path: >> >> So that would be: >> >> $ svn diff --summarize \ >> --old=http://svn.example.com/repos/vendor/libcomplex/2.0 \ >> --new=path/to/workingcopyofcalc/libcomplex > > Interesting. Thank you. > > Couple of questions: > > 1. "--summarize" complains that it can only work on URL-URL diffs. Is there > a work around? > > 2. Running without "--summarize" works, but I see a ton of "mergeinfo" > entries like: > > Property changes on: Somefile > ___________________________________________________________________ > Modified: svn:mergeinfo > Merged /branches/path/Somefile:r19415-19622 > > This is accurate I suppose (what's it indicate?), but gets in the way of > seeing the list of patched files. i.e. "Somefile" is unrelated to any of my > changes. Can this be suppresed? > > 3. Running the above diff also outputs lines related to some files that I > know I never modifed, but did recive updates via the merge. Oddly, these are > all binary files. > > Index: Path/to/bin.dat > =================================================================== > Cannot display: file marked as a binary type. > svn:mime-type = application/octet-stream > > What does this indicate?
Since you appear to be having difficulties getting the URL-to-directory form of svn diff working for your use case, why not use the URL-to-URL version I originally posted? On Aug 28, 2012, at 17:26, Ryan Schmidt wrote: > 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 It answers the question you asked, which was: On Aug 28, 2012, at 15:57, "Q. Chap" wrote: > I'd like carefully examine the files that I've previously patched just to > ensure things still make sense or are required. That is, the command I previously posted will indicate to you what files you previously patched. You can then merge the new version into your working copy, and carefully examine those files and test the project as much as you like before committing them.
