On Mon, Jun 15, 2026 at 11:47 AM Branko Čibej <[email protected]> wrote: > > On 15. 6. 2026 16:55, Timofei Zhakov wrote: > > 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. > > > Sure, but you brought up command-line output changes in the context of > discussing API changes. > > > This is information that clients may want to display just. How could you > justify filesize but not mtime in 'svn status'?
Did you mean 'svn ls' (rather than 'svn status')? (I'm not aware of 'svn status' showing filesize; it only shows the current and Last Changed Rev.) AFAICT 'svn ls -v' does show mtime -- that is, the "Last Changed Date" also shown in 'svn info'. I didn't look at how it gets this information. > I'm not trying to justify anything. I'm considering the consequences of > changing the UI/API. We've made silly mistakes in the past in that respect, > I've certainly made my share of them. I don't think we should keep making > them as a sort of, I don't know, learning experience?... > > > 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. > > > "Easily expose" and "should expose" are not the same thing. You seem to be > missing my point entirely. > > > 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"? (Of course, the quoting is all messed up so it's not obvious who wrote what, argh!!!) Just adding my opinion here: I don't think it's a horrible idea, but I do think we have different commands for different use cases. In my mind, 'svn status' (with or without --verbose) is for checking what changed in my working copy and/or on the server (with --show-updates); 'svn info' is for getting the kind of detailed info about a particular item (which outputs whether a particular item is a file or directory in "Node Kind"); 'svn ls' is a command I only use to browse a remote server when I need to find the correct URL for something -- I hope 'svnbrowse' will replace 'svn ls' for that use case!! Generally I like to err on the side of not changing things unless there's a really good reason. One thing that annoys me about much commercial software (and some open source software) is when they change things for the sake of change. I call it "It worked great. So we reinvented it. Again." I think stability is a good thing. Now, if there's an actual problem it would solve, like eliminating a whole lot of contorted logic in applications, that would be a good reason to consider it. It sounds like 'svn info' provides most of what you want, except the file size. Now wait a minute, that's funny. 'svn info' takes a '-H' (--human-readable) switch. But it doesn't show file sizes. Am I confused? > How many automation scripts for how many users that we know nothing about do > you propose to break because you feel that changing the output of an 'svn' > command would be a good idea? (Ignore --xml because even though we know it's > what people should use when automating the command line, we also know that > they don't.) Probably because XML is hard. And I'm sure it didn't help that we had some bugs that produced invalid XML. :-/ > Why do you think we have separate info, status and list commands if "it's all > the same thing"? > > Those are the sort of questions you need to answer before proposing such a > change to the API or UI. Note that backwards compatibility rules apply to the > UI, too. > > > I don't know what "Subversion design principles" you're talking about that > don't let us make our lives easier and programs faster... I was just thinking about this the other day. There's a lot of tacit knowledge about why things are the way they are, that isn't necessarily documented (unless you consider spelunking through the history and mailing list archives). I don't know if we'll ever be able to get it documented. At least we do have the list archives going back to the beginning (before Subversion became Apache Subversion). > The ones we've been tying to follow, not always with perfect success, for the > last 25 years? > > Exposing something in the public API just because someone feels it would be > convenient might not be the best idea, I hope you agree. We've had our share > of exposing too much already. I prefer to be conservative with changes to our > public interfaces, whether it's the API or the UI. I wasn't always that way > but I hope I've learned my lesson. > > > -- Brane > Idea: Instead of changing an existing API, a completely new API could be added that provides all of the information about an item that you could possibly get from 'svn status', 'svn info', and 'svn ls'. If this is in support of 'svnbrowse' and other file manager-style applications, I can see where it might be useful to have a one-stop-shop API for getting anything and everything a user might want to know. But I'd caution to design it very, very carefully, since that would become another API that needs to be maintained forever... Cheers, Nathan
