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. -- Timofei Zhakov
