Hello, My apologies if this answer is not relevant or has already been given: I did not read the full contributions, just reacting to Brett's post.
I recently discovered the existence of nix (http://nix.cs.uu.nl/) which is a kind of build system (rather a package and configuration manager) that relies on: - a purely functional (ie. side-effect free) lainguage and model for building resources based on other resources, - based on computing and maintaining hash values that encode the 'state' of the environment and the produced artifact(s). When using nix, strict reproducibility of build and separation of different versions, users and executions is maintained through symbolic links containing hash-values pointing to the real resource. Then when I build resource A, based on B and C, I create a resource and store the configuration that lead to it using some unique combination representing the actual state of the 'computation' that creates A. This scheme could provide one solution to the various issues exposed by Brett Porter: The idea could be, for portability, to work with a virtual (indirect, URL-based) representations of the repository encoding some particular state that is needed for some goal: Rollback would be as simple as erasing one particular configuration, sharing of repositories between users could be done with individual configurations, hash code would ensure that not only the artifact but also its build environement are unique and reproducible. My 2 cts. -- OQube < software engineering \ génie logiciel > Arnaud Bailly, Dr. \web> http://www.oqube.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
