Fallout from the CVS discussion

[Garrett Cooper]

On Sep 16, 2012, at 1:07 PM, Eitan Adler wrote:

> On 16 September 2012 15:53, Adrian Chadd <adrian at freebsd.org> wrote:
> 
>> * I'd like to first see a roadmap for doing this - eg, "we're adding a
>> NO_CVS option; CVS will become a port, you can migrate to the CVS port
>> with your next build/installworld";
> 
> We have WITHOUT_CVS .
> 
>> * if you're that way inclined, backport the NO_CVS option (if it
>> doesn't exist) to -9;
> 
> Already done.
> 
>> * Ensure all of the stuff that uses CVS is migrated beforehand, and
>> publish all of that effort somewhere;
> 
> This is part of my plan.
> 
>> * Make sure you're doing it for reasons that aren't coming across as
>> "GPL free! at all costs!"
> 
> This has nothing to do with the reasons I proposed to remove CVS.
> Please re-read my original email. The first words were "CVS is
> obsolete."
> I had *no idea* CVS was GPLed until the thread started (I thought were
> using a BSD licensed one).
> 
>> Now, to stir up trouble, I hereby suggest that if you're going to
>> remove CVS because it's no longer used for FreeBSD's project stuff, we
>> should obviously import subversion into the base because _it_ is being
>> used for the FreeBSD project stuff.
> 
> Please re-read the original thread. I am removing CVS because it is
> obsolete. CVS being used for FreeBSD project was merely a key blocker
> to its removal.
> 
>> Think of why you're not doing that
>> (likely because it's already a port/package and there's just as much
>> inertia to introduce something to the base system as there is removing
>> it and making it a port) and see if that helps refocus your reasons
>> for and against doing things.
> 
> I am not proposing introducing subversion into base because I am not
> willing to do the work to maintain it. If I were, that would be a
> different story (imho, the base should have sufficient software to
> download and compile itself).

1. Subversion changes too much to be in base (its release cycle is shorter than bind).
2. Subversion sometimes breaks between major/minor versions (1.6->1.7 comes to mind) and is not backwards compatible in many cases (again, 1.6 -> 1.7 transition).
3. It requires apr (which optionally requires gdbm), BDB 4.x (which is GPLv2/GPLv3), sqlite3 (which pulls in tcl because of the distfile the sqlite3 maintainer chooses to use), neon or serf, etc (point is the dependency list is not short and thus maintainer overhead is considerably higher).

Please leave it in packages/ports. With pkg_install/pkgng, installing subversion from a package is trivial and that should be the route taken for developers, as opposed to having a copy in base.

Thanks,
-Garrett