Projects / Subversion / Comments

Comments for Subversion

22 Jan 2008 04:07 fmdes

Re: subversion is NOT cultural replacement of CVS. I decided NOT to migrate.
I realize this is a fairly old post, but... pretty much everything in it is either unsubstantiated opinion or factually wrong.

> 1. subversion is NOT cultural replacement of cvs. In their fevor to

> improve, they broke too many things. I would not mind slight

> changes in syntax, but the whole flavour is alien. Essentially

> using subversion requires you to learn entirely new version

> control system and very few lessons learned from CVS will carry

> over.

Unsubstantiated opinion. I used CVS for ten years before switching to Subversion and had no trouble at all adapting. The only things I needed to learn from scratch were Subversion features that CVS simply doesn't have.

I still use CVS extensively, but I vastly prefer Subversion.

> 2. subversion is "modern" software. This means it

> depends on ten other projects. They do not bother

> to document these dependencies in a comprehensible way and

> the ./configure script fails in mysterious ways (apart

> from taking forever to run before it fails). It also

> seems there is good deal of bloat and needless abstractions

> that do not serve a useful purpose.

Building Subversion from scratch instead of using the prepackaged version provided by your OS or distribution of choice was entirely your own decision.

The abstractions you complain about are far from useless; they make Subversion extremely portable while allowing the developers to focus on functionality rather than portability.

> 3. subversion abandoned the CVS flat file philosophy and

> went for BerkeleyDB. Then they noticed that people actually

> considered flat plain text files a good thing(tm) and tried

> to retrofit it. As such, it does not seem to be anywhere

> near the level of stability of the BerkelyDB backend.

Factually incorrect. The fsfs backend was written because of stability and consistency issues with the bdb backend (when accessing a repo over NFS, for instance) and because it makes repo corruption more easily recoverable. It is significantly faster and more stable than the bdb backend, and has been the preferred backend for quite a while (since 1.2).

> But even if you wanted to use BerkeleyDB, they have added

> gazillion dependencies to specific versions of BerkeleyDBs

> so your standard install BerkeleyDB does not work. You will

> need to hand craft a BerkeleyDB that is palatable to

> subversion. Hardly portable, eh?

Factually incorrect. The only issue is that accessing a bdb repo directly (not remotely) with a client built against a newer bdb version will automatically upgrade the repo, rendering it inaccessible to older clients. If all your users access the repo over SSH, you will never run into this problem.

> 4. subversion ssh support seems complicated and much more bloated

> than cvs. In effect subversion is geared towards WebDAV and

> when you try to do ssh, it resorts to trying to emulate

> WebDAV locally on the host where you ssh to. Frankly, cvs

> is much easier to understand.

Factually incorrect. CVS and Subversion implement SSH access in pretty much the same manner.

> 5. subversion simply does not seem to be addressing the need

> we have: ssh accessed repository. They spend all their

> powder on snazzy remote access via WebDAV but forget the

> home base.

Factually incorrect. See above. SSH access works very well - far better than with CVS, in fact, because every time you update or diff a CVS working copy over SSH, CVS does a partial checkout of the corresponding parts in /tmp on the server.

> 6. cvs is not seriously broken. It meets Symlabs needs pretty

> well and only occacionally behaves "mysteriously". It has

> strong culture and has widely available "googlebase" so you

> can get your problems solved. cvs never lost a file for

> us (though some users did by not fully understanding how

> it works).

Bully for you. Projects with large CVS repos that have been around for a while (FreeBSD, for instance) have experienced both repo corruption and other issues caused by changes in repo syntax over time.

Remember, by the way, that disks sometimes fail, and even RAID controllers have been known to silently corrupt data on the way to or from disk.

03 Aug 2007 18:02 delt

