Branches
Articles referencing this project
Comments
[»]
subversion is NOT cultural replacement of CVS. I decided NOT to migrate.
by Sampo Kellomäki - Apr 15th 2006 18:31:34
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
--
ID Mgmt Specialist, Federated Single Sign-On, Identity Web Services
[reply]
[top]
[»]
Re: subversion is NOT cultural replacement of CVS. I decided NOT to migrate.
by delt - Aug 3rd 2007 18:02:10
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.
[reply]
[top]
[»]
Re: subversion is NOT cultural replacement of CVS. I decided NOT to migrate.
by Dag-Erling Smørgrav - Jan 22nd 2008 04:07:11
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.
[reply]
[top]
[»]
excellent work
by Adrian Thurston - Mar 8th 2004 10:24:13
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.
[reply]
[top]
[»]
Ahh, we *certainly* do need a CVS replacement...
by Charles Duffy - Oct 9th 2003 15:02:20
...but the goal of "CVS without the warts" (which seems pretty
much like what Subversion wants to be) is perhaps shooting a bit low.
Folks looking for a modern, Free Software revision control system might be
well served to also consider <A
HREF="http://gnuarch.org/">GNU Arch</A>, a revision
control system with somewhat higher goals (including distributed repository
support a la BitKeeper, some very high-end merge algorithms, dumb server
support (so *any* WebDAV/sftp/ftp server can be an arch repository server
without unmodified) and quite a bit of community support. In my experience,
tla (the modern arch implementation) is also more stable.
Don't get me wrong -- having a changeset-based revision control system
with similar usage to CVS but lacking its worst flaws is a Very Good Thing
-- but it's also possible to aim higher, and SVN (best I can tell) really
doesn't do that.
[reply]
[top]
[»]
Re: Ahh, we *certainly* do need a CVS replacement...
by Greg Stein - Oct 9th 2003 15:57:01
> Folks looking for a modern, Free
> Software revision control system might
> be well served to also consider GNU
> Arch,
Hey, thanks for trying to advertise another solution here. Please keep
this kind of stuff to your own FM entries.
> blah feature this blah feature that blah
The two have different feature sets because of different design goals. Any
sort of comparison, or even worse, trying to position one as better than
the other, in this small space is just silly. Don't even try.
> In my experience, tla (the
> modern arch implementation) is also more
> stable.
SVN is very, very stable. We are just super conservative with how we label
the project. We don't want to misrepresent, and we want to install
confidence. Thus, we aren't shoving a 1.0 out the door just because we feel
like it.
I'd be alright with saying arch is "just as stable" because it might match
our stability. I don't have any info to say if arch is less, but I
know it can't be more.
> Don't get me wrong -- having a
Don't get me wrong... you're just here to push your solution to
people who are looking at the Freshmeat entry for Subversion. That is not
very social of you.
The simple answer is that SVN has targeted a very specific design model
that works for a large group of people. That model looks and feels a lot
like CVS simply because we want it to. We want people to feel
comfortable switching. If you don't like that, then you're free to use
other systems. But don't come here and criticize or dump on SVN, and even
worse: don't use this area as an advertisement for your own preferred
system.
[reply]
[top]
[»]
Stability
by Charles Duffy - Nov 6th 2003 14:36:43
> SVN is very, very stable. We are just
> super conservative with how we label the
> project. We don't want to misrepresent,
> and we want to install confidence. Thus,
> we aren't shoving a 1.0 out the door
> just because we feel like it.
I've had too many client-side failures trying to check out svn
repositories and cases where I had to rm and re-checkout a repository I'd
already grabbed (which suddenly decided it didn't want to update) to agree
with that statement.
(I track debian-unstable, so I'm fairly sure that at the times when these
errors occurred I did in fact have a current svn client build).
[reply]
[top]
[»]
Re: Etiquitte (& a lame self-justification attempt)
by Charles Duffy - Nov 6th 2003 14:51:20
> 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.
[reply]
[top]
[»]
Re: Etiquitte (& a lame self-justification attempt)
by Karl fogel - Dec 13th 2003 23:04:17
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
[reply]
[top]
[»]
Re: Etiquitte (& a lame self-justification attempt)
by Daniel Sterling - May 3rd 2004 21:15:26
>
> 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
[reply]
[top]
[»]
Slightly hypocritical
by Tim Angus - Dec 20th 2003 18:16:17
I thought this reply was a bit strong considering that SVN promotes itself
as a CVS replacement, but there you go.
[reply]
[top]
[»]
Re: Ahh, we *certainly* do need a CVS replacement...
by Floyd - Apr 27th 2005 22:18:41
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.
[reply]
[top]
[»]
Thoughts
by GladeSoft - Oct 25th 2002 13:05:09
Subversion seems very impressive. The idea of the copy-on-write semantics
that give you labling and branching are quite well thought-out.
My only complaints about subversion are that it is difficult to install
with so many required packages. I also wish the DB was pluggable.
This would be a great project to combine with Katie, the open-source
ClearCase clone. You could really export the Subversion filesystem as a
filesystem and have little queries based on properties.
That would be quite powerful.
[reply]
[top]
[»]
Re: Thoughts
by Greg Stein - Oct 25th 2002 17:50:14
The installation requirements will become easier over time, as the
dependencies become readily available. For example, RedHat 8.0 now installs
DB 4.0. Also note that SuSE 8.1 includes Subversion packages. Similar for
Debian and other linux distributions.
A pluggable database is already planned for a release after 1.0, and some
people are even working on it today.
Note sure about Katie, though. Got enough to do for 1.0 :-), but would be
interested in seeing somebody try it out.
[reply]
[top]
[»]
Very important project
by Pavel Roskin - Jan 18th 2002 11:03:35
I want to thank everyone working on the project. It is very important for
the community. I've been working with CVS for years and I know that it has
limitations that cannot be eliminated without redesigning CVS and breaking
compatibility. Besides, CVS was developed without security in mind, and as
we all know, one cannot add security later.
An open-sourced, full-featured, secure by design version control system is
needed badly.
Good job!
[reply]
[top]
[»]
Re: Very important project
by EAN - Mar 12th 2004 15:50:45
> 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
--
Wilderness is where you might get lost. Wander Well!
[reply]
[top]
|
