migration from CVS to ClearCase
makp
Could you please let me know the procedure to migrate code from CVS
to ClearCase ?
Much thanks,
Madhu Kalirajan
Tgefen
Hi Madhu,
In general - Take your most important labels and import them into
ClearCase.
ClearCase contains a utility for this target. Read here:
http://www.scmlife.com/cf/200306/clearexport_cvs.html
Also, read ClearCase manual: http://www-01.ibm.com/support/docview.wss?uid=swg21239261
Regards,
Tamir Gefen
CM, ALM and IT
GoMidjets - Innovative ClearCase Add-ons
http://GoMidjets.com
marlow...@googlemail.com
Nooooooooooo! You want to migrate from CVS to subversion!!!
I have suffered under clearcase and IMHO the pain is extreme. And for
only one benefit: it's branch management is good. This is because it
supports the idea that a branch is finished once you have merged it
back onto the trunk. AFAIK no other source code control does that. But
it is painful in so many other ways......
-Andrew Marlow
Jorgen Grahn
I use base ClearCase and kind of like it, so it's not as universally
hated as some other tool I'd rather not mention ...
Anyway, I guess Madhu doesn't migrate to ClearCase by choice.
/Jorgen
--
// Jorgen Grahn <grahn@ Ph'nglui mglw'nafh Cthulhu
\X/ snipabacken.se> R'lyeh wgah'nagl fhtagn!
Marc Girod
> I use base ClearCase and kind of like it, so it's not as universally
> hated as some other tool I'd rather not mention ...
I even *love* it (that is, base ClearCase), and I do use
(reluctantly) subversion (for instance).
I would add that it is a misconception that you
should 'merge branches back onto the trunk', and that
ClearCase does *not* support in any way the fact that
the branch would be 'finished' then, whatever this might
mean.
Marc
Jorgen Grahn
Maybe Andrew was referring to UCM or something?
I too reacted on the words "should" and "finished", but I think it's
a valid way of using ClearCase. There may be better ways, but I have
never anything but that way (or more commonly pure unplanned chaos).
Marc Girod
> Maybe Andrew was referring to UCM or something?
I am afraid so...
> I too reacted on the words "should" and "finished", but I think it's
> a valid way of using ClearCase.
I don't.
> There may be better ways, but I have never anything but that way
> (or more commonly pure unplanned chaos).
Well, UCM is planned chaos...
I hope to offer soon a reasonably packaged alternative with:
http://search.cpan.org/perldoc?ClearCase::Wrapper::MGi
Marc
britt.s...@gmail.com
I also really like base ClearCase. I think its a good implementation
of some brilliant concepts. By "finishing" a branch I think he means
setting it to "obsolete" which is sometimes the right thing to do.
I'm distressed a bit that IBM/Irrational doesn't care that they are
losing so many ClearCase customers to clunky, less capable tools like
Subversion.
-Britt
marlow...@googlemail.com
> > I even *love* it (that is, base ClearCase), and I do use
> > (reluctantly) subversion (for instance).
> > I would add that it is a misconception that you
> > should 'merge branches back onto the trunk', and that
> > ClearCase does *not* support in any way the fact that
> > the branch would be 'finished' then, whatever this might
> > mean.
>
> Maybe Andrew was referring to UCM or something?
No, I wasn't. Plain clearcase history graphs will show where a file
has been merged from a branch back onto the trunk.
> /Jorgen
Marc Girod
> No, I wasn't. Plain clearcase history graphs will show where a file
> has been merged from a branch back onto the trunk.
Yes, but if you force delivery by merging back, then
this information is mostly worthless.
Most often it is pure duplication, 'trivial merges'
which hide the data you'd be interested in: real
changes.
Marc
Dee
>
> I hope to offer soon a reasonably packaged alternative with:
>
> http://search.cpan.org/perldoc?ClearCase::Wrapper::MGi
I have been trying to make sense of this, I really have, but it
hasn't been easy. While you criticize "SCM tools" for having
problems that are very specific to ClearCase, you use terminology
and concepts that you do not provide or point out definitions for.
Instead of getting entangled with all that, I decided to take a more
practical approach, and examine what actually happens if I follow
your method.
The first thing I learned is that your method of creating all new
branches from /merge/0 involves a copy-merge from the tip of the old
branch to the new branch. You say you want to avoid trivial merges,
but then you make an equal amount of copy-merges up front. I find it
difficult to see wisdom in that.
More importantly, every time when I actually do need to make a merge
(when I am working in collaboration with other developers and need
to put together changes that we implemented in parallel), using your
method leads to much bigger trouble than it purportedly solves.
Usually, when I need to merge changes together, I run findmerge
command to pick up not only the files that need merging, but also
their common ancestors. However, if everybody uses your method
- if we always branch off from /main/0 - findmerge turns out useless.
Either the only common ancestor that findmerge ever finds is /main/0,
which effectively leaves me with a two-way diff-merge instead of the
three-way diff-merge that I prefer.
Or the attempt to find the common ancestors takes up too much time
because the version tree is a mess - the longer we have applied your
method, the messier it gets.
You won't notice the performance problem as long as you are just
playing with the method in a small sandbox, but as soon as you
join am actual project where changes are made for real, you will
see how findmerge just won't perform anymore.
The grave consequences of messing up with the version tree are
explained for example in
http://www-01.ibm.com/support/docview.wss?uid=swg27018214
("Understanding IBM Rational ClearCase findmerge performance issues
and possible workarounds").
In summary, your method to avoid trivial merges not only fails reduce
unnecessary merges, but in effect turns off the most valuable part of
ClearCase's merge machinery: the quick, automatic method of finding
common ancestors for three-way diff-merge. Paying such a high cost
for no benefit at all makes absolutely no sense to me.
Marc Girod
> The first thing I learned is that your method of creating all new
> branches from /merge/0 involves a copy-merge from the tip of the old
> branch to the new branch.
Note however that this is the same as copying the data to your view:
you do not check in this version. You modify it, and check in the new
version.
The result is that there is no duplication of data.
This 'copy merge' ends up thus not being one in the version tree.
> However, if everybody uses your method
> - if we always branch off from /main/0 - findmerge turns out useless.
Not at all. It can still be used exactly in the same way.
I am afraid you didn't try as you pretend.
> Either the only common ancestor that findmerge ever finds is /main/0,
> which effectively leaves me with a two-way diff-merge instead of the
> three-way diff-merge that I prefer.
You are not clearer than me, I'm afraid.
This doesn't make sense. Note that /main/0 is always a common
ancestor.
> Or the attempt to find the common ancestors takes up too much time
> because the version tree is a mess - the longer we have applied your
> method, the messier it gets.
Define a mess, and provide measurements.
> You won't notice the performance problem as long as you are just
> playing with the method in a small sandbox, but as soon as you
> join am actual project where changes are made for real, you will
> see how findmerge just won't perform anymore.
This is just insulting, and completely incorrect.
> The grave consequences of messing up with the version tree are
> explained for example in http://www-01.ibm.com/support/docview.wss?uid=swg27018214
> ("Understanding IBM Rational ClearCase findmerge performance issues
> and possible workarounds").
The version tree is not complex, just different.
And the number of ancestors to consider does not grow: it stays
incremental.
> In summary, your method to avoid trivial merges not only fails reduce
> unnecessary merges, but in effect turns off the most valuable part of
> ClearCase's merge machinery: the quick, automatic method of finding
> common ancestors for three-way diff-merge. Paying such a high cost
> for no benefit at all makes absolutely no sense to me.
I am afraid you didn't go beyond the surface.
Probably didn't install the wrapper and try it.
What you are showing here are thus only your prejudices.
The most valuable part of ClearCase is winkin, and promotion of
derived objects.
This is what my scheme optimizes.
In the same time, it optimizes the delivery process, restoring its
fairness in presence of MultiSite (which gets broken in delivering by
merging), making it reversible, and removing spurious intermediate
states which serialize the work of different users.
It does has some perfomances penalties, because ClearCase is not
optimized to support it.
But I am not convinced you spot any.
I need to use findmerge far less with this process than with the
traditional deliver by merging one, because I use it only for rebase,
because the configurations are far more stable (less spurious
versions), and because the deliveries can be more frequent and thus
more incremental.
I have not noticed (but not measured) any significant perfomance issue
there.
Marc
Marc Girod
> The grave consequences of messing up with the version tree are
> explained for example inhttp://www-01.ibm.com/support/docview.wss?uid=swg27018214
> ("Understanding IBM Rational ClearCase findmerge performance issues
> and possible workarounds").
This technote doesn't apply at all: on the contrary,
the version trees produced by my branching
system are extremely *simple*, and do not exhibit
the kind of complexity shown in this example,
and which results from UCM delivery by merging!
They may show strange in a GUI lsvtree, but that's
why my wrapper offers a:
ct lsgenealogy
function. Use it with a limited depth, e.g. -d 3, and
see that it will only show you relevant data,
typically only one line of descent of contributors,
even if not all of them on the same branch!
Marc
tumpelo
>
> I have not noticed (but not measured) any significant perfomance issue
> there.
>
To really know about the performance issues, you'd need to have lots
of users doing changes in parallel and then needing to merge. How many
users do you have using the method in the same VOB?
Marc Girod
> To really know about the performance issues, you'd need to have lots
> of users doing changes in parallel and then needing to merge. How many
> users do you have using the method in the same VOB?
Not enough, I fully agree!
I.e. I am alone using it systematically.
Plus a few sporadic users, partly using scripts.
(I have convinced only a couple of people elsewhere,
who are at best in the same case as I am myself).
But I was making no claim, only replying to one (non substantiated).
Note that the technote mentioned earlier is in favor of my system:
there are deep problems with complex branches as used
in traditional (e.g. UCM) branching models.
But there are much more serious problems with them than just
performance!
Marc
Jorgen Grahn
I am puzzled by your discussion of merge performance; on the system I
use (where ClearCase *is* heavily loaded and often painfully slow)
findmerge is quite fast. It always seems as a very cheap operation.
Haven't read the article mentioned upthread though.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
tumpelo
> there are deep problems with complex branches as used
> in traditional (e.g. UCM) branching models.
The problems I have seen with UCM branches stem from base ClearCase
- I have not seen UCM adding any new problems to those that base
ClearCase poses. On the contrary, UCM makes a good compromise.
For one, it doesn't make you create a separate branch for every
change, but allows you to continue on same branch (stream) as long
as you see fit. This is especially important to snapshot view users,
since UCM requires users to create a separate view for each stream.
The biggest branch-related problem I have had in UCM is that of
cascading branches, which cause the internal path name to grow too
long. However, that is purely a base ClearCase problem, and when
you take heed of it, when you plan your branch (stream) hierarchies
to avoid that problem, you'll also avoid the performance problems
that would creep on you if you didn't.
UCM has lots of other performance problems, as well as other kinds
problems, but with branching, I cannot see UCM having any.
Besides, I would not call UCM "traditional". Bae ClearCase is
traditional,
and UCM It was Rational's attempt to bring ClearCase into modern world.
Jorgen Grahn
> On Oct 20, 8:28 pm, Marc Girod <marc.gi...@gmail.com> wrote:
>> there are deep problems with complex branches as used
>> in traditional (e.g. UCM) branching models.
> Besides, I would not call UCM "traditional". Base ClearCase is
> traditional, and UCM It was Rational's attempt to bring
> ClearCase into modern world.
I'm not progressive like Marc, but my understanding of UCM is that it's
ClearCase "dumbed-down" to the level the users were used to from other
tools. (Some would probably say "limited to a sane subset".)
/Jorgen
--
Marc Girod
> For one, it doesn't make you create a separate branch for every
> change, but allows you to continue on same branch (stream) as long
> as you see fit.
The biggest problems are not with branching,
but with merging *back*.
There is only one problem with branching, and you
mentioned it: cascading.
But it doesn't hurt you unconditionally.
Back to it later.
> This is especially important to snapshot view users,
> since UCM requires users to create a separate view for each stream.
You have it backwards: snapshots views are good
for UCM, not UCM for snapshot views.
Rather, UCM jeopardizes the interest of dynamic views
and suffers thus for nothing from their low-level penalty
without getting the high-level benefits they bring.
Now, snapshots views are a dirty hack that was put in
place when laptop became cheaper, and because they
weren't yet powerful enough to run a site of their own
(and MultiSite would not have coped with hundreds of
sites).
Compared to dynamic views, they are a step back 20
years in time!
What is so important with clearmake and dynamic
views, is the stability of the derived objects, which can
be shared, and thus identified, so that you can focus on
the moving parts in your configuration, and you can
compare configurations with a decent signal per noise
ratio.
How does UCM shoot that? By mandating that delivery
happens by merging *back* to integration branches,
thus created lots of duplicates of existing versions (the
ignominous trivial merges: 100% nuisance, even if each
of them is small) and invalidating all the derived objects!
> The biggest branch-related problem I have had in UCM is that of
> cascading branches, which cause the internal path name to grow too
> long.
Agreed, so that under base ClearCase, you can write a
wrapper to avoid it: branch off /main/0 and merge to your
new checked out version before editing it!
Simple and efficient, but impossible under UCM!
> However, that is purely a base ClearCase problem, and when
> you take heed of it, when you plan your branch (stream) hierarchies
> to avoid that problem, you'll also avoid the performance problems
> that would creep on you if you didn't.
The main perfomance problems of UCM are with merging.
> UCM has lots of other performance problems, as well as other kinds
> problems, but with branching, I cannot see UCM having any.
The one I explained above.
And the second with MultiSite: to merge to the integration
stream, you need to master it. This is only possible on one site!
Call a marketing guy: he'll explain you that UCM is good for
centralized organizations!
> Besides, I would not call UCM "traditional". Bae ClearCase is
> traditional, and UCM It was Rational's attempt to bring
> ClearCase into modern world.
And you would be wrong.
UCM froze down a way of thinking which was the state-of-the-art
in 1999.
Nothing prevents one from thinking in base ClearCase!
ClearCase was revolutionary, and is still not understood
today!
The tradition is to consider the development as growing
from the sources, but this is hysterical (wrong spelling)!
This was correct in the 50s, when you had to write your
compiler.
But today, the software comes from packages which you
extract and run. Only very seldom do you look for the
sources in order to fix a bug and submit a patch (sigh!)
With audited config records, you might manage the
products directly!
Test the executable first before you'd decide to 'get' the
changes.
Marc
tumpelo
> On Thu, 2010-10-21, tumpelo wrote:
> > Besides, I would not call UCM "traditional". Base ClearCase is
> > traditional, and UCM It was Rational's attempt to bring
> > ClearCase into modern world.
>
> I'm not progressive like Marc, but my understanding of UCM is that it's
> ClearCase "dumbed-down" to the level the users were used to from other
> tools. (Some would probably say "limited to a sane subset".)
Umh, that's what I get for not being specific enough.
What I mean by "modern world" specifically is that base ClearCase
completely lacks the concept of a configuration that has an evolution
of its own. UCM calls it "component".
You have to have an object to change in order to have meaningful
change management. Without it, change management is built on sand.
Being able to identify individual snapshots of a configuration
(by labeling or some such means) is not enough - configuration
management is about managing the whole life-cycle of a configuration.
This is what people mean when they say that (base) ClearCase is
like RCS, not a configuration management tool at all.
ClearCase was lagging behind the real configuration management tools
for way too long, and when Rational finally took up the effort to
save their face, they came up with quite a contrivance.
I don't know how much UCM features are dictated by the limitations
of ClearCase architecture to begin with, and how much the result
reflects Rational's ill-fated attempt to differentiate from their
competitors by making up concepts of their own.
I just know that UCM is not "dumbed-down" - it is much worse than
that.
Marc Girod
> What I mean by "modern world" specifically is that base ClearCase
> completely lacks the concept of a configuration that has an evolution
> of its own. UCM calls it "component".
I'm sorry but I don't buy that.
I agree that it is important to be able to extract
a sub-structure from a larger configuration, but
forcing you to do it *in advance* is not a progress.
To me, the flexibility offered by identifying a
derived object and its dependencies, and
applying a label to the config record, is much
more valuable than the hard-coding of intentions,
necessarily short-sighted.
There remains an unfortunate dependency on the
(accidental) directory layout, until one refactors it.
Marc
tumpelo
>
> I agree that it is important to be able to extract
> a sub-structure from a larger configuration, but
> forcing you to do it *in advance* is not a progress.
>
>
> There remains an unfortunate dependency on the
> (accidental) directory layout, until one refactors it.
I'm afraid you are confusing the general idea of following the
evolution of a configuration with the specific details of UCM. Yes, it
is idiotic to decide beforehand that the whole history of a file
always belongs to a particular "component". I agree on that. I cannot
see any rational (pun intended) reason why the different versions of a
file - or even the same version of a file - cannot belong to multiple
different "components".
However, almost all SCM tools make a similar mistake, if not in a
strong form then at least in a weak form, under the hood. Even
Mercurial still hangs on the notion of delta files being the best way
to save disk space. I have not studied all possible SCM tools, just
those that I have to take seriously at work, and among them, I know
only two that are poison-free in this regard: Synergy (ex Continuus)
and GIT, which goes even farther than that.
GIT takes a bold leap in admitting the reality instead of forcing you
to pretend that you must and can control all of history. The history
of software has never been a fully connected, consistently recorded
succession of new versions. Software development has always been a
fission-fusion process, where portions of history diverge, separate,
become isolated and sometimes encounter again. GIT fully accepts this
reality, while pretty much all other tools are based on the idea that
what you have ín your repository is the truth, the whole truth and
nothing but the truth. When two separate islands of history have a
rendezvous, you cannot treat the situation straight-forwardly. You
have to pretend that the copy you received from elsewhere is a
subservient part of the history you already have in your repository.
GIT completely liberates us from this nonsense, and allows us to
handle each rendezvouz honestly, take it as what is it, without any
pretense. What a huge relief.
Jorgen Grahn
...
> GIT takes a bold leap in admitting the reality instead of forcing you
> to pretend that you must and can control all of history. The history
> of software has never been a fully connected, consistently recorded
> succession of new versions. Software development has always been a
> fission-fusion process, where portions of history diverge, separate,
> become isolated and sometimes encounter again. GIT fully accepts this
> reality, while pretty much all other tools are based on the idea that
> what you have �n your repository is the truth, the whole truth and
> nothing but the truth.
Sounds good, but when I think about it I can extract no meaning from
your words.
> When two separate islands of history have a
> rendezvous, you cannot treat the situation straight-forwardly. You
> have to pretend that the copy you received from elsewhere is a
> subservient part of the history you already have in your repository.
> GIT completely liberates us from this nonsense, and allows us to
> handle each rendezvouz honestly, take it as what is it, without any
> pretense. What a huge relief.
Doesn't GIT use the diff3 algorithm like everyone else? The diff3
algorithm treats both contributors as equals. Which tools try to
pretend they /aren't/?
Apologies for being skeptical, but I had to listen to the Subversion
propaganda (in the form of badmouthing other tools) for years ...
Dee
>
> Doesn't GIT use the diff3 algorithm like everyone else? The diff3
> algorithm treats both contributors as equals. Which tools try to
> pretend they /aren't/?
You have to take a step back. What happens *before* you can use diff3?
How do you identify the three versions for diff3? That's where the
difference lies.
The two separate islands of history I am talking about are separate in
the sense that you do not aleways have any unambiguously identifiable
common ancestor in either of them. In most SCM tool, if you want to
combine such islands - or parts of them - into one repository, you have
to pretend that one of them existed before, and import content from the
other into a sub-branch, forging timestamsp and whatnot in the process,
depending on the tool. You have to pretend that there is a common
ancestor when there is none.
GIT doesn't pretend. When you have two repositories that hold two
islands of history, and you fetch part of one repository into the other,
GIT does it without pretending that they have a common ancestor. As
result, you will have multiple root versions. If you know there is a
version that can be fairly comfortably be used as a common ancestor for
running diff3, you have to hand-pick that version for diff3. It's you
pretending, not GIT. You can decide to do it because you need it, but
GIT doesn't *force* you to pretend. That's my point.
However, multi-root histories is not the only feature that is required
for honesty. Another noteworthy deatil is that GIT identifies all
objects by their SHA1 signatures. This means that a version identifier
in GIT doesn't depend on how the previous version was identified, or
even which repository it resides in. It doesn't depend on timestamps or
the name of the object or any other metadata. It only depends on the
content of the version.
> Apologies for being skeptical, but I had to listen to the Subversion
> propaganda (in the form of badmouthing other tools) for years ...
It's time to get over with Subversion. That whole era is gone, now that
we have the new generation of SCM tools that calls itself "DVCS",
Distributed Version Control Systems.
Marc Girod
Jorgen Grahn
> 9.11.2010 15:28, Jorgen Grahn kirjoitti:
>> Apologies for being skeptical, but I had to listen to the Subversion
>> propaganda (in the form of badmouthing other tools) for years ...
>
> It's time to get over with Subversion. That whole era is gone, now that
> we have the new generation of SCM tools that calls itself "DVCS",
> Distributed Version Control Systems.
That's precisely the kind of statement that worries me[1]. The SVN people
used to declare victory too, and to me it always sounded like a FUD
operation.
If we were entering a New Era, I'd want it to be the era of version
control. /Any/ kind of version control. Most non-programmers (most
data generated) are stuck in a pre-CVS world where they cannot
retrieve past revisions, or collaborate freely with others.
Marc Girod
> That's precisely the kind of statement that worries me[1]. The SVN people
> used to declare victory too, and to me it always sounded like a FUD
> operation.
And they were not the first.
In fact, if there is one thing constant which everybody
agrees upon in all these revolutions, it is that everything
was wrong so far but now, at last, we'll do it right now.
'There is one thing history teaches us, and it is that it
teaches us nothing.'
> If we were entering a New Era, I'd want it to be the era of version
> control. /Any/ kind of version control. Most non-programmers (most
> data generated) are stuck in a pre-CVS world where they cannot
> retrieve past revisions, or collaborate freely with others.
I am guilty too of wishing to enter an new era, and no,
it is not of version control. On the contrary, it would be
of software management (quite the opposite in fact).
By management, I do not mean managers, of course.
Managers, precisely, want to control.
To me, management should mean continuity.
It should first be non-invasive, i.e. be able to make sense
of what was done, instead of of mandating what to do.
Pulling on this thread, an SCM tool ought to build up
some kind of generic structure between nodes it would
identify.
The closest thing I have met is clearmake, but I am
interested in exporting the ideas, thus e.g. in Audited
Objects (http://sourceforge.net/projects/audited-objects/)
and why not, on pluging these into git, or on top of git.
Marc
Jorgen Grahn
> On Nov 15, 10:11 pm, Jorgen Grahn <grahn+n...@snipabacken.se> wrote:
>
>> That's precisely the kind of statement that worries me[1]. The SVN people
>> used to declare victory too, and to me it always sounded like a FUD
>> operation.
>
> And they were not the first.
> In fact, if there is one thing constant which everybody
> agrees upon in all these revolutions, it is that everything
> was wrong so far but now, at last, we'll do it right now.
Yeah, but it's unusually strong in this area.
Like in this article from yesterday:
An-Illustrated-Version-Control-Timeline
http://developers.slashdot.org/story/10/11/17/1537247/
Marc Girod
> Yeah, but it's unusually strong in this area.
> Like in this article from yesterday:
>
> An-Illustrated-Version-Control-Timeline
> http://developers.slashdot.org/story/10/11/17/1537247/
Yes... somewhere between sad and funny...
We are in a postmodern world, on which reality
is made of the perception one has of it.
That's what drives Pablo (a very nice guy, btw):
he tries hard to make self-fulfilling prophecies.
Such catalogs, the mere idea that complex
tools might be compared on a better-worse
scale, matrices of checkboxes (e.g. support for
branches: X | O), disclose a reductionism
characteristic of 'modern' thinking.
Marc