On Tue, Mar 31, 2026 at 7:12 PM Daniel Sahlberg <[email protected]> wrote:
> Den tis 31 mars 2026 kl 18:03 skrev Timofei Zhakov <[email protected]>: > >> On Tue, Mar 31, 2026 at 5:47 PM Branko Čibej <[email protected]> wrote: >> > >> > On 31. 3. 26 17:44, Timofei Zhakov wrote: >> > >> > On Tue, Mar 31, 2026 at 5:40 PM Branko Čibej <[email protected]> wrote: >> > >> > On 30. 3. 26 21:59, Timofei Zhakov wrote: >> > >> > Hello all, >> > >> > The problem I would like to address is that actions like picking the >> right >> > branch in a repository are sometimes annoying with the current UI of the >> > command-line. Although all operations are really well-designed, the >> user still >> > needs to manually input the whole URL of a branch/or use the relative >> path >> > syntax. >> > >> > There is not enough user feedback. When interacting with a repository >> through >> > the CLI it feels like some abstract thing that exists somewhere on the >> remote >> > target - not a file-system tree. The current way we usually do that is >> one of >> > the following: >> > >> > 1. Imagine what we have on the server in our minds. It's often not that >> big of >> > a deal to type 30 characters when switching/merging stuff. >> > >> > 2. Use the web interface (if any). >> > >> > 3. Use third-party tools like TortoiseSVN Repository Browser (and the >> whole >> > ecosystem including branch picker in switch/merge which I believe is >> almost >> > the same thing). >> > >> > 4. Borrow the right command with the exact path from another resource >> (like >> > when first time checking out a new project). >> > >> > The 2 and 3 are not always possible as the standard web interface is >> very >> > limited in terms of functionality and not always do we have the >> pleasure to use >> > the GUI apps. >> > >> > What I believe we need to improve overall workflow with Subversion is a >> way to >> > browse repositories (without checking it out) directly in a terminal. >> Luckily >> > because of the way accessing remote targets is designed in Subversion, >> it's >> > possible to retrieve information of any arbitrary node without a need >> to fetch >> > it entirely. >> > >> > I would like to propose introducing a tool for browsing remote >> repositories >> > (svnbrowse). It will be a TUI (terminal user interface) like-ish >> application >> > where a user could navigate the repository like in a web browser. >> > >> > I have tried to implement it. A patch is attached below. I generally >> liked the >> > user experience it brings. >> > >> > There are also a few issues we might face when implementing this >> feature; >> > >> > 1. It currently loads items pretty slowly; Initially I used the >> svn_client API. >> > However, it creates a new ra_session per each call. I believe it >> would >> > be better to switch to using svn_ra directly. >> > >> > 2. We might load the tree recursively for faster navigation between >> > directories. This would also allow fuzzy searching. But it makes the >> > operation unbounded. >> > >> > 3. Should it work over a working copy or it's a web browser >> replacement? Using >> > URL from a working copy makes it much more convenient to use as a >> user only >> > needs to type 'svnbrowse' to get into it. >> > >> > 4. The revision issue; What revision do we use? If implementing it like >> in the >> > rest of the commands (with --revision that defaults to HEAD), how >> often >> > should we resolve it? The RA API (and the protocol) also allows >> fetching the >> > contents of the HEAD directory (using svn_ra_get_dir2 with >> > SVN_INVALID_REVNUM revision). However, there is no way to get the >> revnum >> > back (without making an extra request). >> > >> > 5. Should it be a separate program or something like an option in >> > 'svn list --please-let-me-browse-it'. I personally think that it >> should not >> > be in 'svn' command. By conceptual conventions of 'svn' there are >> minimal >> > interactions and it can be used for scripting as well. I believe it >> would be >> > much better to separate it into a different program. >> > >> > 6. I suggest limiting the scope to directory browsing as it's the >> simplest to >> > implement but it improves the experience by a lot. Later on, adding >> file >> > content browsing and log would be natural. Also it may act as an >> > alternative to svnmucc if a commit operation was implemented. >> > >> > 7. Do we use ncurses (library that the majority of TUI apps use) or >> figure out >> > something else? >> > >> > This list is not complete and I may have missed something; To conclude, >> there >> > are plenty of things to be done and many problems with on obvious >> solution. >> > Better we try something out and get some feedback and vision of what is >> to be >> > improved. The prototype represents the general wireframe of what it >> should >> > like. I made it in like an hour to get an overall impression. >> > >> > Please feel free to express your opinion about this idea. Dear svndev, >> it's >> > time to discuss some UI things >-< >> > >> > >> > So, if I'm reading this correctly, you're basically proposing a nicer >> interface for svnmucc? Or just the read-only part of it? >> > >> > I'm suggesting to start with a read-only browser with an opportunity >> > to implement a nicer interface for svnmucc in future. >> > >> > But I think the primary focus of the minimal-working prototype is the >> > read-only part. >> > >> > >> > Ack. Sounds nice. In return, I propose not doing this in C but in >> Python, preferably 3.10+. We have the bindings, and this is what Python is >> really good at if used correctly. >> >> I personally think that using anything besides C could potentially be >> bad for cross-platformability (is this a word?). It's not guaranteed >> that the platform that we are being run on has a Python interpreter >> which is especially common on Windows. >> > > Cross-platformability works for me! > > I can't remember if I added Python manually on my main computer but at > least it wasn't a big effort (possibly it is a Windows Store app). I don't > think Python would be a major blocker for any reasonably modern Windows > machine. > > I think we should ask ourselves "how do people usually install svn tools?". I think the most common way it's done on Windows is by checking the relevant option in TortoiseSVN installer. Is it really gonna include a Python interpreter into distribution? I assume it's generally a bad idea. If it doesn't, then the tools in Python would not work out of the box. It also requires something like an extra batch file to enable invocations by typing a direct command (like svnbrowse[.exe|bat]) in a terminal. I don't think it's worth it. > >> The rest of the command-line tools don't use Python so why should >> svnbrowse. >> > > I don't think this is a good argument. If a certain solution makes more > sense for a particular tool, we should go that way. > > >> >> Generally, with a good framework, it's not so hard to make such >> applications in C. >> > > Wasn't the a joke about 10 types of people, those who like C and those who > don't? Or maybe that was about something else? > > That said - I firmly believe that if this is a scratch for you to itch, > you should select the tool that makes the most sense to you. If you think C > makes the most sense - go for it! > > That's a good point, thanks! And not for me only, but for the rest of us that care also. -- Timofei Zhakov
