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

[John Baldwin]

On Thursday, June 20, 2013 9:13:51 am David Chisnall wrote:
> On 20 Jun 2013, at 14:09, Julian Elischer <julian at freebsd.org> wrote:
> 
> >> 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.
> > bug reporter:   I have this new bug...
> > developer:    Can you try rolling back to xyzzy
> > bug reporter:  Yeah that fixes it..
> > developer:   Ok.. patch will follow....
> 
> 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 only mean that this use-case is required and this is why you can't use
portsnap for src updates.  Especially because when some user does an update
they aren't going to want to switch to some other tool so they can start
bisecting to find an offending revision. Many of our users are willing to do 
the bisection thing, and it was a commonly used feature of cvsup to do this 
via timestamps.

In terms of whether or not the src updating tool live in ports:

cvsup used to only be available as a port, and many users really did like 
having csup come into the base system so they did not need a port for this.   
The rather broad support for svnup among our users on stable@, etc. should be 
a good clue that many of them would greatly prefer a tool in the base system 
for tracking source rather than installing a port, esp. a port with the large 
number of dependencies that svn has.

-- 
John Baldwin