> -----Original Message----- > From: Xavier Hanin [mailto:[EMAIL PROTECTED] > Sent: Thursday, November 09, 2006 6:15 PM > To: [email protected] > Subject: Re: infallibility-of-metadata would be better from this point >
> > > > > -----Original Message----- > > > From: Stephane Bailliez [mailto:[EMAIL PROTECTED] > > > Sent: Thursday, November 09, 2006 8:43 AM > > > To: [email protected] > > > Subject: Re: infallibility-of-metadata would be better from this > > > point > > > > > > > > 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...)) > > > > > > Another problem I see is that if on one hand there is a > module for which the latest metadata correspond to what you > want but on the other hand for anotherr module you need an > old version, then no repository version is really good. > > > Xavier > I didn't see the problem there if the tags or repository snapshot is linked only to the module I build (or rebuild). I think the snapshot (being a single number or a set of numbers) must be done after the conflict resolution. Did I misunderstood you? Note that there is an other argument in favor of granular revision numbers. This solution support much better a possible evolution of the repositories toward a peer-to-peer architecture (see stephano mail "[RT] on package management"). Even if this type of repository is maybe not a good thing for corporate environment, it's a possible evolution that should be anticipated. Now it's true that it introduce additional complexity. But I have some difficulties to imagine what would be the additional complexity for the user, compared to the difficulty of having only one revision number. Gilles
