"Compare with working copy" on file from log window passes wrong path to external comparison tool

89 views
Skip to first unread message

Tobias Knauss

unread,
Sep 16, 2020, 6:39:21 AM9/16/20
to TortoiseSVN
When using "Compare with working copy" on a file in the file list of the log messages window, the external comparison program is started with an incomplete path:
(line breaks added for convenience)
"C:\Program Files\Beyond Compare 4\BCompare.exe"
  "C:\Users\toknauss\AppData\Local\Temp\CVisitechLLS_CCalibData_CPhotoheadPosition.cs-rev3347.svn000.tmp.cs"
  "D:\sw_developme\hardware\CVisitechLLS_CCalibData_CPhotoheadPosition.cs"
  /title1="CVisitechLLS_CCalibData_CPhotoheadPosition.cs - Revision 3347" /title2="CVisitechLLS_CCalibData_CPhotoheadPosition.cs : Working Copy" /leftreadonly

The path
"D:\sw_developme\hardware\CVisitechLLS_CCalibData_CPhotoheadPosition.cs"
is incomplete and should be
"D:\sw_development\di_sw\\hardware\CVisitechLLS_CCalibData_CPhotoheadPosition.cs".

The special thing about this is: The URL of this file in the working copy is
<servername>/svn/di_sw/branches/v.0.24_KzK2Cam/hardware/CVisitechLLS_CCalibData_CPhotoheadPosition.cs,
and the file that I try to compare to this working copy is on the parent branch
<servername>/svn/di_sw/branches/v.0.24/hardware/CVisitechLLS_CCalibData_CPhotoheadPosition.cs

If the file to compare is on the same branch, it works.

If I use another branch, I also get wrong results, e.g.
"D:\sw_development\di_sw\hardware\trunk\hardware\CVisitechLLS_CCalibData_CPhotoheadPosition.cs"
The file to compare was from
<servername>/svn/di_sw/trunk/hardware/CVisitechLLS_CCalibData_CPhotoheadPosition.cs


Stefan

unread,
Sep 16, 2020, 12:52:38 PM9/16/20
to TortoiseSVN
is the file shown in gray in the file list? That would mean it's not a child of the path you're showing the log for.

Stefan

unread,
Sep 16, 2020, 1:14:33 PM9/16/20
to TortoiseSVN
if yes, then it's fixed in r28969

Tobias Knauss

unread,
Sep 22, 2020, 6:12:22 AM9/22/20
to TortoiseSVN
No, it's blue.
I'm using TortoiseSVN 1.14.0, Build 28885 - 64 Bit , 2020/05/24 13:32:45

I also tested with
TortoiseSVN 1.14.0, Build 28975 - 64 Bit -dev, 2020/09/19 07:09:46
and it still fails.
Should be very easy to reproduce.

FYI, the link "https://nightlybuilds.tortoisesvn.net/1.11.x/" to the Release Candidates in the section "Stable Branch Builds" on your web page https://tortoisesvn.net/downloads.html does not work.
And why is the installer 28973 in "latest" older than the installer 28975 in "1.14.x"? 28973 not the _latest_ then, although it was placed there on 22.09, whereas the newer 28975 was placed in "1.14.x" a day before... confusing.

Stefan

unread,
Sep 22, 2020, 12:16:56 PM9/22/20
to TortoiseSVN
On Tuesday, September 22, 2020 at 12:12:22 PM UTC+2 Tobias Knauss wrote:
No, it's blue.
I'm using TortoiseSVN 1.14.0, Build 28885 - 64 Bit , 2020/05/24 13:32:45

I also tested with
TortoiseSVN 1.14.0, Build 28975 - 64 Bit -dev, 2020/09/19 07:09:46
and it still fails.
Should be very easy to reproduce.

No, it isn't. Please provide more detailed info:
* what's your wc root
* from where do you show the log
* which file do you want the diff for
 

FYI, the link "https://nightlybuilds.tortoisesvn.net/1.11.x/" to the Release Candidates in the section "Stable Branch Builds" on your web page https://tortoisesvn.net/downloads.html does not work.

Will fix soon.
 
And why is the installer 28973 in "latest" older than the installer 28975 in "1.14.x"? 28973 not the _latest_ then, although it was placed there on 22.09, whereas the newer 28975 was placed in "1.14.x" a day before... confusing.


commit on trunk (latest), then merge to 1.14.x later. So that's why 1.14.x is newer.
The filedates are different because a build takes a long time...

Tobias Knauss

unread,
Sep 25, 2020, 4:04:31 AM9/25/20
to TortoiseSVN
I just reproduced it on a new repo in 5 minutes:

1) Create empty repo with trunk/tags/branches (rev.1)
2) in trunk, create test.txt and folder-1\folder-1-1\folder-1-1-1\test111.txt
3) open the text files and insert some text
4) commit (rev.2)
5) create branch b01 from working copy (trunk), switch working copy (rev.3)
6) open the text files and edit the text
7) commit (rev.4)
8) create branch b02 from working copy (b01), switch working copy (rev.5)
9) open the test111.txt and edit the text
10) commit (rev.6)
11) open the other text file and edit the text
12) commit (rev.7)
13) open log window on the  test111.txt . You will see revisions 2 to 6.
14) select rev.4; in the lower pane select  test111.txt (blue; the test.txt is grey), right-click, choose "compare with working copy"
15) Beyond Compare 4 starts (in my case), showing "test111.txt - revision 4" on the left, with the content of the file, and "test111.txt - working copy" on the right, saying "file not found". The path "D:\svn\spielwiese2\branches\b01\folder-1\folder-1-1\folder-1-1-1\test111.txt" is given for the right file, although the directory does not exist on my disk, because I did not update the branch folder, so the branches are not on the disk, but only in the SVN repo. Remember, I switched the working copy to the specific branches in the trunk folder.
tsvn bug - compare with working copy.png

Stefan

unread,
Sep 25, 2020, 2:14:14 PM9/25/20
to TortoiseSVN
the problem here is that the file in rev 4 is from the b1 branch, while the wc is on b2. So technically it's not possible to do a "compare with working copy".

Tobias Knauss

unread,
Oct 3, 2020, 5:09:42 AM10/3/20
to TortoiseSVN
Hello Stefan,

why is this not possible? In my opinion it indeed is technically possible.
If I open the log window on a folder, the you know the SVN path of the working copy (in this case branch b2). So you can trace the file back and forth inside the SVN history. Therefore you should also know, which file of the working copy belongs to the file inside branch b1, that I selected when choosing "compare with working copy".
There may of course be situations where this does not work, e.g. if files were moved/copied. But also in case of renaming it should be possible to find the correct file and start the comparison.

Best regards
Tobias
Reply all
Reply to author
Forward
0 new messages