On Mon, Jun 15, 2026 at 8:48 AM Branko Čibej <[email protected]> wrote:
On 14. 6. 2026 21:54, Timofei Zhakov wrote:
On Sun, Jun 14, 2026 at 12:56 AM Branko Čibej <[email protected]>
wrote:
On 14. 6. 2026 00:25, Timofei Zhakov wrote:
On Sat, Jun 13, 2026 at 9:58 PM Branko Čibej
<[email protected]> wrote:
On 13. 6. 2026 21:49, Timofei Zhakov wrote:
First of all, I find it a bit weird that there is no
easy way to recover the real node kind (not the one in
subversion but in the system's FS)
from svn_client_status6(). Although it is present in
the WC API (svn_wc_status3_t->actual_kind), it isn't in
the client equivalent. There is only a hacky way to
use svn_client_status_t->backwards_compatibility_baton
which is a void* that actually describes a
svn_wc_status3_t so one could use the field from it (if
they really know what they're doing).
subversion/include/svn_wc.h:svn_wc_status3_t:
[[[
/** The actual kind of the node in the working copy.
May differ from
* @a kind on obstructions, deletes, etc.
#svn_node_unknown if unavailable.
*
* @since New in 1.9 */
svn_node_kind_t actual_kind;
]]]
I personally don't see a real reason to not have it so
if nobody objects I'd just add it there.
One of Subversion's core design principles is that
working copy info should be abstracted from client
operations. There was even an effort to remove
"everything" from the svn_wc.h header, but we can't do
that because of compatibility guarantees.
Exactly, let's not force them and give everything one could
ask for from the client API directly.
Of course, over time we've added all sorts of loopholes
to get at WC data anyway – the "WC compatibility
version" being the latest example. Still, even so we're
keeping this in the svn_client API. Though I do have my
doubts about exposing the WC format version in this way,
I don't see why it's necessary.
I didn't say it's anywhere closely valid - it's a
horribly wrong workaround that just exists and I wanted to
mention it.
There is also an idea that I think we might consider to
include last modified time (actual_mtime) into the
status structure of both WC and client. We already have
this information as an svn_io_dirent2_t when the status
is assembled in libsvn_wc/status.c so it doesn't cost
us anything to do and could potentially give users more
idea about a node.
Why do you need mtime etc. in the client status in the
first place? Clients can't use it to guess whether a
file was modified, we have more complex underlying
mechanisms for that. So let's start by discussing what
you want to achieve before you modify the public API.
Clients may want to display extra info about status items
and this is one of them that we can make cheap to retrieve.
I don't think there is that much it could possibly break
to add a field with stuff we already have.
We do tend to be more concerned about commit times than
on-disk times, though we do have the meta-data-versioning
branches that haven't been touched in ages. I would guess
clients are more interested in whether a file is modified,
not its exact modification time. I can't recall, do we have
an example of this, a request from users, or similar? Or a
concrete use case? 'svn status', 'svn info', 'svn ls' etc.
have always, correctly IMO, been concerned about version
control aspects.
Nothing really concrete yet, but I'm sure it would make API
consumers happy.
For the record: we already have filesize in both (WC and client)
structures.
Yes, I know. Thought it's sometimes the on-disk size and
sometimes the in-repository size, depending on which structure
(info or status) you look at.
I'd like to also throw it here onlist for discussion but perhaps
it would be great to show if a file is a directory in 'svn st'
(and probably other similar commands) by adding a slash to the
end of a name.
You're conflating 'svn status', 'svn info' and 'svn ls'. 'svn
status' is about the modification status of a node; not its local
size or modification time. 'svn info' does show the node kind.
'svn ls -v' appends that '/' to directory names. You're also
mixing API and command output.
Even if we add modification time to the client API, it should be
in 'ls' and /maybe/ 'info', not in 'status'. Please keep in mind
that Subversion isn't a general-purpose shell and we have to be
careful not to mix information relevant to version control with
information that users and clients naturally get elsewhere.
Specifically, we shouldn't confuse users or API consumers into
thinking that the local modification time is recorded in the
repository.
I think it's a common thing to do (although I just found that GNU
'ls' doesn't do that).
'ls -F' does, and also appends a '*' to executable files. It's an
often used option, but not the default. Just as 'ls' doesn't show
names that start with a dot by default. A bit like the difference
between 'svn ls' and 'svn ls -v'. What you see in your Linux VM or
WSL when you type 'ls' in the terminal is usually not what you'd
see if you typed '/bin/ls'.
It instead colours them differently. Which I believe would be
also a nice thing if we do it in Subversion but is a completely
different topic that I really wish we considered at some point.
GNU ls does not use colours by default. You have to add
'--color=auto' or '--color=yes' to get that. Those options are
often added to bash aliases, but they're not the default by any means.
I did not mix anything up. I think API and command-line changes could
be completely unrelated to one another.
