svn commit: r251886 - in head: contrib/apr contrib/apr-util contrib/serf contrib/sqlite3 contrib/subversion share/mk usr.bin usr.bin/svn usr.bin/svn/lib usr.bin/svn/lib/libapr usr.bin/svn/lib/libap...

[Daniel O'Connor]

On 20/06/2013, at 23:03, Julian Elischer <julian at freebsd.org> wrote:
>> And do you think that the sort of user who is sufficiently engaged with the project to do this is the sort of user who would not be willing to do so if it meant installing the subversion port?  If so, then there is a clear case for svnlite.
> 
> I think that it lowers the barrier.. once you start bringing ports into the picture you start running the risk of port revision hell.


If there is a statically linked port & corresponding package then the barrier is almost as low, but has a few other advantages that other people have listed.

That approach has a small footprint (binary + man page), is always up to date (so the VCS infrastructure is not tied to the earliest version of SVN) and doesn't have any dependencies.

--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C