Details
-
Improvement
-
Status: Open
-
Major
-
Resolution: Unresolved
-
1.4.x
-
None
-
Mac OS X
Description
It would be helpful to allow to disable keyword "un-expansion" during
'svn diff' on command line.
I've found this behaviour use case:
Seems that if i have svn:keywords set on a file, when I do an svn diff
that goes to a 3rd-party diff tool such as AraxisMerge, SVN creates a
"normalized' version of the file with the keywords (such as Id)
un-expanded and passes that temp file to AraxisMerge
As a result, if I make any changes to the text file in Araxis, it
modifies the tmp un-expanded file and not the original
This happens on 1.4.4 and 1.5.2 versions in MacOSX
Is there any way to disable this un-expansion on command line in svn diff?
I've confirmed with Araxis Support that they are getting "wrong"
parameters from svn diff into their 'araxissvndiff' utility. When a
particular file has "svn:keywords" property set, the file they get is
pointing to somewhere in /tmp directory. If I remove the svn:keywords
with propdel, then same 'svn diff' results in the "correct" local file
being passed into Araxis. Here's the sample output:
toli@tolimac:~/dev/marketcetera/code/public/source$ svn --version
svn, version 1.5.2 (r32768)
compiled Sep 19 2008, 14:28:09
svn diff AbstractFIXMessagesView.java
Index: AbstractFIXMessagesView.java
===================================================================
arg 0 = /Applications/DevApps/AraxisMerge/Utilities/araxissvndiff
arg 1 = -u
arg 2 = -L
arg 3 = AbstractFIXMessagesView.java (revision 9884)
arg 4 = -L
arg 5 = AbstractFIXMessagesView.java (working copy)
arg 6 = .svn/text-base/AbstractFIXMessagesView.java.svn-base
arg 7 = /var/folders/TL/TLHJYlwRHviA+6Qs-2mN3++++TI/-Tmp-/svndiff.3.tmp
If i do 'svn propdel svn:keywords" on the file, i get the right
"AbstractFIXMessagesView.java" path as arg7.
Would be nice to have a command-line switch to disable this "unexpansion" so
that 3rd-party apps that can handle it get the right path to the file, not some
tmp file - that way, users can modify the text in Araxis and save it to the
correct location.
The full email exchange with Araxis along with possible workaround to
disable "un-expansion" altogether is below:
<Araxis support>
If the file for which the "svn diff" is performed has keyword
expansion (for $Id$, $Revision$, etc.) or end of line character
translation enabled then Subversion will create what it calls a
'normalized form' of the working file before performing the diff. The
temporary file you're seeing is the normalized form of your working
file. The normalized form un-expands keywords and converts end-of-line
sequences back into their original repository form. This has the
overall effect of preventing differences due keyword expansion and end
of line translation from being reported.
The following page describes the svn:keywords and svn:eol-style properties:
http://www.developer.com/tech/print.php/10923_3503151_4
There doesn't appear to be any way of disabling the creation of the
normalized form of the working file via command line options, which is
a shame since Araxis Merge is able to filter out differences due to
keyword expansion (using the Regular Expression filter options) and
end-of-line character differences.
It might be worth filing an enhancement request against Subversion to
enable this normalization to be skipped when a third-party (e.g.
Araxis Merge) diff program is being used. Another option would be to
turn off the keyword and eol expansion for your source files, but I
doubt that's acceptable. Another option would be to build your own
customized version of the subversion client tools so that they skip
the creation of the normalized form of the file. In the case of
subversion 1.4.4, you might be able to get away with editing the
relevant part of the file_diff function in diff.c from:
SVN_ERR(svn_wc_translated_file2
(&translated, path,
path, adm_access,
SVN_WC_TRANSLATE_TO_NF
| SVN_WC_TRANSLATE_USE_GLOBAL_TMP,
pool));
to just:
translated = path;
--
http://subversion.tigris.org/servlets/BrowseList?list=users&by=thread&from=689135
Original issue reported by toli