|
From: Christian P. <tr...@ge...> - 2005-10-27 17:43:03
|
On Wednesday 26 October 2005 22:58, Robert Walsh wrote:
> > Subversion's BerkeleyDB back-end sometimes sucks... the rest of it is
> > pretty good. GCC's about to switch to it from CVS..
>
> Having used SVN for a while now (on this project and on others), I can
> say that I find it quite mediocre:
saying mediocre gives me the feeling of a very very bad word.
when you really feel that way, then you'd better stay away=20
from svn in any way.
> * There's the BerkeleyDB flakiness thing. Plus having to
> _manually_ upgrade the DB whenever the BerkeleyDB version
> changes.
That's why they introduced fsfs.
> * Branching and merging is as bad as CVS: you actually have to
> remember what revisions you've merged in yourself. For busy
> repositories like some I'm involved in, that can be painful.
> This is probably my biggest gripe. With a changeset concept
> added to Subversion, I at least expected this to be fixed, so
> imagine my surprise.
star mergin technique is on the way. it's "well known" by the=20
subversion devs, that svn's merging is as trivial as in CVS,=20
however, branching is far off the same as in CVS. I guess you=20
never did it, when you say it actually *is* the same.
When you need "star merging"-alike features, use SVK as SVN client which=20
already supports it.
> * Centralized repositories are so mid-90s.
this is FUD. SVN is adopting some basic ideas from CVS, so, that users will=
=20
have it easy to switch over. This counts in for centralization as well as f=
or=20
the client side commandline use.
If you still want a decentralized approach, you'd be better with SVK (which=
is=20
based on SVN API).
> * Subversion is 120,000+ lines of code PLUS all the APR and neon
> stuff clocking in at another 350,000 lines of code, versus
> 10,000 lines of python for Mercurial. Python runs everywhere,
> even on Windows: portability was essentially free.
as said above, when you don't like it. don't use it. but don't blame others=
=20
about that you feel so bad in using it.
I (in my case) don't like CVS, but I (usually) don't blame it publically in=
a=20
way you do (that is: somewhat "mediocre").
> * Configuring an already-fun-to-configure Apache setup to plonk an
> SVN server in on top.
you don't need Apache to provide access to SVN repositories.
Think about svn:// and svn+ssh://. Simply RTFM.
> * Slow slow slow slow updates, especially for large repos or
> continent-spanning net connections: looks like SVN still checks
> every file in your repo against the server's version every time
> you do an update. So, I've changed my mind: this is probably my
> biggest gripe. I have to wait about 3 minutes to get a repo
> based in New Mexico updated, even if there's no changes (I'm in
> California.) Again: what did they add changesets in for?
> Changesets that aren't really changesets are kind of lame.
This "performance issue" is well known by the svn devs and got *partly* fix=
ed=20
at the time KDE were about to switch over from CVS to SVN.
I'd recomment you to join #svn and/or #svn-devel at OPN if you have some go=
od=20
(meaning: not "lame") ideas and proposals on how to improve it.
Doing so could also change your future experience when using svn after havi=
ng=20
these improvements being implemented :-P
> * Plus, I hate that 'svn update' updates the current directory and
> it's subdirectories, and not the whole repository, but that's a
> personal thing.
This is just like CVS did, and I personally don't find this behavior that=20
"hate"-full, in fact, it even shouldn't affect upper-level directories. But=
=20
this is just a matter of policy. If you like to change that, write your=20
little script that finds the local root of your working copy and does the s=
vn=20
update from there.
Obviousely, you like the other policy, then add e.g. the following=20
into your ~/.bashrc:
function svnup() {
pushd . &> /dev/null
while [ -d "../.svn" ]; do
cd ..
done
svn update
popd &> /dev/null
}
Best regards,
Christian Parpart.
|