Comments on: The hell of CVS

By: strik

strik — Fri, 23 Jun 2006 07:51:12 +0000

@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).

By: Wayne Schroeder

Wayne Schroeder — Thu, 22 Jun 2006 19:45:25 +0000

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.

By: Michael Kohne

Michael Kohne — Thu, 22 Jun 2006 00:13:27 +0000

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!

By: Jeff Outlaw

Jeff Outlaw — Wed, 21 Jun 2006 21:12:59 +0000

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.

By: dispensa

dispensa — Wed, 21 Jun 2006 19:30:22 +0000

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.

By: -

Wed, 21 Jun 2006 19:23:05 +0000

git is quite good WRT performance (at least on native linux, that is)

By: Kevin Eshbach

Kevin Eshbach — Wed, 21 Jun 2006 17:53:48 +0000

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.

By: dispensa

dispensa — Wed, 21 Jun 2006 16:15:54 +0000

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?

By: Kevin Eshbach

Kevin Eshbach — Wed, 21 Jun 2006 14:09:20 +0000

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.

By: strik

strik — Wed, 21 Jun 2006 07:11:55 +0000

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.