Let's talk about subversion/svn

David Demelier demelier.david at gmail.com
Sun Dec 16 15:52:25 UTC 2012

On 19/11/2012 08:16, Jeremy Chadwick wrote:
> Given the incessant focus on everything using Subversion now (please do
> not get me started, it will be like arguing with a brick wall), I'd like
> to know what the plan is for minimising the number of dependencies.
> The present subversion **package** on the official FTP servers is for
> subversion-1.7.6:
> root at icarus:~ # ftp ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-stable/Latest/
> ...
> ftp> dir subversion*.tbz
> 229 Entering Extended Passive Mode (|||10279|).
> 150 Here comes the directory listing.
> lrwxr-xr-x    1 967      100            32 Oct 14 14:53 subversion-java.tbz -> ../All/subversion-java-1.7.6.tbz
> lrwxr-xr-x    1 967      100            27 Oct 13 13:24 subversion.tbz -> ../All/subversion-1.7.6.tbz
> lrwxr-xr-x    1 967      100            28 Oct 14 01:54 subversion16.tbz -> ../All/subversion-1.6.18.tbz
> 226 Directory send OK.
> And this is partially what it pulls down dependency-wise:
> root at icarus:~ # pkg_add -r -n subversion
> Fetching ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-stable/Latest/subversion.tbz...  Done.
> Package dependency sqlite3- for ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-stable/Latest/subversion.tbz not found!
> Package dependency gdbm-1.9.1 for ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-stable/Latest/subversion.tbz not found!
> Package dependency db42-4.2.52_5 for ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-stable/Latest/subversion.tbz not found!
> Package dependency neon29-0.29.6_4 for ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-stable/Latest/subversion.tbz not found!
> I say partially because due to use of -n, some of those packages weren't
> downloaded, thus the recursive dependency nature is lost (I consider
> this mostly a bug with -n when used with a remote package, but it could
> also be deemed a feature).
> However, GDBM and Oracle/Sleepycat DB aren't (by default) enabled
> in 1.7.7 which is what's in ports currently:
> root at icarus:/usr/ports/devel/subversion # make run-depends-list
> /usr/ports/databases/sqlite3
> /usr/ports/devel/apr1
> /usr/ports/devel/gettext
> /usr/ports/textproc/expat2
> /usr/ports/www/neon29
> So GDBM and Oracle/Sleepycat DB are now disabled by default (good!),
> but now we have the following (and I will describe each of them for
> readers so they know what they're for):
> - SQLite -- which I believe is used for data storage for commits/etc.
>    and tends to work well for that, so I'm okay with it.
> - gettext -- needed for NLS, which I've learned to accept although I'd
>    rather everything today just use UTF-8 universally (idealistic me).
>    However, there are many people who are heavy WITHOUT_NLS advocates,
>    and I used to be one, so they should be honoured (IMO).
> - APR -- have yet to figure this out.  All I can think of is "svn is
>    an Apache project and we like injecting all our crap into everything,
>    so enjoy!".
> - expat2 -- XML parsing library, which I also have yet to figure out
>    the need for.  What VCS uses XML and why?  Is this really *needed*?
> - neon -- OPTIONS description labels this as "WebDAV/DAV support",
>    but in reality what this provides that's most important is HTTPS/SSL
>    support.  I found this out the hard way when building svn for a
>    customer 4-5 months ago.  NEON_DESC should really become this:
>    NEON_DESC=WebDAV/Delta-V access module + HTTPS/SSL support
> I want people reading this to remember olden days, because it seems
> we've taken a step backwards when it comes to applying minimalistic
> approaches and KISS principle.  I want people to remember the days of
> this command:
> pkg_add -r cvsup-without-gui
> And how it had a dependency on ezm3 (Modula-3 language), which its
> author insisted was needed "because cvsup's design needed M3 for speed"
> (I'd have to dig up his exact words).  This utter nonsense was debunked
> when csup -- written purely in C -- was introduced into the base system.
> I remember that day, and it was one of the happiest moments I had using
> FreeBSD.  Yes really.  All of my co-workers at the time who used FreeBSD
> rejoiced as well.
> I understand everyone uses svn differently, but there *needs* to be a
> package (or stub port) that is minimal, i.e. "install this to use svn on
> FreeBSD if you want to check out src and ports and other stuff"[1], that
> has absolutely no fluff in it other than what's needed, and I am not
> sure if the above defaults meet that requirement (thus possibly a
> stub-port would be good).  Possibly that can be accomplished by someone
> updating the existing subversion.tbz package on the servers to 1.7.7?
> Not sure.
> I also know FREEBSD_TEMPLATE is absolutely needed (failure to include
> that will result in weird breakage, which I've seen posts complaining
> about on the lists in the past).
> There is STATIC, which would be great for solving this (if you ask me),
> but if I remember right the port maintainer stated sometime in the past
> that he had concerns over this option given "security implications",
> e.g. if SQLite, etc. had security holes in them and thus had to be
> updated, a static build wouldn't be able to deal with that, but that's
> just a bunch of hogwash (I can explain why in detail if wanted).  So I
> doubt we'll see something like subversion-static.tbz anytime soon.
> So what's the point of my Email?
> I want to find out what is being done by the FreeBSD folks (that means
> Project members and Committers alike) to deal with this migration from
> the end-user perspective.  The Project has effectively destroyed
> csup/cvsup in different ways, especially over the past 2 days (I love
> seeing all CVS commits now done as user "svnexp" and the cvsweb.cgi
> interface is 100% broken -- thanks!  Nobody used this functionality
> anyway, right?), so for me svn is the only choice[1].
> Finally: for those wanting svn in the base system, good luck.  I'm sure
> licensing issues will be the main reason this can't happen.  This just
> circles back to my age-old argument about how the "base system" concept
> on FreeBSD needs to be nuked, and that all "base system" software should
> actually just be ports/packages and can be updated/maintained in that
> same fashion (but obviously with much more scrutiny).  There's no
> technical reason this can't be done, only social reasons.  For how this
> is done properly, see Debian.
> I look forward to responses, but I can assure you I will respond very
> little; I tend to be argumentative (case in point) and could battle this
> all day and night, but more importantly, the work/effort here is not my
> responsibility -- it is the responsibility of those who have deprecated
> something that was minimal and "just worked out-of-the-box".
> [1]: Regarding ports and "use portsnap": have no problem with portsnap,
> but it doesn't work for my workflow/model.  I absolutely need to see
> things in more real-time fashion than "when a portsnap mirror decides to
> update its snapshot from the master" (could be hours, could be days, who
> knows -- and we have seen occasions of these delays happen already, and
> not just recently).  I used csup (and when providing diffs for PRs, cvs
> itself) exclusively for ports and src, and I will therefore use svn for
> the same purpose.  Not for debate.  :-)

We should write a snup tool similar to csup, a bootstrap tool that 
depends on nothing and can fetch both src/ ports/ and doc/ repositories 
with branches support.


More information about the freebsd-ports mailing list