[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: Wed, 18 Mar 2009 22:24:18 +0000

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
>>>> 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

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

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.


:       ___
:  oo  // \\      "De Chelonian Mobile"
: (_,\/ \_/ \     TortoiseSVN
:   \ \_/_\_/>    The coolest Interface to (Sub)Version Control
:   /_/   \_\     http://tortoisesvn.net
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-03-18 23:24:31 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.