|
From: Robert W. <rj...@du...> - 2005-10-26 20:15:27
|
I'm seeing this: $ svn update svn: Berkeley DB error while opening environment for filesystem /home/svn= /repos/valgrind/db: DB_RUNRECOVERY: Fatal error, run database recovery svn: bdb: PANIC: fatal region error detected; run recovery Subversion sucks. Mercurial rules, OK. Regards, Robert. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
|
From: Nicholas N. <nj...@cs...> - 2005-10-26 20:28:04
|
On Wed, 26 Oct 2005, Robert Walsh wrote: > I'm seeing this: > > $ svn update > svn: Berkeley DB error while opening environment for filesystem /home/svn/repos/valgrind/db: > DB_RUNRECOVERY: Fatal error, run database recovery > svn: bdb: PANIC: fatal region error detected; run recovery Same here. > Subversion sucks. Mercurial rules, OK. Subversion's BerkeleyDB back-end sometimes sucks... the rest of it is pretty good. GCC's about to switch to it from CVS.. Nick |
|
From: Robert W. <rj...@du...> - 2005-10-26 20:58:24
|
> Subversion's BerkeleyDB back-end sometimes sucks... the rest of it is=20
> 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:
* There's the BerkeleyDB flakiness thing. Plus having to
_manually_ upgrade the DB whenever the BerkeleyDB version
changes.
* 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.
* Centralized repositories are so mid-90s.
* 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.
* Configuring an already-fun-to-configure Apache setup to plonk an
SVN server in on top.
* 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.
* 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.
Regards,
Robert.
--=20
Robert Walsh
Amalgamated Durables, Inc. - "We don't make the things you buy."
Email: rj...@du...
|
|
From: Dirk M. <dm...@gm...> - 2005-10-27 07:06:57
|
On Wednesday 26 October 2005 22:58, Robert Walsh wrote: > * There's the BerkeleyDB flakiness thing. Plus having to > _manually_ upgrade the DB whenever the BerkeleyDB version > changes. it has a FSFS backend which doesn't have all those problems (plus is much faster) > * Configuring an already-fun-to-configure Apache setup to plonk an > SVN server in on top. then don't use subversion over apache - its slower than anything else anyway. > * 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. actually it doesn't. but it verifies integrity of your local files first. so if you have a slow disk / bad filesystem, it can take very long time before actually connecting to the remote server. Dirk |
|
From: Josef W. <Jos...@gm...> - 2005-10-26 20:29:27
|
On Wednesday 26 October 2005 22:15, Robert Walsh wrote: > I'm seeing this: > > $ svn update > svn: Berkeley DB error while opening environment for filesystem /home/svn/repos/valgrind/db: > DB_RUNRECOVERY: Fatal error, run database recovery > svn: bdb: PANIC: fatal region error detected; run recovery > > Subversion sucks. Mercurial rules, OK. Git is nice, too. There is a SVN import now. Should be quite easy to switch ;-) Inclusive Web-Frontend and automatic mails to this list on a "push" to a "central" repository... Josef > > Regards, > Robert. > |
|
From: Robert W. <rj...@du...> - 2005-10-26 20:58:57
|
> Git is nice, too. There is a SVN import now. > Should be quite easy to switch ;-) I should point out that Mercurial has importers for just about everything under the sun. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
|
From: Nicholas N. <nj...@cs...> - 2005-10-26 21:21:16
|
On Wed, 26 Oct 2005, Robert Walsh wrote: > Having used SVN for a while now (on this project and on others), I can > say that I find it quite mediocre: Have you heard of Bazaar-NG? I haven't used it but it looks interesting. http://www.bazaar-ng.org/ |
|
From: Bryan O'S. <bo...@se...> - 2005-10-27 03:57:32
|
On Wed, 2005-10-26 at 16:21 -0500, Nicholas Nethercote wrote: > Have you heard of Bazaar-NG? I haven't used it > but it looks interesting. http://www.bazaar-ng.org/ It's quite similar to Mercurial, but slower. <b |
|
From: Julian S. <js...@ac...> - 2005-10-27 01:36:25
|
Fixed. J On Wednesday 26 October 2005 21:15, Robert Walsh wrote: > I'm seeing this: > > $ svn update > svn: Berkeley DB error while opening environment for filesystem > /home/svn/repos/valgrind/db: DB_RUNRECOVERY: Fatal error, run database > recovery > svn: bdb: PANIC: fatal region error detected; run recovery > > Subversion sucks. Mercurial rules, OK. > > Regards, > Robert. |
|
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.
|
|
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...
|
|
From: Dirk M. <dm...@gm...> - 2005-10-28 08:20:22
|
On Thursday 27 October 2005 20:46, Robert Walsh wrote: > Not that simple. For example, one of the repos I use is in a secure > national lab. http access is all they allow through. ROTFL... its so secure that they let people *transmit unencrypted credentials* ? You made my day. Dirk |