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

Re: [PATCH] Don't use entries for checking status in svn_wc_status3_t. Was: Re: [WIP] Some quirky parts of libsvn_wc/status.c:assemble_status() for retrieving revisions

From: Greg Stein <gstein_at_gmail.com>
Date: Fri, 23 Apr 2010 13:55:11 -0400

On Fri, Apr 23, 2010 at 11:01, Daniel Näslund <daniel_at_longitudo.com> wrote:
> On Fri, Apr 23, 2010 at 06:23:49AM -0400, Greg Stein wrote:
>> On Fri, Apr 23, 2010 at 05:38, Daniel Näslund <daniel_at_longitudo.com> wrote:
>> > I wanted to keep the current behaviour since the status code is involved
>> > in so _many_ tests and rewriting all of those would cause me to loose
>> > momentum. Guess, what? I've already lost that momentum. :)
>>
>> I suspect you mean svn/status-cmd.c rather than "status code". The
>> real point is "how does 'svn status' present the values in
>> svn_wc_status3_t?". You can provide wc-ng semantics in that structure,
>> and then let status-cmd map those into old-style semantics and
>> display.
>>
>> Then, in a future step, we can discuss altering the output of
>> status-cmd to make more sense and to eliminate all the ugliness.
>
> Ok, how about creating something like this. To be called from inside the
> status callback for compatibility with the testsuite (a temporary thing
> of course).

Well... I think keeping the created_* values in there would be just
fine. It is the crazy semantics of entry->revision that you're trying
to duplicate which is bothering me. If you create a function to return
a revision with those semantics... sure. Go ahead. You're not
"infecting" svn_wc_status3_t with craziness in that case :-)

>...
> Ok, 'we want' is really 'I think we want' but you get the idea.

Whatever you think. My concerns lie around the definition/semantics of
svn_wc_status3_t.

>...

Cheers,
-g
Received on 2010-04-23 19:55:40 CEST

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