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

Re: status information

From: Stefan Küng <tortoisesvn_at_gmail.com>
Date: Fri, 18 Jun 2010 19:39:25 +0200

On 18.06.2010 19:11, Greg Stein wrote:
> On Fri, Jun 18, 2010 at 12:28, Stefan Küng<tortoisesvn_at_gmail.com> wrote:
>> ...
>> Since you obviously haven't read my post here:
>> http://svn.haxx.se/dev/archive-2010-06/0250.shtml
>
> I read it. I read practically every post on dev@ *AND* most of the
> posts to commits@.
>
> I didn't respond because I didn't like the idea. We've used flag-based
> APIs in the past (entry_modify comes to mind), and they all tend to
> suck in the long run. They tend to hide what the function is used for,
> and make it very hard to reason about the function. For example,
> searching thru the code, I find the following:
>
> svn_wc__entry_modify(db, local_abspath, svn_kind_unknown,
> &tmp_entry, modify_flags, scratch_pool);
>
> That tells me nothing about what that call is doing. So I need to open
> an editor, look for the call, and track down all assignments to
> modify_flags. And I also need to ensure each member of tmp_entry
> denoted by modify_flags has been assigned.
>
> Just way too hard to work with, and so we're undoing all of those in libsvn_wc.

That's what a documentation of APIs and flags are usually for, so you
don't have to track down the code.
But anyway, this isn't an argument against keeping the features, only
about a mask param.
So how about passing a struct which has bools instead of a mask?
Something like this:

struct status_info_req_t
{
bool get_modifications;
bool get_needslock;
bool get_filesize;
bool get_whatever;
}

With this, you immediately can see in the code what each flag is used
for and what it means.

> At this point, use libsvn_wc APIs if you need to get something done. I
> don't care if you need to use them. Others say "only client".
> Whatever. The simple fact is: the API isn't "done", so use whatever
> you need.

And I thought this mailing list was to be used to discuss stuff, raise
concerns and get to an agreement on how things should be done. Silly me.
Seems it's only "take what's there and stop complaining".

Your attitude sucks.

Stefan

P.S. Since I have now a week off from work, I'll take the time to think
about whether I want to keep working on TSVN. From what I see on trunk,
what I get here about where 1.7 is going and the attitude it doesn't
seem worth my effort anymore. Seems TSVN 1.7 can only get worse than
1.6, so what's the point.
Don't expect anymore posts from me, at least until I made my decision.

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.net
Received on 2010-06-18 19:40:12 CEST

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

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