I’m a big CVS fan. Well, I was. Then, yesterday, I merged a very large set of changes associated with upgrading some parts of our build system from HEAD to our mainline stable branch.
The first problem I had was the common one: I touched a lot of files across a long time, so the traditional tag-to-tag merge wouldn’t have worked. So I closed my eyes and held on tight and just let CVS re-merge everything. I ran cvs update to see what fun awaited me, and got a healthy but not overwhelming number of conflicts. A good many of them were the standard re-merge conflicts for which CVS is so (in)famous. OK, fine, resolved, committed.
Then I went through and built it. Bang, build error. I fixed a few obvious merge bugs, and then I got to a file that was missing a change from HEAD. So: delete file, update to stable, merge from head. NO CHANGES.
I updated to HEAD to be sure I wasn’t losing my mind. The build fix was there. Updated to stable again. Gone. Merge from head: nothing. I finally manually cvs diff’d the head revision (by number) with the stable revision (by number), and voila, out comes a diff! I grumble some more, output the diff to a patch, run the patch utility, and commit the change. Build works again.
I’ve had it. It’s one thing to commit a Type II error by double-merging and conflicting – at least I know for sure what’s going on. But to fail to detect a change and falsely report the same – that is unacceptable and scares the hell out of me. I’ve been using CVS professionally for over a decade; at this point, I give myself credit for understanding the basics. If I’m doing something wrong, it’s non-obvious.
So, I’m switching. This is ridiculous. I’m looking at (in probability order) SVK, Perforce, Subversion, and maybe darcs, arch, and (longshot) git. With a codebase our size, we need intelligent merging in a bad way, and perf is a concern. Anyone have any thoughts on any of these? Is SVK mature enough for serious commercial use? Or should I just bite the bullet and go to Perforce?
Just to be sure: Which version of CVS do you use? The “CVS Home” (http://www.cvshome.org/) version, or the “CVSNT” version (http://www.cvsnt.org/)? (Both on client and server) Which is the version number? (You might want to try “cvs version” for this)?
Have you checked that this is not a known error in some older release of that software?
I’ll forward this link to the cvs-info mailing list. Perhaps, someone will come up with a valuable comment.
- Spiro.
I’m using cvs, not cvsnt. I have 1.11.20 and 1.12.9 in use, but I’m not sure which I was using at the time (one is on my mac and one is on my dev server). I don’t have the repro any more so I can’t imagine that my case will be very helpful for them from a bugfixing standpoint. Besides, I feel sure that I’ve just stumbled on an odd but expected case.
My beef with CVS isn’t that it’s buggy per se; it’s that it has lots of odd but expected cases.
Hello again,
yes, it seems you’re right, this is an expected case. I got the following answer on the CVS mailing list:
“The phenomenon described by the blogger is typical of a situation where
the common ancestor is not identified correctly. What happens is that
there’s the “real” common ancestor, and the (incorrect) version that
the user identifies as the common ancestor. During a 3-way merge, the
difference between the “real” common ancestor and the user’s
specification is lost. If you do the math, what happens is that the
delta between the user’s specification and the top of its branch is
applied to the target branch. That delta does not include the
difference between the specified ancestor and the real one. Hence, it
is lost.
So, it’s important to tag the committed result of every merge, avoiding
race conditions (i.e. use “cvs tag” on the workspace from which the
merge was committed, not “cvs rtag”), and use that tag as the ancestor
for the next merge. This is explained somewhere in the documentation.”
Now I remember again *why* I am always tagging the point where I merged before.
- Spiro.
We use Perforce at work (we needed a CM tool that was cross-platform.) and I have nothing but praise for it. It really is a nice product. (Though my only biggest nit is why the architecture is such that one user can lock down the whole database preventing other users from doing anything when submitting a large batch of changes. Shouldn’t it operate like a database and only lock down the relevant pages versus the whole table?) I have never used CVS so I cannot honestly say if one is better than the other.
That adds to my suspicion that nobody has anything seriously bad to say about Perforce.
I thought I read somewhere that Microsoft started NT development on Perforce and eventually switched to source depot. I don’t remember why that was; anyone?
I thought I read somewhere that Microsoft uses a customized version of Perforce called Source Depot. I could have swore it was part of some PowerPoint presentation given at some conference. I am googling for it, but not having much luck finding the article.
git is quite good WRT performance (at least on native linux, that is)
My only concern with git (and arch and darcs) is that we’re set up around a centralized dev environment here, in the CVS style. It optimizes a set of issues that aren’t precisely the ones that pain me the most.
The things I need most are intelligent merging and the ability to handle a large repository well. Ideally, it wouldn’t be a total shock to the system for our developers, either.
At Reuters where I work we are converting from SourceSafe to Subversion. While I am by no means an expert I like it alot. From co-workers who have used CVS in the past they seem to be able to grasp it pretty quickly. On the negative side, two issues. One this is a hosted solution so beware that there is a possibility of someone else “eyeing” your code. Two, while I know for a fact that you guys are NOT using VMS our current version of Subversion and Tortoise SVN do NOT support VMS. We have even had difficulty getting it play well with Pathworks.
On the Windows and Linux side of things it works great.
One thing to note: Microsoft’s Source Server (the source code equivalent to a symbol server) presently on has support for SourceSafe, Perforce and Subversion. If you think you might want to fool with a source server, you’ll have to consider that in your deliberations.
I can recommend Seapine’s Surround SCM, for at least mid-size projects (that’s all we do, nothing really huge). It’s multi-platform, and it generally just works.
I love CVS, but I have to say that I wouldn’t choose it anymore. It’s file based nature and the fact that it can’t remember the base of a branch on it’s own just seem too limiting to me. I want to be able to rename and move files without loss of history, and I sure don’t want to have to remember to tag branch bases myself (I’m bad at remembering to do extra stuff).
Good luck!
So basically, it was pilot error. I’ve never experienced a cvs merge error when following one simple rule: When you merge branch A into brach B, when done, go back to branch A and make a tag that denotes the last place you merged it into branch B. Then, the next time you need to merge the new changes in branch A into branch B, you can update to branch B, then cvs update -P -d -j A_merge_B -j A, and all will be quite happy. Of course, after this merge, you need to go to your A checkout and tag it again (perhaps with a new tag or -F) to denote a new merge point FROM branch A into branch B. Rinse, repeat.
@Michael Kohne:
The Source Server from MS has support for CVS, at least for some beta-testers. I am using it with success.
Of course, for CVS users, going to SVN might be the easiest path, as SVN is very similar to CVS in its usage (I am speaking about command-line here, I don’t use anything else for it).