Re: Using Clearcase functionality in CVS

[Paul Sander]

>--- Forwarded mail from address@hidden

>I'm forwarding an email from a coworker who is our configuration manager
>and has a Clearcase background.  We however, use CVS in our office and
>are attempting to implement some Clearcase techniques (features) in
>CVS.  If you can provide any assistance in this area (Used both
>Clearcase and CVS), your input would be greatly appreciated.  The
>following inserted email explains what we are trying to accomplish.

>>"Dennis,
>>
>>I tested out the "cvs checkout -j WMS_1006_RELEASE -j
>>WMS_1020_RELEASE"
>>that we talked about, and cvs did what I expected with some files and
>what I did >NOT
>>expect with others.

>>For instance, with "cmd_ups_31_common_function.pc", I got version 1.70
>of the >file
>>instead of a "merged" version of 1.70.12.1 and 1.70.  So, therefore, I
>got an either >or
>>response from cvs.

Yeah, this is a degenerate case that CVS doesn't handle well.  I consider
this a bug, but I'm sure we could find someone on this list who would
argue otherwise.

>>But, if that makes any sense, this is the definition of what we want
>cvs to do for us,
>>and you can bounce this off the person you have found who has extensive
>cvs and
>>clearcase experience....
>>
>>Here goes...
>>
>>We want to be able to extract from cvs the particular revision of any
>file based on >a set of "rules"(similar to the way config. specs. are
>used in clearcase) which >specify branch/label tags and any other
>criteria which might help identify the >"configuration" of all the files
>that are in cvs which satisfy such "rules".

CVS has no capability that's equivalent to ClearCase' query language.
In fact, the only useful meta-data that CVS keeps are tags (branch and
version tags) and timestamps.  That means you must have a tag for
everything you'll ever want to pull out of CVS, or a branch/timestamp
pair.  And that means that you really have to plan ahead to decide every
purpose for which you'd want to perform a checkout or update and make
sure the proper tags are created correctly.  But that is a clumsy
substitute for attributes that can store values.  And again you can't
query CVS for a complete set of tags that exist in the repository.

In practice, you'll find that applying ClearCase practice to CVS won't
work.  CVS just isn't smart enough to keep up.  So you'll have
to reduce your process to something that CVS can handle, perhaps
supplemented by wrappers or other helpers.

For example, try implementing ClearCase' merge-arrow semantics.  You must
somehow combine a "cvs tag", a "cvs update" with two -j options, the
necessary user edits, a "cvs commit" and another "cvs tag" operation so
that you can track the contributors to the merge and have a smarter
computation of the common ancestor for the next merge.  You can't automate
this in any reasonable way due to the pause to resolve merge conflicts.

Heaven help you if you want an equivalent to UCM.

You could try to somehow meld a relational database with CVS, but
performance would suck and you'd have to maintain it.  Keep in mind
that the break-even point is about 2 or 3 man-weeks of CVS hackery per
ClearCase license (for purchase), then 1-2 days per year per ClearCase
renewal.

>--- End of forwarded message from address@hidden