Conversion from ClearCase to Synergy?
dee
right keywords. Does anyone know of a tool set for conversion between
ClearCase and Synergy? From ClearCase to Synergy, in particular?
Dee
Stephen
"dee" <dear...@luukku.com> wrote in message
news:1236867140.584522@vanews01...
>I tried to look up stuff from Internet, but could not figure out the right
>keywords. Does anyone know of a tool set for conversion between ClearCase
>and Synergy? From ClearCase to Synergy, in particular?
they should have something (they dud when they were Telelogic).
If you want to script your own then Tailor might be a good starting point.
http://wiki.darcs.net/DarcsWiki/Tailor
dee
> I don't know of an open tool for this. Talk to IBM professional services -
> they should have something (they dud when they were Telelogic).
of any such tools or solutions.
What I need is a solution for one-directional continuous (=repeated)
updates from CC to Synergy, between two companies. Since ClearCase usage
models vary a lot, I do not expect to find a single solution that works
for all cases, but somehow I did expect to find at least something -- in
a narrow, single-usage-model sense.
Yes, I keep telling my managers it isn't quite as simple as they think
("look for an application independent data transfer method, please"),
but well, you know the drill...
Jorgen Grahn
How about good old-fashioned patches?
- The CC people develop linearly and produce labeled releases
A, B, C, D ... regularly.
- When C comes, you use CC and GNU diff to generate a patch file
B-to-C.patch. Preferrably you also ship a file with all checkin
comments or some other description of the changes.
- The Synergy people have a "from CC" branch (a "vendor branch" in CVS
terminology). It currently contains B. They apply the patch, and
then it contains C.
- The Synergy people merge from the "from CC" branch to where they
do their actual work.
- And now everyone has C.
Yes, it's crude.
/Jorgen
--
// Jorgen Grahn <grahn@ Ph'nglui mglw'nafh Cthulhu
\X/ snipabacken.se> R'lyeh wgah'nagl fhtagn!
dee
>
> How about good old-fashioned patches?
It's funny how people (mostly in my own organization) keep giving advice
on the trivial part of the problem, ignoring the actual job.
ClearCase and Synergy are both versatile, complex products, and
especially ClearCase allows/enables/encourages/forces/intimidates users
to develop usage models that are not compatible with each other. In
order to find the history data from ClearCase, you first have to decide
what you are looking for. You have to decide what to pick up (VOBs,
labels, branches) and what to leave behind (unlabeled versions, UCM
data, or some such). You have to decide if you can survive with one
"generic" ClearCase view or if you need different views for different
portions of retrieval. You have to decide the timing of retrieval
batches. And so on.
If the company in question happens to have several different usage
models in use, you have to create a tailored retrieval method for each
of those usage models. This is the hardest part of the task. To pipeline
the retrieved data into Synergy is much simpler, because you'll only
have one usage model to serve at the receiving end.
I do not see any room for patches here. What I get from ClearCase is
files and metadata. What I put into Synergy is files and metadata.
Patching in between only creates an unnecessary layer, without solving
any problem.
Jorgen Grahn
Ok. It wasn't 100% clear from your first postings, so I thought I'd
slip in that suggestion to see if it fit. I take it it didn't ;-)
Unfortunately, that's the only thing I can suggest. Around here, no
data ever leaves ClearCase.
Marc Girod
> In order to find the history data from ClearCase, you first have to
> decide what you are looking for. You have to decide what to pick up
> (VOBs, labels, branches) and what to leave behind (unlabeled
> versions, UCM data, or some such). You have to decide if you can
> survive with one "generic" ClearCase view or if you need different
> views for different portions of retrieval. You have to decide the timing
> of retrieval batches. And so on.
Congratulations for your description of the problem.
Indeed, this is why ClearCase developers designed MultiSite.
What is needed is an open standard of this kind.
Each exporting product taking care of serializing the exports,
each importing product taking care of picking up what it can
gasp (note how ClearCase picks some data in the packets
and throw some other away, e.g. in relation with the -preserve
model of the local replica)
Both products maintaining epoch numbers (high-water marks).
Of course, the current MultiSite model which forces to explicitly
know every other replica is unbearable in the long range.
So, my advice would be to parse the MultiSite packets...
That's work, I guess. And building on sand, as everything
may change without notice.
Marc
dee
>
> Congratulations for your description of the problem.
> Indeed, this is why ClearCase developers designed MultiSite.
> What is needed is an open standard of this kind.
>
> So, my advice would be to parse the MultiSite packets...
Did you know that the replication packets both in Synergy and ClearCase
are created in XML format?
Anyhow, as http://www-01.ibm.com/support/docview.wss?uid=swg21134582
states, the architectural difference between the two products are is too
grave. There is no way to map ClearCase and Synergy concepts in such a
straightforward manner. Even without that reference, I happen to know
enough of the both sides to know there is no possibility for these two
to find a way to standardize their replication packets in such a way
that they could be interchangeable between the two products. Just no
way. The only option really is to pull out the data using the
command-line interface and store the data using the command-line interface.
I was just hoping that someone had done it in some particular case, for
some particular usage model, in a way that would be shareable, so I
wouldn't need to start from scratch.
Marc Girod
> Did you know that the replication packets both in Synergy and ClearCase
> are created in XML format?
I obviously did not know.
Thanks for pointing this out.
I assume the schema are not available, though?
> The only option really is to pull out the data using the
> command-line interface and store the data using the command-line interface.
This surprises me, but I have to take your word.
There must be a breakeven point: parsing the command
line is easier in the context of radical simplifying
decisions as you described. But obviously, it would
eventually soon become more complex, if one tried to
lift the restrictions gradually.
Good luck.
Marc
dee
> On Mar 20, 10:55 am, dee <dear.r...@luukku.com> wrote:
>
>> Did you know that the replication packets both in Synergy and ClearCase
>> are created in XML format?
>
> I obviously did not know.
> Thanks for pointing this out.
> I assume the schema are not available, though?
Now, I have to admit I cannot remember the source for the CC part of the
claim, but I do distinctly remember a Telelogic representative telling
me some few years ago that their DCM uses XML format.
Regarding ClearCase MultiSite, this is the closest I can come up with
right now:
https://publib.boulder.ibm.com/infocenter/cchelp/v7r1m0/topic/com.ibm.rational.clearcase.cc_ms_admin.doc/c_firewall_issues.htm
(see "Packets are susceptible to snooping.")
I have no idea of what IBM regards as the most severe architectural
incompatibilities, but it's easy to list some obvious ones:
- in ClearCase, every element belongs to a particular VOB, and with UCM,
to a particular UCM component; Synergy has one undivided database
- in Synergy, every version belongs to some configuration (project
version); in ClearCase, UCM baselines somehow correspond to this idea
(as versions of a UCM component)
- but then, every element in a UCM component can only be members of that
component, whereas in Synergy, different (or even same?) versions of a
file system object can belong to different projects at the same time!
- UCM activities and Synergy tasks are kind of close but not exactly
equivalent
- ClearCase uses 0-versions and they can be labeled etc. - no such beast
exists in Synergy
- ClearCase (MultiSite) always replicates all of a VOB; Synergy (DCM)
only replicates the objects that have been selected for replication (and
I suspect that it is rather rare to replicate all of a database in any
manner close to what CC MS does)
These are the details I can quickly shake out of my sleeve, but I have
probably missed some just as obvious ones. I am sure there are even more
profound differences under the hood.
Marc Girod
> These are the details I can quickly shake out of my sleeve
Again, excellent presentation.
I surely don't underestimate the difficulty of the task.
My only point was that if one intended to work at
a bridge between different products, ultimately one
would rather deal with the native events than with
their consequences in resulting file system images
(snapshots of any kind).
One might have to design patterns for the
conversions, e.g. to build intermediate objects for
the purpose of sharing them, or whatever.
The kind of stuff a compiler does when it produces
binary code for a given architecture.
Marc
dee
>
> My only point was that if one intended to work at
> a bridge between different products, ultimately one
> would rather deal with the native events than with
> their consequences in resulting file system images
> (snapshots of any kind).
While writing my initial list of incompatibilities, I had mainly the
CC-to-Synergy direction in mind. Now that I have also thought of the
opposite, the one IBM has denounced impossible, I have to continue a bit
further.
I already mentioned that in Synergy, every file (or directory) version
always belongs to a project version. I also said that the closest match
to Synergy projects and versions in ClearCase is UCM components and
baselines. Pretty good match, but I forgot to mention is that Synergy
allows projects to be nested along with a directory structure, whereas
ClearCase does not. In base ClearCase, on the other hand, you only have
labels, and no guarantee that users have followed a labelling scheme
that translates to the kind of consistent trail of events that UCM
component baselines do.
In ClearCase, the corresponding basic principle is that every file (or
directory) version belongs to a named branch, an instance of a branch
type. Synergy has no such notion, provides no way to name branches. Sure
enough, Synergy users keep talking about named branches, in a way that
resembles the ClearCase branch types, but that is all based on an
agreement among users, not something supported by Synergy. Since the
branching scheme depends on a naming standard (of project versions), you
again have no guarantee that users have followed the agreed standard
consistently, or that the standard hasn't changed over time.
To transfer history form ClearCase to Synergy, you have to be able to
select configurations that can be converted into project versions, and
you may have to make up some missing parts of the project version
hierarchy as you go. However, to automate the selection of
configurations (and anything that follows), you have to be sure that
users either have used UCM or that they have followed a usage model just
as strict as UCM.
To transfer history from Synergy to ClearCase, you face a similar
problem. Only this time, you have to make up the branch types as you go,
and to automate this process, you have to rely on a very strict usage
model on Synergy side. Without that strict usage model, you have to make
each branch type decision case by case. Frankly, I find it hard to
imagine that such a strict usage model is easy to find in real world.
Of course, in lack of a strict usage model that gives you a clear
branching pattern, you could consider a brute force option, and create a
new branch type in ClearCase for every project version in Synergy --
just imagine the number of 0-versions that you'd get that way.
So in either direction, you have to rely on a usage model so strict that
it doesn't seem realistic. The only setup I could imagine being
implemented in a fully automized manner, without having to tailor it for
a particular organization, is the transfer from UCM to Synergy, and even
that is far from a perfect match.
To summarize, even if we forget the exterior differences, such as
multiple VOBs vs. single database, the difference in replication
methods, and the un-nesting of UCM components, the ultimate difference
in the architectures (or "native events" as you chose to put it, Marc)
is that ClearCase requires all versions to be on a named branch, whereas
Synergy requires all versions to belong to a named project version, and
these two concepts are orthogonal to each other. In order to transfer
versions from one tool to the other, you have to be able to satisfy the
receiving tool's orthogonal requirement, and you can achieve that only
if the users of the first tool have followed a very strict usage model
that satisfies the both requirements. Not very likely.
It is possible in some limited cases, but not in the general case.
Marc Girod
> To summarize, [...]
> these two concepts are orthogonal to each other.
As previously, you put it in a very clear and convincing way.
I'll love to quote you when I try to explain that there are no
(well, not many, in practice) tool independent SCM patterns,
and that arguments and comparaisons based on such
assumptions (and *there* are many) are most often just
incompetent and naive bullshit.
> In order to transfer
> versions from one tool to the other, you have to be able to satisfy the
> receiving tool's orthogonal requirement, and you can achieve that only
> if the users of the first tool have followed a very strict usage model
> that satisfies the both requirements. Not very likely.
However, I'll stay on my idea that whereas you are
describing a challenge, you are not proving it is impossible.
For sure, one should *not* depend on use patterns, but as
I wrote, on 'native events and objects'.
I wrote of 'intermediate representations' (think again of
compiler technology, of back-end/front-end distinctions),
and cannot see why one could not create counterparts for
whatever is found in either context.
I have in my mind the example of the translation of C++
programs to C (which admittedly proved to have weaknesses,
when it came to exceptions, templates, and virtual multiple
inheritance...).
Maybe it is impossible. I only do not see it yet fully.
And I don't intend to take the challenge myself now.
Thanks!
Marc
dee
>
> However, I'll stay on my idea that whereas you are
> describing a challenge, you are not proving it is impossible.
I am not trying to prove something. Rather, I am recording my learning path.
> For sure, one should *not* depend on use patterns, but as
> I wrote, on 'native events and objects'.
You make "one should *not* depend" sound like deus-ex-machina, a divine
intervention that sweeps all obstacles away.
> I wrote of 'intermediate representations' (think again of
> compiler technology, of back-end/front-end distinctions),
> and cannot see why one could not create counterparts for
> whatever is found in either context.
In order to build up those intermediate representations, you must have
the necessary information available. Some of it you get from the "native
events and objects", but not all of it. Some of the information you need
can only be explored through semantic analysis in a context larger than
the tool (again, UCM might make an exception).
Base ClearCase does not require users to connect labels (label types)
with information that would denote any evolutionary path between the
configurations that the labels represent. The most usual way to denote
these relationships is to use a naming standard for labels, but such a
naming standard is something we do behind ClearCase's back, without
ClearCase knowing about it. And even if we use some more explicit method
(attributes or such), it is still somethign of our own interpretation of
the data, not something in the realm of the "native events and objects".
In order to transfer configurations from CC to Synergy, you have build
up their evolutionary relationships as you go; this is a fundamental
requirement you cannot circumvent. But since you cannot find or derive
these relationships from ClearCase directly, the "native events and
objects" alone are not enough. You have to combine them with the
semantic information that you derive from elsewhere. Usage model is the
name I gave to that external context. You may want to call it something
else, but you won't find it from the "native events and objects".
Marc Girod
> You make "one should *not* depend" sound like deus-ex-machina, a divine
> intervention that sweeps all obstacles away.
A strategy, a choice...
> Some of the information you need
> can only be explored through semantic analysis in a context larger than
> the tool (again, UCM might make an exception).
This, one should drop.
No mind reading.
This is again a very typical case in the compiler analogy.
What is not encoded cannot be garanteed to be retained.
> The most usual way to denote
> these relationships is to use a naming standard for labels
Call that bad practice.
Bjarne Stroustrup had a motto: Tell it to your compiler.
There is no information in a name. The only use for names
is discrimination, in a context.
> a naming standard is something we do behind ClearCase's back
Absolutely.
Therefore it doesn't exist.
> this is a fundamental
> requirement you cannot circumvent.
Indeed. But you can throw it away.
There are no miracles: I agree with that.
A compiler is not expected to produce working programs
out of bad source code.
Marc
dee
>
>> Some of the information you need
>> can only be explored through semantic analysis in a context larger than
>> the tool (again, UCM might make an exception).
>
> This, one should drop.
> No mind reading.
And without that "mind reading", there is no way to do the transfer
between the tools.
> What is not encoded cannot be garanteed to be retained.
Exactly. Nothing can be transferred, then.
>> The most usual way to denote
>> these relationships is to use a naming standard for labels
>
> Call that bad practice.
If it is the practice, then it is all you have. And if the standard, as
it has been practiced for who knows how many years, gives you only
pieces of the evolution history of the configurations, you can transfer
only the pieces you can identify, if even that. If the pieces are too
patchy to form a consistent evolution, there is not way to make the
transfer. Simple as that.
Remember, I am talking about transferring existing history. I am not
talking about starting afresh with ClearCase and Synergy, and setting up
the context for transfers. I am talking about an environment that
already has accumulated history.
Marc Girod
> If it is the practice, then it is all you have.
OK. I think that we'll end up in understanding,
and agreement.
You don't get a unix port if the sources are only hello.c.
Even if the designers meant it, and talked of it in
meetings for 10 years.
But I would not conclude from that, that where there is
information in the system, it ought not be possible on
principle to transfer it.
In ClearCase, most of it would be in config records of
derived objects. Some in hyperlinks between label
types.
Mostly relations building up a structure.
Marc