On Tue, Mar 31, 2026 at 9:14 PM Branko Čibej <[email protected]> wrote:
> On 31. 3. 26 19:49, Timofei Zhakov wrote: > > 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. > > > ... What? I think you're confusing Python with Perl. :D > > Either that, or you've never seen well-written Python code. Just to be > clear, there's almost none of that in the Subversion repository... > Could be, could be. This is probably a skill issue that I have but I couldn't understand the majority of Python solutions that have more than 100 lines of code. > It's also a real pain for the package distributions to deal with programs > in Python rather than compiled languages. > > > I don't know where you're getting this but it's just plain wrong to 9 > decimal points. > > It's just painful to deal with it. You're either forced to write the whole program in a single file or the install dir becomes messy due all those files. > > I should've waited a day, but I think we should write everything in Rust > instead :-)) > > > Nah. Use Erlang with Go bindings. See? I can think up horrible ideas, too. > :p > > That's a nice one ^-^ -- Timofei Zhakov
