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

Tijl Coosemans tijl at FreeBSD.org
Sat Jun 22 18:38:34 UTC 2013


On 2013-06-20 21:34, Warner Losh wrote:
> 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...

For what it's worth, my reservations have always been because it didn't
feel right. I never asked for an approval process.

I do think there should be a tool in base that can fetch source updates
and it would be nice if it could roll back changes and even nicer if it
could do bisects. But svn itself is not the right tool for that.

For instance, will you allow that svn is updated from version x.y to
x.(y+1) in a stable branch? If yes, then users might have to run
"svn upgrade" which is a one way process, so how does importing svn
allow you to roll back changes or do bisects then? If no, then who's
volunteering to backport security fixes?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/svn-src-all/attachments/20130622/6936f5f7/attachment.sig>


More information about the svn-src-all mailing list