The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Subversion versus CVS

We currently use CVS for all our source code control. I know that Subversion is a relatively new SCC system.

Are there any practical benefits to switching from CVS to Subversion?

Thanks!
Roger Jack Send private email
Wednesday, April 20, 2005
 
 
The one thing that made me switch was rename support. But having atomic commits is nice too, plus the incredibly fast tag and branch performance is easy to get used to.

If you switch make sure you use the more robust native file system format and not the Berkeley database format.

On the other hand: if it ain't broken...
Jan Derk
Wednesday, April 20, 2005
 
 
It's much more flexible, supports renames, moving files, atomic commits, and lots of other things.

I've been back in CVS for 3 months after a 1.5 years of being mostly in Subversion (VSS was the other part) and the pain is immense.
KC Send private email
Wednesday, April 20, 2005
 
 
Let's not forget repository-wide version numbering. Per-file version numbers are IMHO the absoute worst thing about CVS. Unless a particular point in time has been tagged, it's very difficult to get a consistent snapshot of what the repository looked like at a point in time, or to see what changes happened as part of a particular commit.

For those not familiar with the two systems, a CVS commit might bring one file to r1.17, another to r1.1, and a third to r1.42. A Subversion commit would bring all three to the same version number.
comp.lang.c refugee
Wednesday, April 20, 2005
 
 
I second the reccomendation to use the native file store (FFS) instead of Berkeley DB. I had frequent repository corruption with BDB, but not a hiccup since switching to FFS.
comp.lang.c refugee
Wednesday, April 20, 2005
 
 
That's FSFS, not FFS.
comp.lang.c refugee
Wednesday, April 20, 2005
 
 
Good call, the repository-wide counter is one of the greatest things ever.

Whenever I sit down to do work for a client, I keep track of what number I started with.. just in case I completely kill the code.  Rolling back is a snap.
KC Send private email
Wednesday, April 20, 2005
 
 
A local respository is simple.
Tayssir John Gabbour Send private email
Wednesday, April 20, 2005
 
 
Can someone share experience on how well Subversion handles *merging* branches back?

CVS has *exellent* merge support for over a year now in its CVSNT fork (which, despite what the name suggests, runs well on everything and not just on NT).

Not up to the arch/monotone/codeville standard of merging capabilities, but continuously branching, merging and re-merging from one branch to the trunk works amazingly well. (If you have had bad experience with CVS merging, which sucked bacly, have a look at CVSNT).

So, branching is fine and all, but how does Subversion fair in merging?
Ori Berger Send private email
Thursday, April 21, 2005
 
 
Subversion writes stuff into the files. You then get to edit them anyway you want.

Then you say "OK, I merged these changes" and it commits them next time.

This is, frankly, a Good Thing.

It works well in practice.
Katie Lucas
Thursday, April 21, 2005
 
 
Subversion merging is as Katie described, and I find that it works well. An external merge tool comes in handy for handling conflicts. I've been happy with kdiff3.
comp.lang.c refugee
Thursday, April 21, 2005
 
 
Subversion is much better than CVS. I have used both. I now use Subversion for (what I now believe I must call) my micro-ISV, and it does exactly what I need. I am also (wearing my freelance consultant hat) a heavy user of Perforce, which is great but costs $700 a seat or something horrible like that (clients pay for my access to their installations).

The clincher is the fact that (like in Perforce) you get a unique number for each state of the entire project - the current revision number. That enables you to synch to any revision, and track major releases by tying them to revision numbers.

And SVN tracks renames and all other changes to the file system.

