[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [E-devel] cvs, servers and stuff.
> It's not true. SVN requires a lot more overhead (including Apache
> with SVN and DAV modules),
They aren't required, they just make things easier. You can use a
standalone svn daemon, or AFAIK have a client side client and server
side client who talk over SSH (similar to rsync's two-client mode?).
I've only ever used Apache + mod_svn myself though.
Even if you do go the apache + mod_svn route, since when was apache
known for being bloated and slow? (Sure it's slower than things like
lighttpd, but even with all the bloat turned on the apache overhead is
still tiny compared to the processor time spent getting actual work
> uses a BDB backend (you remember your love of BDB, right?)
Since a few years ago, it's been able to use a filesystem based
database, which I've never had problems with (BDB kept me away from
SVN for a while too, since it kept giving me headaches...)
> and requires DOUBLE the amount of disk space for a
> checkout. Yes, I said double.
Having a local copy of the unmodified source makes things like taking
diffs or reverting changes *much* faster, and zero load on the server.
Disk space shouldn't be much of an issue with today's drives; Raster's
point about running rsync on his local checkout will indeed use twice
the bandwidth if it's done the naive way, but I'm sure there are some
optimisations that could be done. (I'm interested in knowing why
someone would want to rsync their local copy anyway, rather than
checking into the server on one box and checking out elsewhere)
> Furthermore, branching and tagging
> don't really exist for SVN (it uses "copies" which, while they may be
> zero overhead on the server, are murder on the checkout).
I've found tagging much cleaner, and you don't need to check anything
out at all:
svn cp http://server/project/trunk http://server/project/tags/0.4.2
(if you want to retroactively tag an old version of the trunk, just
add "-r <revision number>" before the trunk URL). Practically zero
overhead on the server (all it stores in the copy is a reference to the
trunk filename and revision), and zero overhead on the client.
Branching I've only experimented with, but don't use regularly enough
to say whether it's better or worse than CVS's.
> And last I checked, you could not keep your history.
The cvs2svn script seems to have worked fine for other large, active
projects (mplayer, gaim, and inkscape are the ones in my src folder)
Unfortunately for the topic at hand, the only thing I can't say for
certain is "SVN is better at dealing with server-killing loads caused
by vast numbers of anon checkouts". Using my otherwise unused 200MHz
test server, browsing the HTTP interface is as fast as browsing plain
text files, but I don't know if it'll stay that fast with thousands of
users at once...