Xavier Hanin wrote:
What I think is really important is to be able to go back to the
version of
metadata used for a particular build, and using a tool like svn for
that is
something I've already considered and seen implemented by some
customers. It
works pretty well, the problem is that then you have to deal with
metadata
versions (as you explain Stephane) and this is not easy. Especially when
several nodes in your dependency graph require different metadata
revisions.
What is even less easy is to maintain metadata for a public repository
where
you can't be sure the change is an improvement. It can be for one
person but
not for the other.
"improvement" is indeed relative. It is just like fixing bugs.
If an app relies on a bug (eeek) to do things and that later this bug is
fixed, this may trigger another bug. :)
I would not really look for granular metadata revision to the node level
(this can get too complicated and is really unecessary to me) but more
on the whole repository thing.
Basically on your configuration you would say "I depend on r214093 of
the repository (or a tag name if you wish...))
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).
[...]
This will get way too granular I think.
And just adding configuration is enough to break things too.
I think we have to recognize as Steve said, that metadata can change.
This is a fact of life. Trying to solve this problem will simply get
things way more complicated than they actually are or need to be and we
will get entangled into a gigantic net which will make your life 10
times more difficult.
And how do you manage dependencies too ? In a corporate environment you
can be mean and when you upgrade a third party foo 1.1 to 1.2 you could
very well want to change (for very valid reasons) all other dependency
descriptors (even third party one) that say that depends on foo 1.1 and
bump them to foo 1.2 (which avoids unecessary conflict resolution and
unnecessary clutter).
-- stephane
