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. This is information that clients may want to display just. How could you justify filesize but not mtime in 'svn status'? To me, they sound almost the same - both describe information about the underlying file. Information that the status implementation already has and could easily expose from the API so they won't have to do extra work to retrieve those. Or actual_kind in libsvn_wc but not in libsvn_client - the same thing. Okay, if apparently 'svn status' is not just filtered 'ls' why do you think it'd be such a horrible idea to add a '/' to the directories? Can we at least discuss it maybe - not just throw it away just because "it's a different thing"? I don't know what "Subversion design principles" you're talking about that don't let us make our lives easier and programs faster... -- Timofei Zhakov
