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]

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.

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.

-------------- 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/20130623/930e81d2/attachment.sig>