[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: SubWCRev.exe

From: Simon Large <simon.tortoisesvn_at_googlemail.com>
Date: Thu, 19 Mar 2009 22:25:42 +0000

2009/3/19 Stefan Küng <tortoisesvn_at_gmail.com>:
> Simon Large wrote:
>> 2009/3/6 Jean-Marc van Leerdam <j.m.van.leerdam_at_gmail.com>:
>>> Simon,
>>>
>>> 2009/3/6 Simon Large <simon.tortoisesvn_at_googlemail.com>:
>>>> 2009/3/6 Stefan Küng <tortoisesvn_at_gmail.com>:
>>>>> Lucas Majewski wrote:
>>>>>> Running 1.5.9.15518
>>>>>>
>>>>>> per documentation from
>>>>>> http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-subwcrev-keywords.html
>>>>>>
>>>>>> $WCINSVN?TText:FText$ is replaced with TText if the entry is versioned,
>>>>>> or FText if not.
>>>>>>
>>>>>> I wanted to use $WCINSVN$. It works fine when the WorkingCopyPath is an
>>>>>> actual working copy. When WorkingCopyPath is not a working copy the app
>>>>>> exists wiht "XXX' is not a working copy and does not perform any
>>>>>> substitution or even creation of DstVersionFile. I would expect that
>>>>>> when WorkingCopyPath  is not a working copy all substitutions defined in
>>>>>> in template are substituted with blank or something like that and FText
>>>>>> gets replaced for WCINSVN.
>>>>>>
>>>>>> Am I using it wrong?
>>>>> SubWCRev works with working copies. If you use it on normal folders, it
>>>>> can't retrieve the necessary information and quits with an error.
>>>>> It wouldn't be a good idea to do string replacements in such a case.
>>>> Err, so why do we even have this keyword? By definition it can only
>>>> ever produce a true result.
>>>>
>>> Maybe because it processes generated and/or ignored files inside working copies?
>>>
>>> The FText can be 'This is a generated file, do not make modifications to it'
>>
>> Reviving this thread because having looked at the code I think the
>> logic is flawed.
>>
>> Firstly you cannot use SubWCRev on a single file, or at least not at
>> the moment. The test.tmpl file in the subwcrev source dir gets filled
>> out with the default unknown information when called for a versioned
>> file.
>>
>> Secondly, looking in status.c where the WC crawl is done we see
>> getallstatus() which I believe is called for every item in the WC.
>>
>> Line 158 has:
>>     sb->SubStat->HasMods = TRUE;
>> which is OK. HasMods was initialised to FALSE, but if any file or
>> folder is modified the variable will be set TRUE giving an overall
>> modified status.
>>
>> Line 144 has:
>>     sb->SubStat->bIsSvnItem = false;
>> and lines 154 and 157 have:
>>     sb->SubStat->bIsSvnItem = true;
>>
>> Here the variable is set FALSE before scanning each item and set TRUE
>> if that item is versioned. But when that happens in a WC crawl the
>> result only applies to the last item that was crawled and we have no
>> idea what the crawl order will be.
>>
>> Similar stuff happens with the lock date/author/comment starting at
>> line 180. You only get the information for the last item crawled. Even
>> if the information were made sticky, which item would you use the info
>> from?
>>
>> I just tested on a simple WC where I have a lock on a file. It doesn't
>> show up at all in the keyword substitutions.
>
> Fixed in r15794.

I have updated the docs on trunk and merged the source change back to
the 1.6.x branch but the 1.6.x potfile is not updated yet. I will wait
for 1.6.0 release now as I don't want to make more changes for the
translators at the last minute.

Simon

-- 
:       ___
:  oo  // \\      "De Chelonian Mobile"
: (_,\/ \_/ \     TortoiseSVN
:   \ \_/_\_/>    The coolest Interface to (Sub)Version Control
:   /_/   \_\     http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=1358526
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-03-19 23:25:56 CET

This is an archived mail posted to the TortoiseSVN Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.