<snip> > 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. > > Exactly!
> 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. > With CMake it's not even a mandatory build-time dependency anymore if a tar-ball distribution is used. > But here's probably a more compelling reason to use C: Though 'svn' (the > main CLI binary) mostly isn't interactive, it does have a few interactive > features that prompt for user input, especially in the conflict resolver; > it runs only if we're in an interactive terminal. This interface is > functional but rather clunky. If we have a simple but comfortable TUI for > svnbrowse, it might not be such a big leap to adapt it for these and > possibly other interactive areas... just food for thought. > That's an interesting point. I also agree that there are certain things that might be improved. > > I suggest to create a branch to hack on svnbrowse so it doesn't only exist > as an emailed patch. It will also allow others who are inclined to hack on > it as well. I probably won't be able to be much help on this in the > immediate future but I'll try to be helpful in whatever way I can... > I honestly wanted to wait a while when the 72 hours period goes by so we have some feedback and hack it directly in the trunk. > > Thanks for suggesting this! > > [1] > https://subversion.apache.org/docs/release-notes/1.14.html#pythonoptional > > Cheers, > Nathan > > -- Timofei Zhakov
