Re: problem using vendor branch feature (folder case mismatch)

On 12/1/2015 10:29 PM, Stefan Küng wrote:
> On 01.12.2015 13:14, Stefan Hett wrote:
>> Hi,
>>
>> Environment:
>> Win 7 64-bit
>> TSVN current nightly of 1.9 (1.9.99 build 27005)
>>
>> Steps to reproduce:
>> 1. create the following file structure in a repository (correct case is
>> important!)
>> trunk
>> /- Test
>> /- test1.txt
>> 2. create a test folder (not under SVN control) of the following structure
>> VendorTest
>> /- test
>> /- test2.txt
>> 3. Drag+Drop (with right click) the VendorTest folder onto trunk and
>> select "SVN Vendorbranch here"
>>
>> Afterwards consult the commit dialog of the change.
>>
>> Actual result:
>>
>>
>> Expected result:
>> test/test1.txt would not be marked as "missing".
>> Also it looks like the Test/test1.txt entry is weird here.
> I get slightly different results and a thrown exception.
> I fixed the exception in r27008 though, but I'm not sure if that fixes
> your issue as well.
I re-ran the test with the latest nightly (r27008) and the test case was
also resolved for me.
Thanks for the quick fix. :-)
>> Please note that I was actually tracing down a case where added files
>> were still listed as "Unversioned" rather than added in the commit
>> dialog (even though trying to add them brought up a dialog showing the
>> "Undo Add" entry, suggesting they were actually already added).
>> Since the triggering issue (case difference in the Test folder) seems to
>> be the same, I take it chances are for both problems actually suffering
>> the same underlying issue.
> Can you retrace how you got such a situation?
I reran the original case and it seems to have been fixed too. Maybe the
explanation lies in the code review I did on the code section which you
applied the change to in r27008:

I'm wondering the following line here:
vv = versionedFiles.begin();

While I don't want to waste your time, I can't spend the necessary time
atm to do a thorough code/design review on that part. So pardon me if
I'm completely off and the reasoning for that code lies in the intended
design.

The problem this line might cause is that if the first entry is removed,
the second entry in the list would never be touched (because of the v++
increment in the for-loop).
In addition to that, this code section seems to have a runtime of O(n^2).
If I'm not mistaken, the following change would resolve both "problems":

Again, this is all under the presumption that the restart of the loop is
not essential for this particular code.

-- 
Regards,
Stefan Hett, Developer/Administrator
EGOSOFT GmbH, Heidestrasse 4, 52146 Würselen, Germany
Tel: +49 2405 4239970, www.egosoft.com
Geschäftsführer: Bernd Lehahn, Handelsregister Aachen HRB 13473
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3149076
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].