2006/11/8, Xavier Hanin <[EMAIL PROTECTED]>:
That's why I began to thought about using compatible metadata revision, so
that you never break anything. Whenever you want to change the metadata of a
module, the only thing you can do is to add new configurations, and maybe
deprecate others. The metadata revision is identified in the file by an id
(which could be simple incremental number, or by a timestamp/user uple as
you indicate) Each configuration declares in which metadata revision it has
been introduced/deprecated. By default when you depend on a module you
depend on its first metadata revision, unless explicitly specified
(specifying a specific revision or the latest one if it makes sense). The
compatibility of all metadata revisions ensure that when you get the latest
metadata revision (i.e. the current one on the repository) you are able to
know its whole history. Thus you are able to resolve the dependency on the
metadata revision 1 if you get the revision 2, the only thing that changes
is that when you declare a dependency on all configurations, it actually
means all configurations which existed in the metadata revision you
indicate.
This idea is the result of a few hours of thinking during my trip back from
california last september, but I hadn't time to think more about it til now,
nor to experiment with it. So I'm pretty sure you will find a lot of flaws
to this idea, but it may be a good start for some kind of solution.
Xavier
I'm not sure to understand what you explains (even after reading it a
few times), but here is what it inspired me when I was on the train
this afternoon (a short travel... so short inspiration).
When we want a build to be reproducable, we classically use an SCM
repository for the source. The process is to define a tag name, apply
this tag to the source you want to build, and then run the build.
The same principle should be applied when some files (the meta data
files) are comming from outside our source repository.
Of curse, you can not store the tags of all your users into a public
repository. But the "tag info" can be stored somwhere else (for
example in a report file stored by the user in his own repository
under his build tag). If the build use this "report" instead of
re-resolving the dependencies, you are sure to repeat the same build.
With a meta-data revision number, it should be achievable.
