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...

Warner Losh imp at bsdimp.com
Thu Jun 20 19:34:42 UTC 2013


On Jun 20, 2013, at 2:40 AM, David Chisnall wrote:

> On 20 Jun 2013, at 00:10, Warner Losh <imp at bsdimp.com> wrote:
> 
>>> - FreeBSD developers, who are probably okay with installing a port, but would prefer a version that didn't depend on kitchen/sink?
>>> 
>>> - Users, who wish to be able to update the source tree and then either build world, or build some optional parts that are not part of the default install?
>>> 
>>> - Some other category of svn consumer?
>>> 
>>> I think having a definitive statement as to the intention of svnlite would help frame the discussion in a more productive format.
>> 
>> How do I roll back to last week with FreeBSD-update?
> 
> Which of the classes of user that I outlined do you think wants to be able to do that?  As a FreeBSD user, I never felt the desire to do that, but maybe I was unusual.  As a FreeBSD developer, I don't mind installing the svn port to be able to do it (although I'd prefer a more lightweight port).  I would expect the same to apply to the sort of engaged user who is willing to bisect to track down a bug.  

People trying new versions of FreeBSD. Some of them install the release, others might install a snapshot, some will do an install world. But if it worked in release 9.3 and broke in 9.4, then to find where they would need to install an svn port to get all the points in between.

Not having to install a port, possibly a port that got messed up by the world you just build, is a big win for me in my mind. Users often have commented to me that running FreeBSD gets harder and harder with more hoops to jump through to do things that used to be easy. Installing svn is one more hoop. It, by itself isn't a huge hoop, but if we can avoid that hoop we should.

I do mind installing a port to do this. We've kicked too much out of the tree in the name of anti-bloat, and frankly I'm glad to see this.

I think insisting on a definitive statement on svn lite's mission statement is a way to obstruct progress. Sometimes you just need to things because they feel right, not because they have been through a 20-step approval process...

Warner



More information about the svn-src-head mailing list