Hi, I love the idea!
Den mån 30 mars 2026 kl 22:00 skrev Timofei Zhakov <[email protected]>: > 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). > The default web interface is completely crap. ViewVC is quite good but very limited activity there. On dayjob we use VisualSVN Server which is superb. > 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). > It is no secret that I'm also involved in TSVN. I tend to mix between the VisualSVN web interface and Repository Browser, but I see most colleagues use VisualSVN. > > 4. Borrow the right command with the exact path from another resource (like > when first time checking out a new project). > This is what I usually do, copying the path from 2 or 3. > > 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 think that is a great goal! > > 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. > Very neat! > > 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. > I would prefer not loading the whole tree at once, but rather on-demand. Try loading ASF's main repo recursively.. I think TSVN RepoBrowser loads only as much as it really needs and then on-demand loads everything else. > > 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. > If I understand this point correctly you suggest that we should find the remote URL from the current WC (unless given om the cmdline). I think that is a good thing. > > 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). > I think TSVN always defaults to HEAD even for operations where the command line clients would default to the current WC revision (like svn log). I think that makes most sense, potentially with a knob to switch to the WC revision. > > 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. > Separate program, much like svnmucc. > > 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. > Sounds like to good idea to get off the ground. > > 7. Do we use ncurses (library that the majority of TUI apps use) or figure > out > something else? > I would suggest to use something that makes it easy to implement. Portability isn't a major concern here - I assume ncurses is available on all modern Unix-like systems (Linux, MacOs, BSDs etc.). There even seems to be a Windows-build. > 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 >-< > I'm +100 for this idea, however I won't add much help myself. My time is severely limited and my current priorities are the 1.15 release and the proxy-fixes that has been sent to the list. Sorry to not be of more help here. Kind regards, Daniel