Re: subversion is NOT cultural replacement of CVS. I decided NOT to migrate.
Agreed. Now that i -finally- found it (dumbasses couldn't even add "svn" to the search tags) and tried to compile/run it about 10 times with different sets of libraries, dependencies, etc. i have yet to understand what this piece of junk is supposed to accomplish, other than complicating everyone's lives by adding yet another layer of red tape on top of this whole "which tool is the gospel truth" disaster.

15 Apr 2006 18:31 sampo

subversion is NOT cultural replacement of CVS. I decided NOT to migrate.
Someone asked recently why Symlabs is still using cvs and not subversion.

Well, I was provoked to try subversion out and this is what I found out.

Comments based on subversion-1.3.1.

1. subversion is NOT cultural replacement of cvs. In their fevor to

improve, they broke too many things. I would not mind slight

changes in syntax, but the whole flavour is alien. Essentially

using subversion requires you to learn entirely new version

control system and very few lessons learned from CVS will carry

over.

2. subversion is "modern" software. This means it

depends on ten other projects. They do not bother

to document these dependencies in a comprehensible way and

the ./configure script fails in mysterious ways (apart

from taking forever to run before it fails). It also

seems there is good deal of bloat and needless abstractions

that do not serve a useful purpose.

3. subversion abandoned the CVS flat file philosophy and

went for BerkeleyDB. Then they noticed that people actually

considered flat plain text files a good thing(tm) and tried

to retrofit it. As such, it does not seem to be anywhere

near the level of stability of the BerkelyDB backend.

But even if you wanted to use BerkeleyDB, they have added

gazillion dependencies to specific versions of BerkeleyDBs

so your standard install BerkeleyDB does not work. You will

need to hand craft a BerkeleyDB that is palatable to

subversion. Hardly portable, eh?

4. subversion ssh support seems complicated and much more bloated

than cvs. In effect subversion is geared towards WebDAV and

when you try to do ssh, it resorts to trying to emulate

WebDAV locally on the host where you ssh to. Frankly, cvs

is much easier to understand.

5. subversion simply does not seem to be addressing the need

we have: ssh accessed repository. They spend all their

powder on snazzy remote access via WebDAV but forget the

home base.

6. cvs is not seriously broken. It meets Symlabs needs pretty

well and only occacionally behaves "mysteriously". It has

strong culture and has widely available "googlebase" so you

can get your problems solved. cvs never lost a file for

us (though some users did by not fully understanding how

it works).

Now that I have this out of my system, do not expect me to look

at subversion in next five years - or until I get annoyed

enough about some CVS shortcoming and feel I can't fix it

within CVS.

Cheers,

--Sampo

27 Apr 2005 22:18 floyd59

Re: Ahh, we *certainly* do need a CVS replacement...
Just a feedback from a reader: When i read the advertisment above, i just thought: "if gnu/arch needs that kind of unfair pushing, it cant be very good". For me, it just disqualified itself and i'll definitely give subversion a try.

Cheers, and keep it up.

03 May 2004 21:15 eqhmcow

Re: Etiquitte (& a lame self-justification attempt)


>

> Hey, thanks for trying to advertise

> another solution here. Please keep this

> kind of stuff to your own FM entries.

well, I for one agree with Charles' motives. I did come to the subversion page to *research* alternatives. I appreciate someone broadening my horizons by letting me know that CVS and SVN aren't the only VC Systems on the OSS street.

-- Dan

12 Mar 2004 15:50 0x1b

Re: Very important project

> I want to thank everyone working on the
> project. It is very ....
> Good job!


Thank you very much - I can't wait to get mod_authz_svn and SVNParentPath working together!

Thank you one and all

08 Mar 2004 10:24 age

excellent work
Thank's for writing this! Switching from CVS was very pleasant. I can't even count the number of times I thought to myself "ahh, right on" while learning the Subversion way of doing things.

20 Dec 2003 18:16 tangus

Slightly hypocritical
I thought this reply was a bit strong considering that SVN promotes itself as a CVS replacement, but there you go.

13 Dec 2003 23:04 kfogel

Re: Etiquitte (& a lame self-justification attempt)

Charles, thanks for your eloquent apology, that was a very standup thing to do.


Regarding the problems you apparently had trying Subversion, a couple of comments:


One, I don't know what version of Subversion ships with debian-unstable (packages.debian.org is down at the moment, so I can't check), but I'd be surprised if it's anywhere near our latest releases. We have a very regular schedule of frequent alpha releases, so we can get bugfixes out there as quickly as possible. Most OS package maintainers don't update as frequently as we release -- nor can one blame them, as it would be a lot of work. So if you want to try Subversion in its alpha stage, you really need to download a source tarball and compile.


Two, when you had problems with such basic operations, did you post to the users@subversion.tigris.org or dev@subversion.tigris.org list describing the problem? We would surely have jumped all over such a fundamental bug... But I don't recall seeing such a report, at least not recently.


-Karl

06 Nov 2003 14:51 cduffy

Re: Etiquitte (& a lame self-justification attempt)

> Hey, thanks for trying to advertise
> another solution here. Please keep this
> kind of stuff to your own FM entries.

You're right, btw -- on reflection, that was at least a bit out of line.

That said, the mention here wasn't just meant to spam the entry of random-other-rcs-system -- I've tried SVN, indeed did so before I'd ever heard of earch. My "stability" dig wasn't just blowing smoke, but based on personal experience; the feature references were based on things I actually find handy in practice. SVN is widely considered *the* alternative to CVS, and the first stop by folks who are interested in alternatives -- not only because it's a good system, but also because it's the Alternative RCS they've actually heard of (see frequent references on /. and elsewhere).

In short: I probably shouldn't have made that initial post -- you're correct, it wasn't really appropriate. That said, I'd like to think it was at least a step or two up from random spam.

Screenshot

Project Spotlight

ReciJournal

An open, cross-platform journaling program.

Screenshot

Project Spotlight

Veusz

A scientific plotting package.