[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: Stefan Küng <tortoisesvn_at_gmail.com>
Date: Thu, 19 Mar 2009 19:19:20 +0100

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.

Stefan

-- 
       ___
  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=1356840
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].

Received on 2009-03-19 19:19:48 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.