On Mon, Jun 15, 2026 at 6:46 PM Nathan Hartman <[email protected]> wrote: > > 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. >
True. It does not. Please keep in mind that the API and the cmdline are two separate products. The fact that sometimes they sometimes do the same thing is a coincidence. Yes, we need API for certain features in the cmdline but it's not an argument to not implement something in libsvn if it didn't find its use in the cmdline. > > > > 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. It is but a single stupid field that might probably be useful doesn't hurt stability in any way. > > > 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 -- Timofei Zhakov
