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.) Cheers, Nathan
