Let's talk about subversion/svn
jdc at koitsu.org
Mon Nov 19 07:16:09 UTC 2012
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
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-188.8.131.52 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
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,
- 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
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", 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?
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.
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".
: 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. :-)
| Jeremy Chadwick jdc at koitsu.org |
| UNIX Systems Administrator http://jdc.koitsu.org/ |
| Mountain View, CA, US |
| Making life hard for others since 1977. PGP 4BD6C0CB |
More information about the freebsd-ports