On Mon, Mar 30, 2026 at 10:49 PM Daniel Sahlberg <[email protected]> wrote: > > Hi, > > I love the idea!
Thanks so much for responding! > Den mån 30 mars 2026 kl 22:00 skrev Timofei Zhakov <[email protected]>: >> >> 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). > > > The default web interface is completely crap. > ViewVC is quite good but very limited activity there. > On dayjob we use VisualSVN Server which is superb. > >> >> 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). > > > It is no secret that I'm also involved in TSVN. I tend to mix between the > VisualSVN web interface and Repository Browser, but I see most colleagues use > VisualSVN. > >> >> >> 4. Borrow the right command with the exact path from another resource (like >> when first time checking out a new project). > > > This is what I usually do, copying the path from 2 or 3. > >> >> >> 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 think that is a great goal! > >> >> >> 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. > > > Very neat! > >> >> >> 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. > > > I would prefer not loading the whole tree at once, but rather on-demand. Try > loading ASF's main repo recursively.. > I think TSVN RepoBrowser loads only as much as it really needs and then > on-demand loads everything else. That's true. It could be the fastest way to reach the rate limits of all ASF, the network provider, and run out of swap space at the same time. But it works for either smaller trees or by limiting the amount of items to load. I really want to get fuzzy-searching in some way... >> >> >> 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. > > > If I understand this point correctly you suggest that we should find the > remote URL from the current WC (unless given om the cmdline). I think that is > a good thing. Yes, that's exactly what I meant. >> >> >> 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). > > > I think TSVN always defaults to HEAD even for operations where the command > line clients would default to the current WC revision (like svn log). I think > that makes most sense, potentially with a knob to switch to the WC revision. Probably matching style of rest of svnfamily commands would make sense then. >> >> >> 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. > > > Separate program, much like svnmucc. > >> >> >> 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. > > > Sounds like to good idea to get off the ground. > >> >> >> 7. Do we use ncurses (library that the majority of TUI apps use) or figure >> out >> something else? > > > I would suggest to use something that makes it easy to implement. Portability > isn't a major concern here - I assume ncurses is available on all modern > Unix-like systems (Linux, MacOs, BSDs etc.). There even seems to be a > Windows-build. According to my understanding ncurses actually helps portability because it knows the best of how one should deal with weird terminals. It seems that it's really annoying to build it on Windows, but there is a vcpkg port that does the job. On Unix-based systems it's almost guaranteed that it is pre-installed as a dependency of pretty much any interactive application (including some from something like util-linux). >> >> 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 >-< > > > I'm +100 for this idea, however I won't add much help myself. My time is > severely limited and my current priorities are the 1.15 release and the > proxy-fixes that has been sent to the list. Sorry to not be of more help here. I think "+100 let me add a few ideas and share my personal experience" is the kind of help that is needed. Thank you so much for sharing! -- Timofei Zhakov
