When installing devel/arcanist on a machine that only has svnlite, the "arc" command-line tool does not work because it assumes that svn (with that name) is available in the path. If svnlite is sufficient for arcanist to work (which is what I'm not sure about) and is provided by the base system, then we should just explicitly use this binary in the tool and forget about svn proper. If patching the sources is too complicated or undesired, we could make the devel/arcanist package create a symlink under lib/php/arcanist/svn that points to the svn version to use, and then patch the "arc" tool to override the PATH at startup to point first to that location. This way, the code changes would be minimal.
Even if it works with svnlite, it might break in the future, so I don't think that patching it is such a great idea. What about adding a local symlink for your user, that's what I usually do in these situations (like in mkdir ~/bin; ln -s /usr/bin/svnlite ~/bin)?
No because, as a user, I should not be doing that. The default base system only includes svnlite, not svn. If I install arcanist with its default options, it should just work. That either means it has to support svnlite or it has to grow a dependency on the full-blown svn. Telling the user to "just set up a symlink" is broken.
Arcanist doesn't depend on subversion, it works equally well, if not better, with git. As a matter of fact, I use it 90% of the time with git. @work I'm the only one using subversion (because of contributing to FreeBSD), everyone else uses arcanist with git exclusively. Yet I wouldn't force everyone installing arcanist to also install git, so I don't want to see this with subversion either. To me, the workflow pkg install arcanist pkg install subversion AND/OR pkg install git is totally acceptable to a developer. That said, I would like to see arcanist work with svnlite. For my purposes svnlite was (almost?) always good enough to deal with the freebsd repos and installing subversion is pretty annoying. I don't have the time to proof that it's good enough to be used with arcanist though - especially since I would have to do that on every update of arcanist. So - either someone else has that capacity (and might as well take over the three ports this affects - phabricator/libphutil/arcanist) - OR we find a different solution, like e.g. a port called develet/svnissvnlite that conflicts with subversion and all it does is providing a symlink to svnlite. IMHO that could be useful outside of arcanist (right now I tend to use the workaround I described above to provide svn => svnlite to tools). I still wouldn't make arcanist depend on this port though, as - like I said above - not every user of arcanist wants/needs subversion. You could argue that FreeBSD uses arcanist for the project (which uses subversion right now), but I would respond that it's quite possible that the majority of users installing this port might never open a code review for FreeBSD at all. Then of course one could create a meta-port called "freebsd-arcanist" that installs both arcanist and subversion (or the symlink port suggested above) that could be used in tutorials to save the extra command to install subversion. Thoughts?
Oh interesting, those are very compelling arguments and you have convinced me. It didn't even cross my mind that Arcanist could work with other version control systems, and the choice of which one to use was on the user. Having a freebsd-arcanist meta-package would make sense, or even a more generic freebsd-developer + freebsd-packager that included other tools that might be interesting for FreeBSD src and ports development, respectively. I wish ports had a "Suggested packages" feature a la Debian, to easily highlight that other stuff should be installed. As an easy compromise, what do you think about adding a pkg-message to remind the user that installing a version control system is on his own? By the way, your idea of devel/svnissvnlite also sounds good -- as a complement to the above.
Is this still relevant?
Time flies. If there is still interest in a svnliteissvn port, please someone comment and I'll consider it. Closing it for the time being. Thanks.