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]

On Jun 23, 2013, at 6:22 AM, Tijl Coosemans wrote:

> On 2013-06-23 04:43, Garance A Drosehn wrote:
>> On 6/22/13 2:38 PM, Tijl Coosemans wrote:
>>> On 2013-06-20 21:34, Warner Losh wrote:
>>>> 
>>>> 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
>>> 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?
>> 
>> What was added to the base system was 'svnlite', not 'svn' from
>> the official subversion project.  The distinction is that
>> 'svnlite' is a version meant only for access to the official
>> FreeBSD repositories.  'svnlite' in the base system would only
>> be upgraded when it is needed to match the FreeBSD respository.
>> And if you need to run 'svn upgrade' to access the FreeBSD
>> repository, then it doesn't make much difference if you have
>> to do that with 'svnlite' or via the official 'svn' port.
>> 
>> I'm not sure that my comments provide an answer to what you're
>> concerned about, but anyone who wants the latest version of
>> 'svn' to match their own repositories is still going to need
>> to install the port.  We're not going to blindly update
>> 'svnlite' every time a new version of 'svn' is released.
>> 'svnlite' is going to be updated on *FreeBSD*'s schedule,
>> not on the schedule of the subversion project.
>> 
>> It is true that we're going to have to be careful when it does
>> come time to switch to some new repo-format for the FreeBSD
>> repository.  We might find ourselves in some kind of chicken-
>> and-egg situation at that point.  And when we do make a
>> significant upgrade to the FreeBSD repository, then we're
>> going to have to upgrade 'svnlite' across multiple FreeBSD
>> branches at the same time, including all -stable branches.
>> But when that issue comes up it'll come up on our schedule,
>> because we'll control both 'svnlite' and the FreeBSD repo.
> 
> It is precisely the other way around. Once you do a FreeBSD release
> (releng branch) that release will be stuck with the same version of
> svnlite for years. You will end up with multiple releases with
> multiple versions of svnlite that you cannot change. You have zero
> control.

Then they will never have to do svn update, since their checked out tree will never be obsolete in relationship to the version that's installed.

> A port on the other hand is the same for all branches and releases
> of FreeBSD. It is a single point where you have total control over
> the version of svn for all users. Conceptually, a port corresponds
> to the fact all branches and releases share the same subversion
> repo.

Except that you still need to do svn update on trees that are checked out from old repos.

I'm having a real hard time seeing this as an issue based on my experience with the svn port since we made the switch. Then again, I've been talking to the svn repo over http, which is independent of the version of the repo on the other end...

Warner