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. -- Timofei Zhakov
