I consider Subversion has these major advantages over CVS:

• Since it is the new kid on the block there are more interests to maintain and develop it, and also there are a lot more 3rd party client tools.
• Completely designed to be suitable for all file types. CVS was originally designed for text files only so there are some limitations or hurdles when you store binary or unicode files.
• Renaming a file or directory is as easy as just “renaming” it. In CVS, you have to delete, add with new name and commit. For a developer like me who can’t make up my mind when naming files and directories, this one is a keeper.
• More ways to access repository. From native svn server to ssh and http(s), subversion has more ways to connect to, and therefore, more ways to bypass a firewall that blocks certain ports.
• More clients available. Have I mentioned this in the first point? During my years of using CVS I only managed to find two legit GUI client: TortoiseCVS and WinCVS, other than the command line and IDE plugin. Subversion has a lot more in this department.
• Some other pros like atomic commit and directory versioning are also good but kind of trivial for me.

Now one biggest “con”, considered by some, is the absence of “tagging” capability in Subversion. CVS lets you “tag” a label on a file, so you can create a “snapshot” on a repository. If  you use tag to mark the latest production release (and move the tag accordingly) in CVS you’ll miss this functionality. But in my opinion this is just one way to use source control and this shouldn’t be considered a disadvantage in Subversion. In this example, a production release branch can always be created with the release number, which I consider a cleaner way than using a tag. Ultimately everyone has a different way to use a source/version control tool and I think it is a good design point for Subversion to abandon tag. Although I have used “tagging” before in CVS it is not a heart breaker for me to lose it.

There is one thing I do miss is that not being able to hack into local working copy and change repository locations. I used to write a script which search for CVS/Root and CVS/Repository folder and modify the repository name and server/path when I move my CVS repository from one server to another. Now it seems I have to do a fresh checkout in similar situation in Subversion. Which is probably not a bid deal.

All in all I’m pretty happy with the move. My Subversion client is TortoiseSVN, using cygwin ssh to connect to repository through svn+ssh.

During the research I also found Git and plenty of Git vs. Subversion comparison discussion. From what I understand Git facilitates a heavy local work copy so you don’t have to connect to a central repository server, a so-called “distributed source control system”. I can see this feature is extremely useful for projects with a lot of developer and active branches, because the collaborations can happen among the “local copies”.

Any tips on using Subversion? Please share them here. As a new Subversion converter anything will be helpful.

…move away the file mydir/myfile, it is in the way.

The file was checked in fine and the problem goes away if I try to run update in the directory where the file is located.

Usually deleting the whole “mydir” and do a fresh update will fix the problem, but what causes this?

One possible reason is that the directory name was not properly updated in CVS. This can be verified by going to the parent dire of “mydir”, and open the entries file in the CVS folder. It should include this line:

D/mydir////

If it’s not there, adding line to the file can probably fix the issue above.

But what caused the missing directory name then? Beats me. My best guess in my case is that the failed style checking when checking in CVS files has caused some inconsistency in the sandbox, thus the error.

%cvs upd -jBUGGY_BRANCH

A HEAD can be merged into a branch too using the same method.

To search for the conflict, from the command line, run:

%grep -r “>>>>>” *

The result should be a list of files which have the “>>>>>” content. Most likely, indicating the CVS conflict.

%export CVSROOT=/home/user/cvs

%cvs init

or, if multiple ROOTs are kept,

%cvs -d /home/user/cvs/project1cvs init

create a source directory just like any normal unix directory, then we can do

%cvs add hello.php

After satisfied with hello.php,

%cvs commit

will check in the file for real.

find . -name CVS -exec rm -rf {} \;

Basically a “find” command can be concatenated with other commands so the same operation can be applied recursively to all the found results.

Since this is a Unix command Cygwin is required to run it on Windows.