[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Using Clearcase functionality in CVS
Re: Using Clearcase functionality in CVS
Thu, 3 Oct 2002 18:00:36 -0700
>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.
If merge-arrow semantics are what I think they are, I have almost completed
a pair of ant tasks that do it.
Unfortunately time is getting short and I don't know when I will get around
to finishing them. What my ant tasks
attempt to do is merge N number of source trees from external version
control systems onto the main branch.
This means doing the most sensible thing regarding files deleted on one
vendor branch but not another, as well as
making human intervention to solve real merge conflict straightforward and
painless. As the above writter suggests I
do have to make lots of symbolic tags to persist the state of what my ant
tasks have done to the CVS repository.
Is this roughly the same as "merge-arrow" semantics?
P.S.: If anyone else has time to work on this I will be happy to send them
what I have so far. Everything so far has decent unit tests.
James Lee Carpenter
Household Technical Services
6602 Convoy Court
San Diego, CA 92111
address@hidden To: address@hidden,
(Paul Sander) cc: address@hidden
Sent by: Subject: Re: Using
Clearcase functionality in CVS
09/30/2002 02:35 AM
>--- 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.
>>I tested out the "cvs checkout -j WMS_1006_RELEASE -j
>>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 220.127.116.11 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
>>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
>>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
>--- End of forwarded message from address@hidden
Info-cvs mailing list