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.
-- Brane
