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

Re: svn_wc_translated_file3

From: Greg Stein <gstein_at_gmail.com>
Date: Mon, 9 Aug 2010 15:20:04 -0400

On Mon, Aug 9, 2010 at 13:54, Hyrum K. Wright
<hyrum_wright_at_mail.utexas.edu> wrote:
> On Mon, Aug 9, 2010 at 12:11 PM, Hyrum K. Wright
> <hyrum_wright_at_mail.utexas.edu> wrote:
>> On Mon, Aug 9, 2010 at 11:51 AM, Stefan Küng <tortoisesvn_at_gmail.com> wrote:
>...
>>> * new API svn_wc_translated_file3():
>>>  svn_client_translated_file(const char ** resultfile,
>>>      svn_boolean_t * copyCreated,
>>>      const char *  wcfile,
>>>      svn_boolean_t deleteOnPoolCleanup,
>>>      apr_uint32_t  flags,
>>>      apr_pool_t*   pool)
>>>
>>> the flags would be the same as now: SVN_WC_TRANSLATE_FORCE_EOL_REPAIR and
>>> SVN_WC_TRANSLATE_FORCE_COPY.
>>> The API would work like this:
>>> if SVN_WC_TRANSLATE_FORCE_COPY and SVN_WC_TRANSLATE_FORCE_EOL_REPAIR is not
>>> specified and the BASE file is available locally and uncompressed, just
>>> return the path to that file.
>>> Else create a temp copy of the BASE file and return that path.
>>> deleteOnPoolCleanup of course would get ignored if the file is available
>>> locally uncompressed and both SVN_WC_TRANSLATE_FORCE_COPY and
>>> SVN_WC_TRANSLATE_FORCE_EOL_REPAIR are not specified.
>>>
>>> The bool copyCreated would get set to true by the API if it created a copy
>>> and set to false if it just returned the path to the existing BASE file.
>>>
>>> That way, I could get the file very fast if it's possible, but still would
>>> get the file in a slow way if it's not possible.
>>
>> Whatever we do, I'm -1 on any solution that uses bitflags.
>
> Daniel suggests some context here.  We've been burned in the past by
> APIs which use bitflags (see svn_wc__entry_modify()).  Not that there
> is any guarantee of badness, but bitflags tend to add obfuscation and
> control flow difficulties to a function.  And it's just plain hard to
> read.
>
> I realize that booleans are functionally equivalent, and may take a
> bit more typing, but I'd suggest we use them wherever possible,
> especially in out public API.
>
> -Hyrum (who offers the following for clarification of his feelings,
> not with the intent to start a religious war)

I have the same feelings about bitflags. Switching to booleans, or
simply using several functions (ie. instead of bools to alter "big"
semantics), is much more preferable.

And yes, I also realize Stefan was just using flags as a demonstrative
placeholder...

Cheers,
-g

p.s. and even more asinine is using "apr_uint32_t" for the flags
rather than a plain fuckin' "int".
Received on 2010-08-09 21:20:42 CEST

This is an archived mail posted to the Subversion Dev mailing list.