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. > > 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! Kind regards, Daniel
