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.


More information about the erlang-questions mailing list