On Tue, Mar 31, 2026 at 7:30 PM Branko Čibej <[email protected]> wrote:
> On 31. 3. 26 18:01, Timofei Zhakov wrote: > > On Tue, Mar 31, 2026 at 5:47 PM Branko Čibej <[email protected]> > <[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]> > <[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. > > > You're forgetting that you have to install a C runtime on Windows for > practically anything. :) > Yes, that's true, but you have to do that for *practically anything*. > > The rest of the command-line tools don't use Python so why should svnbrowse. > > Generally, with a good framework, it's not so hard to make such > applications in C. > > > Not really. Python gives you everything out of the box including curses, > and generally, to do the same thing in C as you in Python, you need at > least 10 times the number of lines of code. This is exactly the kind of > application that could benefit from our Python bindings. > > On top of which, writing an event-loop-based user interface in C is one of > those horrors you want to avoid at all costs. Been there. In Python, it's > just another day of the week. But, it's up to you. > I think we should use a tool that everybody is already familiar with. Since everything else in Subversion is written in C it's the simplest choice even if some specific thing is slightly more convenient with a different technology. - The developers know how to maintain C code. - The packagers are happy to bundle yet another program in their distributions with no need to deal with a new language. I personally don't know how Python works and would probably spend more time trying to understand it than writing a straightforward C code. Not even considering that Python is generally a write-only language so a program would get more complicated to maintain as more people contribute and time goes by. It's also a real pain for the package distributions to deal with programs in Python rather than compiled languages. I should've waited a day, but I think we should write everything in Rust instead :-)) -- Timofei Zhakov
