You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Ruben Bibas <ru...@gmail.com> on 2010/12/27 16:20:18 UTC

External diffs and temp files

Hello,
I am working with subversion on a debian platform.
I am trying to use either vimdiff or meld as a diff tool.
So I created a script containing either /usr/bin/vimdiff $6 $7 or 
/usr/bin/meld $6 $7.

Everything works fine except that $7 is actually a temp file, and when I 
am done changing the file, the tempfile is saved, but the actual working 
copy has not been modified.

The only similar topic I could find was this one:
http://stackoverflow.com/questions/396176/why-does-svn-diff-sometimes-copy-working-files-to-a-temp-file

However, I don't have any keywords or any of the kind.

Any kind of help would be greatly appreciated.
Many thanks

Ruben

Re: External diffs and temp files

Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
If you want to derive the working file's path, it's in the -L arguments
(argv[3] and argv[5]).  Mind the tabs.

I'd look into scripting something around :diffpatch in Vim: some custom
command you run while editing the file.  In that case, you'll to reverse
the diff before applying it.  (you can use a diff-cmd wrapper,
or the patchutils package, or patch -R, to do that)


Ruben Bibas wrote on Mon, Dec 27, 2010 at 17:20:18 +0100:
> Hello,
> I am working with subversion on a debian platform.
> I am trying to use either vimdiff or meld as a diff tool.
> So I created a script containing either /usr/bin/vimdiff $6 $7 or  
> /usr/bin/meld $6 $7.
>
> Everything works fine except that $7 is actually a temp file, and when I  
> am done changing the file, the tempfile is saved, but the actual working  
> copy has not been modified.
>
> The only similar topic I could find was this one:
> http://stackoverflow.com/questions/396176/why-does-svn-diff-sometimes-copy-working-files-to-a-temp-file
>
> However, I don't have any keywords or any of the kind.
>
> Any kind of help would be greatly appreciated.
> Many thanks
>
> Ruben
>