On 1. 4. 26 00:48, Timofei Zhakov wrote:
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]>
<mailto:[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]>
<mailto:[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.
You're just telling me that you haven't really done this before. This is
on a Debian 12 minimal install:
$ dpkg -l | grep python3 | fgrep -v arm64 | wc -l
29
I'd say distros have Python packages figured out. Python has a mature,
cross-platform packaging system. Creating packages, either as part of a
distro or installing them from PyPI, is trivial. I'd say it's easier
than dealing with the 50 zillion different build systems for C.
In other words, this is not a problem for distributors and specifically
not a problem for us, other than we'd have to create the proper Python
package structure -- which is a given anyway.
I think we're a bit too concerned with supporting a reality that was
true 25 years ago when this project had barely started, but is not quite
as true today.
-- Brane
