On Wed, Apr 22, 2026 at 5:59 AM Nathan Hartman <[email protected]> wrote:
> On Mon, Apr 20, 2026 at 12:41 PM Timofei Zhakov <[email protected]> wrote: > >> Hello all, >> >> Thanks to everyone following svnbrowse. >> >> I believe this project has come to a state of a decently stable >> milestone. It >> is capable for general browsing around in a tree and overall interactivity >> feels good. >> >> However, there are a few things which need some further attention. >> >> 1. Opening a file would crash the entire application; I don't know what >> the >> best way to display them would be. >> >> 2. Handling of --revision and @pegrevision doesn't handle certain cases >> correctly. The condition that checks and fallbacks to HEAD via >> SVN_INVALID_REVNUM (passed to svn_ra_get_dir) misbehaves in certain >> cases (for >> example, 'svnbrowse ./path/in/wc -r head' does not work). >> >> 3. When launched from a colourless terminal (or with a limited colour >> support), >> the UI elements are displayed wrongly. This will occur primarily in >> legacy >> terminals. >> >> 4. No cancellation is yet implemented. Would be more like a fancy >> improvement >> and it doesn't really affect any user experience. >> >> 5. There is a funny segfault (to null dereference) when a node with no >> author >> is opened. >> >> 6. Implement non-pkgconfig search of a curses library (via find_package). >> >> 7. Include in autoconf/configure build. >> >> 8. Print path to stdout when exiting [2]. >> >> I would really appreciate help with 1 (I'm out of ideas about the user >> experience to deal with files), 2 (I have tried to find the correct way >> to go >> with. Somebody more experienced than me should step ahead here), and 7 >> (zero clue how autoconf works). The rest would be pretty obvious to >> tackle. >> >> Of course if you can run a dev build, I'm happy to hear some feedback. >> >> Also I start thinking about what the target use could be (besides >> wandering around in >> directories which is not that useful on its own). I believe it might >> sometimes >> come in handy for scripts to ask a user to pick a path. >> >> For example, we might target on doing something like this: >> >> [[[ >> $ svn checkout $(svnbrowse https://svn.apache.org/repos/asf) >> >> # the user picks a path and quits the app (enter does not work because it >> the >> # opens selected directory) >> # it is printed to stdout >> # $() puts it into an argument [1] and executes svn as usual >> ]]] >> >> As another application we currently have to type full branch URL when >> switching/merging (or use ^/ syntax which is still pretty much the same >> thing >> because one must remember its location in a repository). It could be >> either >> 'svn merge' and 'svn switch' themselves launch the browser (most >> likely they would >> do that in the same process) or it could be a simple shell alias. >> >> Not really another application, but a different way to describe that >> chunk of >> script from above. >> >> But... This on the other hand might be a bad idea; A tool starts doing >> multiple >> things at the same time. Instead of first deciding on the operation's >> scope and >> then executing the actions, it would do both at the same time. If let's >> say >> during a checkout, a user picks location and expects it to work, but then >> they >> realise that suddenly the internet connection just died so checkout >> failed (or >> name any other reason), all the effort required to pick that location >> will be >> lost. When it's a manually typed shell command, one might simply go back >> and retry/edit wrong part. >> >> [1] I did not test it but I'm pretty sure this is how shell works; it >> should >> be the thing as let's say /bin/basename. >> >> [2] it's a bit tricky to use stdout as right now this is the channel used >> for >> the interactive UI. There should be a some way to force curses to use >> stderr instead which solves the issues. >> >> -- >> Timofei Zhakov >> > > I think these items should be tracked (each one separately) in the issue > tracker. (If you'd like, I'm willing to add them there.) > > +1, it's a good point. It would help us keep things organised. If you'd like to do it, go ahead! -- Timofei Zhakov
