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.
