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

Nikolai Lifanov lifanov at mail.lifanov.com
Tue Jun 18 16:48:23 UTC 2013


On 06/18/13 12:40, Tijl Coosemans wrote:
> On 2013-06-18 04:53, Peter Wemm wrote:
>> Author: peter
>> Date: Tue Jun 18 02:53:45 2013
>> New Revision: 251886
>> URL: http://svnweb.freebsd.org/changeset/base/251886
>>
>> Log:
>>    Introduce svnlite so that we can check out our source code again.
>>
>>    This is actually a fully functional build except:
>>    * All internal shared libraries are static linked to make sure there
>>      is no interference with ports (and to reduce build time).
>>    * It does not have the python/perl/etc plugin or API support.
>>    * By default, it installs as "svnlite" rather than "svn".
>>    * If WITH_SVN added in make.conf, you get "svn".
>>    * If WITHOUT_SVNLITE is in make.conf, this is completely disabled.
>>
>>    To be absolutely clear, this is not intended for any use other than
>>    checking out freebsd source and committing, like we once did with cvs.
>>
>>    It should be usable for small scale local repositories that don't
>>    need the python/perl plugin architecture.
>
> This ties the repo to the oldest supported release, meaning that years
> from now we won't be able to use some new subversion feature because
> an old FreeBSD release doesn't support it.
>
> I don't find it unreasonable to ask developers to install the port.
> And for users it seems all they need is something like portsnap for base.
> Portsnap already distributes ports svn so it shouldn't be too hard to
> adapt it for base. And the extra layer it adds is very convenient. Apart
> from a bigger than usual update maybe, portsnap users never even noticed
> it was switched from cvs to svn at some point.
>

I think the scope of this is for developers, to enable viewing 
repository history, committing, etc.
Users are able to keep a bare (no metadata) tree up-to-date with net/svnup.

But wasn't the original cvs retirement plan to import net/svnup into 
base? What is the motivation behind the import of semi-full subversion?
It didn't replace former cvs functionality, since development didn't 
happen in cvs repositories for a while.

- Nikolai Lifanov



More information about the svn-src-head mailing list