Are dynamic views still useful given the speed of current processors?

This question is part of the SCM FAQ, which doesn't mean the answer is not controversial. The statement of the contrary is frequently made, and was made in particular by one of the inventors of dynamic views, in a thread (link unfortunately broken later...) in the ClearCase forum of CM crossroads.

I repeat the statement I made in the above mentioned thread, that the speed of producing deliverables is irrelevant: it is the speed of re-producing them which matters.

The reason is one of scalability: incremental changes should have an incremental impact, not one bound to the size of the system.

The issue is not even one of speed to build, but one of complexity to grasp, of manageability.

-- MarcGirod - 29 Oct 2007

So Marc what is your final statement about dynamic views? Can you summarize the pros and cons?

-- MichaelKircher - 02 Nov 2007

Maybe not a final statement, but there is currently no serious alternative in SCM to the management of derived objects, which at least so far, has only ever been implemented on top of dynamic views.
One could of course conceive of implementing auditing without a virtual file system, by intercepting system calls, in the same way a tool like strace does. This would involve house keeping of the context, as well as an external repository, but could possibly be done in user space...
Such a strategy would not provide all the functions of dynamic views, of course, e.g. the aliasing of different versions (generalized meaning) to the same name (path), which allows in turn referential transparency, i.e. the decoupling of the pattern of use from the exact selection of the versions. But this functionality could be left to something akin the (infamous) snapshot views.

However for now at least, the cons of dynamic views are problems to be solved—light weight replicas, so that there could be thousands of them; structure in type spaces to avoid needing to change mastership ever; replication of config records and lazy identification; etc.

[I am keen to avoid a thread-like development of these wiki pages, and thus suggest to maintain instead multiple, clearly focused, small pages. Thank You for your input in any case!]