|
From: Robert W. <rj...@du...> - 2005-10-27 18:46:18
|
> > * There's the BerkeleyDB flakiness thing. Plus having to
> > _manually_ upgrade the DB whenever the BerkeleyDB version
> > changes.
>=20
> That's why they introduced fsfs.
Granted. Valgrind needs to switch over to this.
> star mergin technique is on the way.
It's not there already, which makes it next to useless for existing
repositories. I already have repos where I have to hand-track merges.
Will the new merge stuff automatically figure out these existing merges?
I don't think it can, unless it comes with a natural-language processor,
because none of the meta-data (from rev blah, directory blah) is left
around.
> > * Centralized repositories are so mid-90s.
>=20
> this is FUD
I don't know what you mean by this, unless you have a different
definition of the word FUD to me. I'm expressing an opinion here. FUD
doesn't enter into it.
> 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=
for=20
> the client side commandline use.
Users, I've noticed, are not stupid: they can mostly deal with new
ideas. Distributed can be made to look centralized if that's a problem.
Switching over to just about any new SCM from CVS is made trivial by the
wealth of importers that exist. I don't buy the "easy migration from
CVS" argument one bit.
> as said above, when you don't like it. don't use it. but don't blame othe=
rs=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").
Wow. I'm not about to bottle up my thoughts on something just because I
might make someone cry. I'm expressing an opinion based on observations
I've had working on projects where I have no policy access to the
repositories. I'm only blaming people in so much as anyone who files a
bug report blames someone. Do you think any argument against SVN is by
default mediocre?
> > * Configuring an already-fun-to-configure Apache setup to plonk a=
n
> > SVN server in on top.
>=20
> you don't need Apache to provide access to SVN repositories.
> Think about svn:// and svn+ssh://. Simply RTFM.
Not that simple. For example, one of the repos I use is in a secure
national lab. http access is all they allow through. ssh certainly
isn't going to be allowed, and their admins will balk at the thought of
opening up yet another port.
> This "performance issue" is well known by the svn devs and got *partly* f=
ixed=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 =
good=20
> (meaning: not "lame") ideas and proposals on how to improve it.
> Doing so could also change your future experience when using svn after ha=
ving=20
> these improvements being implemented :-P
But, why bother? Right now, I can get a really fast SCM (actually,
there's a choice of several) that solves all my problems without having
to wait for future performance and functionality fixes, mess around with
alternative clients to make functionality magically appear, etc. I know
these existing SCMs were designed from the ground up as distributed SCMs
with changesets treated as first-class objects and not an afterthought,
which makes them fast and convenient right out of the box.
My capsule summary of your counter-argument is:
* Don't use BerkeleyDB.
* The new functionality is on the way.
* Yes, performance is a problem. Try fix it yourself.
* If you don't like it, use something else. Good idea!
* Don't express an opinion that might offend someone.
--=20
Robert Walsh
Amalgamated Durables, Inc. - "We don't make the things you buy."
Email: rj...@du...
|