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