Slashdot Mirror
Ease Into Subversion From CVS
comforteagle writes "While you have a nice leisurely Sunday afternoon/evening you might want to read this fine article on easing into Subversion from CVS. Written by versioning admin Mike Mason, it talks about the philosophy and design behind Subversion (now 1.0), how it improves upon CVS, and how to get started using it."
We're switching. CVS is crufty, buggy, and slow. That alone is reason enough to switch, but atomic commits and faster and more transparent branching will be, in the long run, a more fundamental win.
'jfb
To spur "enterprise Linux," Big Bang, the distributed two-phase commit.
Before reading this, let the record show that I am a subversion fanboy. But I am only a Subversion fanboy because it solved almost all of my complaints about CVS. I am not involved with the project at all.
Do developers out there voice the need to store binaries?
Uh, most projects of any size will have at least a few binary files in their repository... icons, etc. But you could store those in CVS without too many problems.
Also, have there been many problems that required atomic commits? Can someone explain why this is important?
Rolling back changes without atomic commits is a pain in fucking ass. Have you ever had to do it? You have to track down every file that you changed (somehow... hopefully you can remember), check which version was the version prior to your commit, and get all those versions of files. For example "Okay, I need version 1.7 of foo.c and version 1.8 of barf.c and version 1.13 of foo.h." It's totally annoying.
Plus atomic commits just makes it much, much easier to keep track of what changes have gone it. This is my biggest, biggest complaint about CVS. File-level commits just make no sense. There is no time, ever, that I can think of when the ability to commit an entire changeset at once isn't better than committing a single file at a time.
Also, Subversions says that it is much faster at things like tagging, but tagging is not a very frequent operation...
Depends on your development process. During beta periods, it's common to make a tag or two per day, and if each tag takes ten minutes, well... it's not a big thing, but it's certainly annoying.
To me it sounds like a great product but I am not able to see a compelling reason why most development shops out there who are currently in CVS would rush to switch.
Certainly not every shop is going to "rush to switch". But, regardless, I imagine that every shop will switch eventually. It may take years, but subversion's advantages are significant enough that in my opinion it will become the new version control standard.
Also note that CVS was crufty and adding new features was almost impossible. Subversion targetted CVS features as their 1.0 milestone. But more importantly, the Subversion code base is a much better baseline to work from when adding new features. So you can expect that it will only get better in the future.
Do developers out there voice the need to store binaries? I can imagine this being needed for web developers and such, but I think programmers can just build their binaries from CVS.
Yes, developers definitely need to store binaries. I worked on a project awhile back where the boot block code was a finished binary. Because CVS was used to house the project, a horrible kludge involving UUENCODE had to be used to store the binary commits. Sometimes the binary was created by a totally different tool that the main build machine doesn't have. In the case I speak of, the binary was built with an expensive licensed assembler for an Analog Devices DSP chip, and contained as a body of the 'build' because it was dynamically 'injected' into the dsp processor from the native processor, which happened to be an 80196.
There are always cases where a binary needs to be committed. Think about bitmaps and other resources. It doesn't make sense to 'generate them from source' every time a build is done.
Given all this, it's my understanding that with newer versions of CVS binaries can be committed safely. Is this even an instance where 'Subversion' is needed?
---
Ok, I saw some questions about why people should switch from CVS to Subversion. The article does a nice job of covering what features Subversion adds, but people still seem to wonder why these are important.
Atomic Commits:
As stated in the article, if something goes wrong in the middle of a CVS commit (e.g. network goes down) it can leave the commit only partially complete. This can be a problem if changes in multiple files are dependent upon each other. Say I add a function to an API, then call it in other file. If the call gets committed and the API change doesn't, now the code in CVS won't compile. With atomic commits if the connection was dropped the commit would simply roll back. Then when my network came back up I could try to commit again, but the repository would never be left in a state where it didn't compile.
Constant Time Tagging/Branching:
In Subversion tagging and branching are fundamentally the same, they're both executed as a "copy" command. I'm not sure what the execution time is for these operations in CVS, though I believe it's linear to the size of the repository. In Subversion this is an O(1) operation. While one of the posts commented on tagging being an infrequent operation, this may be true, but why not let it be fast anyways? However, no matter how often you do tags, constant time branching is nice. I can at any time quickly create my own branch of a project to work from. Working in my own branch means that I can keep very granular track of my changes by committing frequently, without worrying about breaking something else. Once I'm satisfied with my changes I can merge my branch with the main code.
Storing Binaries:
"Binaries" does not necessarilly mean compiled code. There are plenty of things that can benefit from this. Anywhere you use graphics: web programming, GUI programming, or say game or other 3D programming andy you want to store your models. Or, you can store documentation in the repository: PDFs, Word docs, spreadsheets, etc.
Finally, the barrier to switching isn't all that high. The command line program has quite similar syntax, so switching is pretty easy, and the other interfaces such as the web viewer, TortoiseCVS, and IDE integrations generally have counterparts for Subversion.
Well, that's all I can think of for now. I'm actually going to try to get my company to switch over to Subversion from a commercial software they were using when we start on our new product. We're using a Java applet to interface with the repository now, and it's not very nice. CVS would work, since the main thing I want is integration with Eclipse and IntelliJ Idea, but there are plugins to support this with Subversion as well. However, Subversion has nice feature CVS doesn't, so I don't see any reason to use CVS over Subversion.
But using a database DOES provide advantages, as stated in the article. Mostly speed advantages, but also the ability to do live backups. If you try backing up an online (as in live) CVS server's files, there's nothing stopping people from doing commits, thus possibly botching your backup (you're no longer backing up the files you thought you were).
And when it comes down to it, backups are really where your safety lies. In the last CVS project I worked on, the repository was hosed twice. Once due to a careless admin, and once due to the hard drive dying. While we had some down time, virtually no work was lost, largely due to our nightly backups. The fact that CVS stored its data as plain text files certainly didn't protect us.
Once a week, a snapshot release is made. That means a tag is added. This operation takes, on average, 40 minutes, because the GCC source tree is large.
Every time someome makes a branch, they create a tag just before branching (for use later on, with diffs and merging). 40 minutes to tag, another 40 minutes to branch.
All because these are, stupidly, O(n) operations instead of O(1). We'd like to move to Subversion, but can't, until they get annotate ('svn blame') fully working, because GCC developers spend a lot of time doing "revision-control archaeology".
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
When you used PostgreSQL, MySQL, or Oracle, does it bother you that your data is in a big database? Why do you worry so much about Subversion then?
A good thing about CVS is that you can see what files and modules are available using regular unix tools, and if things get messed up in some way you can always fall back to the rcs commands or in the worst case edit the ,v file by hand and extract the latest version.
It is a good thing that you were able to hand-edit CVS repositories when they got corrupted -- because corrupt CVS repositories are a dime a dozen.
I've been using Subversion since January 2002 (yes, a full two years before 1.0 came out.) and I have never, ever, ever seen a corrupt repository or heard about one on the mailing lists. When someone did claim that they thought Subversion corrupted their repositories, the Subversion devs dropped everything to make sure this wasn't the case. AFAIK, it has never happened. (Usually it was the person using multiple servers to access their repo or putting their repo on a network share (Berkeley DB doesn't work over NFS/AFS/CIFS.))
Let me quote a Slasdot posting of mine from a couple of years ago:
My opinion has not changed in the past two years.Thomas
Yep, Subversion comes with a conversion script, cvs2svn, which is under very active development right now. It's not quite so wonderful at converting CVS repositories with complicated branches, so you'll want to double-check the conversion, but lots of people are reporting success converting huge multi-gig repositories over to Subversion.
Look here...
--
All extremists should be taken out and shot.