ClearCase and such like
Matthias.Lang@REDACTED
Matthias.Lang@REDACTED
Sat Apr 15 10:01:39 CEST 2000
> I'm thinking of buying a clever build management tools such as Rational
> ClearCase.
>
> Does anyone have much experience of using these tools in an Erlang
> development environment. i.e. nice integration with emacs, and integration
I worked a year in an Erlang project with about a dozen developers
where we used clearcase, I've also worked in a larger C++ project
which used clearcase. The feeling I got was the clearcase really
helped with the C++ project, while for Erlang it was occasionally
neat, but not worth the overhead---someone needs to maintain it,
someone needs to teach developers how it works, it's much more complex
than CVS. The things that impressed me in the C++ project were
- wink-in (clearcase figures out that you're building the same
binary someone else has built, and therefore you don't need
to compile it again, clearcase "winks" it in from the other
person's part of the filesystem) actually does save you time
and disk space.
- multisite. As long as "someone else" takes care of babysitting
clearcase, the developers feel little pain when a project
gets split across multiple sites, e.g. half the developers in
Australia and the other half in Germany.
- you have lots of information available about the past, e.g.
when you're trying to figure out exactly why the wrong file
got shipped to the customer, you can easily roll back the clock
and go see what build commands were used to make that file.
It's also possible to generate reports your semi-insane
quality manager demands---e.g. he turns up and wants a report
showing all binaries affected by a change in source file X
made in the delivery 3 weeks ago. With CVS you can get that
information by staring at Makefiles, re-running the build and
taking an educated guess. Clearcase stores this information
automatically in its database.
- you have power. If you think, say, Dave is an idiot, it's
easy to get the system to warn you whenever Dave makes a
change to your files. If you're heading towards a release, it's
easy to lock the database so that only a couple of people
have the power to make changes.
In a smaller project using Erlang, these featuers aren't all that
useful. Some of them are partially taken over by Erlang (e.g. a
bit of build information is stored in the .beam file), some are
mostly irrelevant to Erlang (wink-ins aren't imporant in Erlang
because compiling is relatively fast and it's rare to have to
recompile heaps of code because someone changed a .h file somewhere,
there typically aren't a lot of dependencies).
Hope that helps.
Matt
More information about the erlang-questions
mailing list