I use TortoiseSVN, a very nice Windows front end that works as a Windows explorer plug-in, and host my project on CVSDude, which is bloody good value ('scuse the language).

My project is relatively small but not trivial - there are a few hundred source files and it takes 3-4mb.
Graham Asher Send private email
Thursday, April 21, 2005
 
 
==> Can someone share experience on how well Subversion handles *merging* branches back?

It's sweeeet. I had some difficulty at first because the dialogs (IMO) were non-intuitively labelled. That is the fault of my front end (Tortoise) and not necessarily the the fault of Subversion. It set me back about 15 minutes on the first one (I screwed it up severely) while I figured it out. From then on, it's been a breeze with absolutely no complaints. We don't think twice about creating branches because it's so easy to merge back. We had used VSS before, and had so many problems with merging that it took a committee, and a corresponding act of god, to allow a simple branch to take place.
Sgt.Sausage
Thursday, April 21, 2005
 
 
You know how in CVS you don't need CVS installed.  Well you just need WinCVS and then you can basically simluate everything without a real server.  Just by using "Local" authentication in the Preferences.

Can this be done using Tortoise (which I assume i the equiavalent of WinCVS?

The reason I want an easy front-end and no unix and the backend is because I want to install this at a clients site and they like to update html with pretty graphics when I'm not around.  They don't want anything to do with anything that's not on windows.  But, I do want to be able to keep track of who changes what.

Should I just stick with winCVS instead?  Personally, I'd like to try Subversion/Tortoise because it's nice to get expereince with something while your gettting paid to do so.
Soon to be Humbled
Friday, April 22, 2005
 
 
Even while still on CVS, install TortoiseCVS. It is an almost complete replacement to WinCVS and much, much, easier to use. http://www.tortoisecvs.org

The SVN equivalent of WinCVS is called RapidSVN if memory serves me right, and there's also TortoiseSVN.
Ori Berger Send private email
Friday, April 22, 2005
 
 
Yes, both TortoiseCVS and TortoiseSVN allow you to create and checkout from a local repository in a folder without the need for a CVS or SVN server. This is in fact the easiest way to familiar with both.

Not that you would need Unix if you choose to install a server version. Both the CVS and Subversion servers run happily on Windows.
Jan Derk
Friday, April 22, 2005
 
 
We're planning to switch from CVS to Subversion next month. Does Subversion support email notifications when files are checked in?
Julian
Friday, April 22, 2005
 
 
I strongly recommend getting a copy of "Pragmatic Version Control using Subversion", by Mike Mason (ISBN 0-9745140-6-3).

It covers just about everything Subversion can do in a very easy "I need to get this done NOW" style that made it a snap to set up and start using.

I recently switched my home repository from CVS to Subversion - I'll never go back. The fast tags, the "branches are copies" model, "tags are copies" model, it's all just so straightforward.

And if you're on Windows, DEFINATELY get TortoiseSVN. It makes working with Subversion almost effortless, and includes a really good three-way diff/merge program as an added bonus.
Chris Tavares Send private email
Saturday, April 23, 2005
 
 
First, a small caveat: I have contributed some patches to the Subversion code. That put aside, Subversion is a much better alternative to CVS: many operations (like "svn diff") are faster, many things are possible only with subversion, binary files are handled efficiently, there are atomic commits, merging is much nicer than CVS, and it can also be hosted over HTTP/HTTPS. It's very slick, and is a joy to use, whereas using CVS now (especially over a remote Internet host) feels very painful.

I highly recommend you give it a try. Note that there's cvs2svn which converts CVS repositories to working Subversion ones.
Shlomi Fish Send private email
Sunday, April 24, 2005
 
 
Julian: subversion has no problem sending E-mails when commits are done. I think it is done using post-commit hook, but I never set up such a thing so I can't tell.

Consult the good people in Freenode's (http://www.freenode.org/) #svn channel for details.
Shlomi Fish Send private email
Sunday, April 24, 2005
 
 
Thanks a bunch.  I've been reading these JOS forums for over a year and have seen a couple threads about CVS and subversion, but this is by far the most helpful.
Soon to be Humbled
Sunday, April 24, 2005
 
 
[answering to my own question]

Subversion lacks behind cvsnt in the merging department. You need the (contrib) script svnmerge to get close to the level provided by CVSNT. Perhaps this is also integrated in TortoiseSVN, I'm not sure - but basic SVN is not too good at knowing what to merge.
Ori Berger Send private email
Tuesday, April 26, 2005
 
 
My biggest concern regarding any Source Control System is how easy is it to backup and move, and restore?  Say I build a little server box, and have it run SVN.  How do I back it up in case I feel like rebuilding the box or moving it so some other one?  Is it a simple copy and paste?  Or is it some complicated mess of links and depencies that concrete the whole repository into a stand still?
sedwo Send private email
Tuesday, April 26, 2005
 
 
Both SVN and CVS are both a simple "copy and paste" to backup the respository.

Most source code control systems (excluding perhaps VSS) are like that.
Almost Anonymous Send private email
Tuesday, April 26, 2005
 
 
>I second the reccomendation to use the native file store
>(FSFS) instead of Berkeley DB. I had frequent repository
>corruption with BDB, but not a hiccup since switching to >FSFS.

I'll third this. I too had problems with berkely-db over ssh, no problems with after dumping and recreating repositories with filetype=fsfs:

svnadmin create --fs-type fsfs {repository path}

Additionally cvs2svn worked perfectly for me converting my CVS repositories
Gordon Hartley Send private email
Wednesday, April 27, 2005
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz