[Bug Report] BlockPeggedExternals doesn't work as expected, depend on where external is defined

[Johan Backström]

It seems like this setting is not respected if the external property is defined on a directory level which is above the actual local path for the external. 

Example on simple local repo to reproduce the problem below. 
repo folder structure: 
test_library_proj

|-- lib_file1.txt
test_library2_proj
|-- lib2_file1.txt
test_project
|-- somefolder
    |-- externals 

External definitions (output of svn propget -R svn:externals  in test_project):
. - ^/test_library2_proj@7 somefolder/externals/test_lib2

somefolder\externals - ^/test_library_proj@3 test_lib

So, the external for test_library1 is defined as a property of the test_project\somefolder\externals folder, while the external for test_library2 is defined as a property of the  test_project folder. 
Now, if I make changes to both lib_file1.txt and lib_file2.txt in the test_project file structure, then open the commit dialog on from the test_project level, both changes are listed but only the changes to lib_file1.txt are greyed out and cannot be committed. 

Using version 1.14.9 (TortoiseSVN 1.14.9, Build 29743 - 64 Bit , 2024/11/29 19:43:55). 

[Daniel Sahlberg]

Hi,

I assume you have BlockPeggedExternals set to "true", ie the default value.

Can you test if the following script is an accurate reproduction of what you describe?

[[[

rmdir /s /q repo wc
mkdir repo
svnadmin create repo
svn co file:///%~dp0repo wc
cd wc
mkdir test_library_proj test_library2_proj test_project\somefolder\externals
echo file1>test_library_proj\lib_file1.txt
echo file2>test_library2_proj\lib2_file1.txt
svn add *
svn propset svn:externals "^/test_library2_proj@1 somefolder/externals/test_lib2" test_project
svn propset svn:externals "^/test_library_proj@1 test_lib" test_project\somefolder\externals

svn ci -m "base struct"

svn up

echo change1>test_project\somefolder\externals\test_lib\lib_file1.txt
echo change2>test_project\somefolder\externals\test_lib2\lib2_file1.txt

tortoiseproc /command:commit /path c:\temp\wc

cd %~dp0

]]]

It seems to reproduce the issue you describe.

I stumbled on another bug in the same dialog. Even when a file cannot be checked using the mouse, the "Check: All" function will happily check even the un-clickable file.

Thanks for the report - I will try to take a look at this in the weekend.

Kind regards,

Daniel

[Johan Backström]

Hi, 

Can confirm your script reproduces the issue very accurately!

Now when you mentioned it I also noticed the "All" function bug, it obviously also circumvents the check. 
Another interesting thing that seem to affect the original issue is that if any other external is added as a property on the root level, it seem to trigger the check to work as expected for all externals. 
So my guess is that the check is only triggered when a local file or folder which is an external is encountered, and then it continues to be active for all subfolders, or something like that. 

Thanks for the quick response! 

Johan