On 13.06.2012 17:10, Julian Foad wrote: > Branko Čibej wrote: > >> However, I shall now >> demonstrate that Subversion already provides that functionality: > This demo doesn't seem to include the replacement of a node, which is the > case in question.
Well sure, It's not intended to; after all, their own tool obviously doesn't handle replacements if it provides input for code review in a format that ignores all tree-level changes. It doesn't take much effort to run "svn status" first and look for /^R/. One alternative in that case is to write a --diff-cmd compliant tool that will record old and new file names to populate their change-description file (along with building a tree of contents), although you won't get keywors expanded in that case. But that's all beside the point. Providing an API that locates pristine files on disk is inherently wrong. * keyword expansion, eoln conversion, etc. have not been performed * the files may be compressed, or packed, or both * someday in the future, pristine files may not even exist All of the above is solved by using "svn cat" to get the /contents/ of the pristine file, which really is all they're interested in. And it avoids having people mess about in the .svn directory. -- Brane
