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