Re: svn stat on new files

Hello.

Maybe I am misreading something, but I cannot see either concern with
the patch.

On Fri 2002-12-06 at 13:36:29 -0600, Ben Collins-Sussman wrote:
>
> Ugh, read the log and diff for r3746. It looks like your change is
> going to undo that fix...?

Before the patch, it was like (shortened)

  /* only if entry == NULL, i.e. unversioned items */
  stat->text_status = svn_wc_status_none;
  if (path_kind != svn_node_none)
    stat->text_status = svn_wc_status_unversioned;

which results in ("sws_" as shorthand for "svn_wc_status_")

 path_kind |
---------------+-----------------
 svn_node_none | sws_none
 other | sws_unversioned

r3746 changed it so that it becomes

  stat->text_status = svn_wc_status_none;
  if (path_kind != svn_node_none)
    if (is_ignored)
      stat->text_status = svn_wc_status_none;
    else
      stat->text_status = svn_wc_status_unversioned;

 path_kind | !is_ignored | is_ignored
---------------+-----------------+-------------
 svn_node_none | sws_none | sws_none
 other | sws_unversioned | sws_none

In other words: The behaviour has changed for entries which really
exist on disk (path_kind != svn_node_none). If they are on the
ignore-list (that is what is_ignored effectively means, AFAICT), they
have sws_none, beforehand they had sws_unversioned. That is in order
to enable clients to tell the difference when a full status output is
done.

Matt's suggested patch changes this into:

  stat->text_status = svn_wc_status_unversioned;
  if (is_ignored)
    stat->text_status = svn_wc_status_none;

 path_kind | !is_ignored | is_ignored
---------------+-----------------+-------------
 svn_node_none | sws_unversioned | sws_unversioned
 other | sws_unversioned | sws_none

It's obvious that the change of r3746 is still there: it affected
existing nodes, i.e. the "other" row, while Matt's patch affects
non-existing nodes (the "svn_node_none" row). r3746 is about
differentiating between the !is_ignored and is_ignored columns, which
always had equal values in the svn_node_none row (before and after the
current patch).

[...]
On Fri 2002-12-06 at 13:04:00 -0600, Karl Fogel wrote:
> Matt Kraai <kraai@alumni.cmu.edu> writes:
> > Here is a patch which does so. OK to commit?
>
> I think you're solving a different [non]-problem.
>
> This isn't about explicitly ignored files;

See above. His change is neutral regarding is_ignored (by this I mean,
it's the same regardless of the value of is_ignored).

Or do you mean, the status should be sws_none for the cell
(svn_node_none and is_ignored)?

> it's about non-existent filenames being given as arguments to an svn
> command.

Well, it does indeed simply change all non-existent files to
unversioned and therefore implicitly to display a "?" in the command
line client.

A completely different point is whether that new meaning is
consistent. At the start sws_none meant "non-existing". Through r3764
it became "non-existing or ignored". And now it becomes "existing and
ignored". (All also imply "not versioned", of course).

Whereas sws_unversioned started with (all implying "not versioned",
still) "existing", with r3746 it became "non-ignored and existing"
and now would be "non-ignored or non-existing".

Regarding these changes, it looks to me as if the meaning of these
values is simply overloaded and maybe it would be more reasonable to
introduce new values of svn_wc_status_*, instead of picking unused
corner cases and giving them new meanings.

What would the ideal table look like?

 path_kind | !is_ignored | is_ignored
---------------+---------------------+-------------
 svn_node_none | unversioned/missing | missing
 other | unversioned | ignored

You can simply use sws_none instead of missing; I only wanted to avoid
confusion with its already overloaded use from above. As you see, I am
not sure, if unversioned or missing should win in one cell. I can see
the case for either. Just imagine the client prints "I" for ignored,
"-" for missing and "?" for unversioned. Currently the client would
display "?" for both, missing and unversioned.

Hope I did not discuss something different than was meant. ;-)

Bye,

        Benjamin.