> > Hello,
> > my colleagues found a issue with the definition of external diff programs
> > today which I can reproduce. So it still exists in TortoiseSVN 1.7.7.
> > The issue is, that the external diff program defined (WinMerge in our case)
> > is being used as expected for comparing two revisions past, but for
> > comparing the working copy with a past revision Tortoise's diff program
> > is being used. This happens from the graph as well as from the log dialogue.
> "compare with working copy" first creates a unified diff (patch) file,
> and then uses TMerge to 'apply' that patch file in reverse to the
> working copy.
Ok, but why can the check for modifications command then use WinMerge?
This one obvisously not using this unified diff format. How does this come?
> Since TMerge is the only UI tool that can apply patch files (as far as
> I know), TMerge is used unconditionally for this task.
> WinMerge can not apply a patch file (the issue for such an enhancement
> is open in their issue tracker for years).
> > The graph has an additional issue: depending on whether you've
> > selected the working copy first and the other revision afterwards
> > or vice versa the context menu has the view diff option or not.
> > In my eyes that's a bug as well.
> Nope, not a bug. The first selected revision determines the action
> since in case of multiple selected revs, that's the 'root' revision.
Hm? That sounds prety illogically in this case. How does it matter if
I begin the process of compairing two versions (the revision and the wc)
with selecting the revision first and then the wc from first selecting the
wc and then the revision? Isn't it like a+b = c and b+a = c?
If not it would not make any sense to me at all. Might be that it
requires additonal logic on the displaying of that popum menu, but for us
users this would create a more consistent user experience!