Clearcase

[Dirk Heinrichs]

Am 15.01.2015 um 17:54 schrieb Angel Ezquerra:
> If CC is slow perhaps you did not spend a ridiculous amount of money
> in infrastructure and support, or you did and even then it is still slow.

Yes, you need to spend money, I think we already agreed on this.
However, if you spend it right, you get a fast CC setup that pays back
in the long run.

> Also, I question what you call "really fast". Does it compare to the
> performance of any decent DVCS?

As fast as file access via NFS can be. And if I look at the Mercurial
clone time on Windows. That's a nightmare. Five times slower than on
Linux and this only after heavy tuning.

> It is definitely outdated IMHO. All popular SCMs developed in the last
> 10 years (or more) have moved away from the per-element checkout and
> into a changeset based revision model. And god forbid you forget to
> checkout a file that you want to modify. If you don't you get exposed
> to the concept of hijacked files.

Ah, I see your problem. You've only used CC with snapshot views. You
don't get hijacked files in dynamic views. That's the point where I
fully agree with you. If you don't use dynamic views, you'll never be
able to use CCs capabilities. In this case you're completely right, it
aint any better than subversion.

>>     to its incredibly clunky windows client,
>     Matter of taste, I guess.
>
>
> I never saw anyone praise the clear-case client in any way. Maybe I
> can no longer say that?

I didn't praise it. Just said it's a matter of taste.

> The Clear-Case GUI looks old and ugly and has not seen a significant
> change in years (possibly in decades).

Yes, that's right. So what?

> Doing anything remotely complicated through it is most often an
> exercise in frustration (e.g. creating a new view for instance takes
> an incredible amount of clicks, or dealing with hijacked files, ugh!,
> or comparing changesets (if you use UCM) or any non single file
> comparision is a pain, etc).

I used the command line most of the time. Never had to deal with
hijacked files, due to exclusive use of dynamic views.

>>     to how hard it makes it to go back to older versions of your
>>     source code,
>     Huh? Change a label in your configspec, ready.
>
>  
> Not if you use UCM. Also, you may be able to go back, but branching
> from there is not that easy (it may even be impossible depinding on
> your server configuration).

That's complete nonsense. You can branch from any point in history you
like. And it's completely automatic and transparent. It also doesn't
have anything to do with server configuration. It's part of your config
spec.

>
>>     to the brittleness of config-specs,
>     Can you elaborate some more? We've always used some standard
>     5-line templates, quite easy.
>
>  
> You must version control your config spec if you want to be able to go
> back to what you had at a given point in time.

Nope, that's nonsense, too. You only need to do that if you don't put
the same label on all your artifacts.

> But then, that is why new SCMs do that for you by tracking changesets
> instead of single files. Even if you do that, depending on how
> complicated your config spec is, or if you use a lot of modules things
> can get out of hand very easily.

Then you have artificially complicated things. Config specs are quite easy.

>
>     Direct filesystem access to all versions via MVFS.
>
>
> Using a good mercurial GUI client (e.g. TortoiseHg) you get the same
> benefit without the weirdness or the slowness. Plus you get file
> annotation.

No. You don't have direct access to all versions in ANY other VCS. I'm
talking about foo@/main/mybranch/4 (version extended path name).

>  
>
>     Consistant filesystem paths (/vob/<vobtag>/...)
>
>
> I would call that forced directory structure, which is a huge pain.

Not if you have reproducability in mind.

>  
>
>     Reproducible, distributed, parallel builds (clearmake)
>
>
> I've not used clearmake much, but there are very good commercial and
> open source tools that can do that sort of thing, which is not really
> an SCM feature, IMHO.

The point here is the integration with the VCS. And no there are not so
much tools which can do that. One them is omake (Mojave project, not
Windows omake), the other one would be Electric Cloud's Electric Make,
but thats even more demanding and expensive than CC. You need quite some
hacks to teach GNU make, for example, to even rebuild when you change a
compiler option. clearmake does this for you automatically (when used in
dynamic views, it's as dumb as GNU make if used in snapshot views).

> If you work for a very process heavy company, where there is a
> control-freak attitude towards who can do what with your code base,
> then perhaps Clear-Case ifs for you. If you appreciate the sanity of
> your developers, not so much IMHO :->

Process enforcement is independent of the tool. One can do that with
Mercurial or Git as well.

Anyway, enough said. Think we both can't convince each other ;)

Bye...

    Dirk
-- 

*Dirk Heinrichs*, Senior Systems Engineer, Engineering Solutions
*Recommind GmbH*, Von-Liebig-Straße 1, 53359 Rheinbach
*Tel*: +49 2226 1596666 (Ansage) 1149
*Email*: dhs at recommind.com <mailto:dhs at recommind.com>
*Skype*: dirk.heinrichs.recommind
www.recommind.com <http://www.recommind.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20150115/212d24e5/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Logo.gif
Type: image/gif
Size: 1537 bytes
Desc: not available
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20150115/212d24e5/attachment-0002.gif>