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. 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. I think it's a common thing to do (although I just found that GNU 'ls' doesn't do that). 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. -- Timofei Zhakov
