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."

Comments

Is there demand?

[cookiepus]

I've read the linked article (really!) and I think Subversion sounds like a good idea. Primarily, I like the fact that everything you can do with CVS you can do with Subversion in the same way as with CVS.

I am really curious how much demand there is for Subversion's new features, however.

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.

Also, have there been many problems that required atomic commits? Can someone explain why this is important? I mean, the idea is you'll need to merge one way or another. I can see the point being in that what you commit at any given time will compile (presuming you're commiting completed code) but realistically, does anyone not fix their up-to-date checks as soon as they happen?

Also, Subversions says that it is much faster at things like tagging, but tagging is not a very frequent operation...

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.

Not a flame btw, just an opinion.

Re:Is there demand?

[nosferatu-man]

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

Re:Is there demand?

[aurum42]

I don't know what your development model is, but branching and tagging are often some of the most frequent (and slowest, in CVS) operations.

Many projects follow the "make branch, fix bug in branch, test branch and then merge" cycle, which makes a lot of sense.

Re:Is there demand?

[dietz]

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.

Re:Is there demand?

[Endive4Ever]

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?

All your files are belong to us

[wayne606]

It bothers me a bit that all the files are now in a big database. 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. With a database, if things were to get corrupted enough (I have no evidence that this happens often, but still...) you are stuck. Just like with the windows registry, where if it gets messed up you lose big.

Any opinions on this?

Re:All your files are belong to us

[magnum3065]

Someone else already mentioned the ability for live backups with Subversion. Another benefit of the database is built-in journaling support. BerkelyDB logs any changes before making them, so if your system crashes or something, the DB will be restored to a stable point. This is MORE reliable than what CVS offers, even with a journaling filesystem. Also I'm pretty sure that if you REALLY need to hack the DB, there are utilities that will let you do this. However, most of the scenarios that CVS admins needed to hack the ,v files for are no longer a problem in Subversion.

Re:All your files are belong to us

[nthomas]

It bothers me a bit that all the files are now in a big database.

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:

...there is nothing that the dev team values more than the integrity of your data. Nothing. This means that once something has been comitted, it will never be lost.

My opinion has not changed in the past two years.

Thomas

Re:All your files are belong to us

[empty]

...It is ok until it gets corrupted, and then you are hosed. Keeping everything in readable files CVS-style is a BIG plus point once you've been in that situation...
...I am also wary of database-based products which are tied to one particular database...

Subversion has a utility that might assuage your fears:

svnadmin dump

The dump command can do a (full or incremental) dump of your repository such that you can completely recreate its history. If you use this command for backup, you will be assured that you don't lose any data.

As a bonus, the dump file is human readable, so there should be no fear of losing data to an inscrutable binary file.

Some answers

[magnum3065]

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.

Live backups, baby

[dFaust]

This is a valid point, one that has crossed my mind in the past. But consider how many databases are out there in the world. Many with incomprehensible amounts of data. Given this, stability is obviously a number one priority to users and developers of databases, and certainly something that was considered before the Subversion folks a) chose to use a database backend and b) chose BerkeleyDB. Subversion has been self-hosted (they used Subversion for their source control) for over a year, and have yet to lose any data. While a year isn't that long, it's a start.

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.

Re:Windows server?

[Eneff]

How about individuals wanting source control on their at-home projects? I'm sure not going to spend the money on the MS control, but I don't have a *ix box up 24/7 either. (I use my laptop nearly exclusively, and my laptop hardware supports Windows better.)

Consider GCC

[devphil]

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".

Re:Consider GCC

[nthomas]

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".

Just curious, 'svn blame' was added 2003-10. What about it is not working for you?

Thomas

I've tried both Subversion and Arch

[dozer]

Subversion good points:

• Finger feel is very similar to CVS
• Flexible directory layout & tagging
• Extremely stable development.

Subversion Bad Points:

• Database & log files take up a LOT of space.
• Quite hard to share repositories
• No way to mark your branches (if you accidentally check out the directory containing your branches, you just got 50 gigs of 99.9% identical files...)
• No distributed development
• Pretty weak merging

Arch Good Points:

• Extremely good distributed development
• Super easy to share repositories
• Pretty strong merging.
• Very stable development

Arch Bad Points:

• Forces you to give your projects weird names ("my-project--branch-1--1.1").
• Forces each branch into a different top-level directory in your archive ("my-project--branch-2--1.1").
• Doesn't feel anything like CVS.
• Pretty slow (but they're working on it).
• Somewhat difficult to resolve merge conflicts

I wish I could love Arch because distributed development absolutely rules. I could tolerate its bizarre command set, but I simply won't accept arbitrary (and ugly) constraints on what I name my projects and branches.

Verdict: I'm still using CVS. Subversion is very close to pleasing me enough to switch... I'll probably ditch CVS some time this year.

Re:I've tried both Subversion and Arch

[natmsincome.com]

Some of your Bad points for Subvresion don't sound quite right:

*Quite hard to share repositories

The repositories can be read using any WebDAV complient software. If your talking about on the web the articles says you can use viewcvs as a web interface. If you want poeple to connect to the server then it should be setup by default as it's client server.

*No distributed development

If your talking about multiple servers like bitkeeper then I can't help you *I know nothing* but if your talking about client server then there's a misunderstanding as it's been designed to be client server.

I may have misunderstood what you were saying but the comments were a bit vague.

Binary files

[ggeens]

Do developers out there voice the need to store binaries?

There are definitely reasons for storing binary (non-text) files in a version control system:

• Images: quite obvious. You want to version all your artwork. For web-based projects, this can be a large part of your system.
• External libraries: if you use third-party libraries, it makes sense to store them in the version control system. If you need a particular build, you check out the correct revision. This allows you to build the exact same binary as it was delivered before. (Of course, if you have the sources to the library, you might want to import them into your project. But if you don't change the sources, that might be overkill.)
• Compiled files: some people like to store all object files into version control. Again, this allows you to retrieve a specific version faster (no need to recompile). Personally, I would do this only if the compilation takes too much time.
• Documentation: whether you use MS Office or OpenOffice.org, documentation will be in a binary format. (OOo uses compressed XML.)
• Test data: you might want to version your test cases, and those will consist of binary data.

Re:Windows server?

[spongman]

I'm runing svnserve on a windows box in a production environment and it works great.

If you want to start svnserve as a windows service, google for srvany.exe, it allows you to run a regular win32 exe as a service.

It helps just a little

[r6144]

I have used Subversion in quite a few (small, mostly one-man) research projects during the last six months. Before then I used RCS/CVS. Subversion does make me somewhat more comfortable, and I have little to complain about it, which means I probably won't ever look back.

However, IF there is no free software like Subversion, I'll rather do with CVS than using non-free stuff even if someone else pay the money for me. For example, CVS does not have atomic commits, so I use tags instead (ironic since CVS does tagging quite slowly, but still acceptable for one-man projects). Other weak points of CVS can also be worked around. It isn't pretty, but not THAT painful either. Actually, before I discovered RCS, I just did version control manually by saving a tarball after each day's work, which is tedious but still sufferable.

Of course, for large projects, version control is much more important.

Re:how do you migrate?

[mgm]

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.

Re:how do you migrate?

[Moonbird]

Look here...