On Wed, Apr 1, 2026 at 1:12 AM Branko Čibej <[email protected]> wrote:
> On 1. 4. 26 00:53, Timofei Zhakov wrote: > > On Wed, Apr 1, 2026 at 12:48 AM Branko Čibej <[email protected]> wrote: > >> On 31. 3. 26 20:33, Nathan Hartman wrote: >> >> On Tue, Mar 31, 2026 at 2:02 PM Timofei Zhakov <[email protected]> wrote: >> >>> On Tue, Mar 31, 2026 at 7:12 PM Daniel Sahlberg < >>> [email protected]> wrote: >>> >>>> 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. >>>> >>>> >>> >>> I think we should ask ourselves "how do people usually install svn >>> tools?". I think the most common way it's done on Windows is by checking >>> the relevant option in TortoiseSVN installer. Is it really gonna include a >>> Python interpreter into distribution? I assume it's generally a bad idea. >>> >>> If it doesn't, then the tools in Python would not work out of the box. >>> >>> It also requires something like an extra batch file to enable >>> invocations by typing a direct command (like svnbrowse[.exe|bat]) in a >>> terminal. >>> >>> I don't think it's worth it. >>> >>> >>>> >>>>> 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! >>>> >>>> >>> That's a good point, thanks! And not for me only, but for the rest of us >>> that care also. >>> >>> >>> -- >>> Timofei Zhakov >>> >> >> >> I'm also +1 for a svnbrowse utility! >> >> I'm okay with it being implemented in C for reasons that were already >> spelled out: consistency with the other svn* binaries, less friction for >> developers, packagers, and end users, etc. >> >> The 1.14.x release notes explain [1] that Python isn't required for >> Subversion unless someone wants to build Subversion from sources, run the >> test suite, or use something that requires the SWIG Python bindings. >> Staying consistent with that as it affects our core tools is a good thing >> IMHO. >> >> >> >> I don't see this as a core tool. *shrug* >> >> >> > Why not? Could you please elaborate that? > > It's still a tool that people might want to use just like svn or svnadmin. > > > Our core tools are the ones you can't do without. That would be svnadmin, > svnserve/mod_dav_svn on the server side; and svn on the client side. We > have some others, like svnmucc and the language bindings, which are more of > an optional extra. A text UI browser falls into that category, too. > > The difference is exactly between the "must have" and "would want to use" > descriptions. > Yes, if you define it like that it's obviously not a "core tool". I would say that all programs including svnmucc, svnsync, and even svnversion and svnbench are in some way "core". Then svnbrowse would be one of these. > > Here's why I suggested to write this in Python: we're barely exercising > our Python bindings. We don't have tests for them. There are some example > hook scripts, and mailer.py, and that's it. Having a tool that can both be > useful for users and gives our Python bindings a real workout would be a > very nice addition. > > If we use a certain thing too little, on its own it's not a really strong reason to use it in a new subproject. > It's also a question of using the right tool for the job. C is not the > right tool for writing interactive/event-driven user interfaces. Not saying > it can't be done, but as someone who's had to do Win32 programming in raw > C, I sure don't recommend it. > > Yes we should use the right tool. Not because we don't exercise it enough, but because it fits the requirements. In this case I believe the use of C does in fact fit well enough. There should be a certain balance. Because on the other side we people use React.JS in their TUIs [1]. Problems in C is something you at least can easily debug and actually understand where the problem is. [1] https://deepwiki.com/chatgptprojects/claude-code/7-terminal-ui-(tui) -- Timofei Zhakov
