On 11/9/06, Steve Loughran <[EMAIL PROTECTED]> wrote:
Gilles Scokart wrote: > > >> -----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...)) >> > > > I fear it would be too simple. When we talk about a build being > reproduceable, most of the time it doesn't meant relaunch exactly the same > build. Most of the time, it actually means "change a few things and be sure > that all the rest is excactly the same". With a single release number of > the repository, it would be hard to say "change only the metadata of one > specific dependency". > The other way to think about it is "when I make a full-build package release, that includes all the artifacts needed to rebuild and retest my application". You could snapshot the metadata (chain expand all the dependency info into one file), and/or pull down all the relevant artifacts. That way even if a DMCA takedown notice pulls a JAR you want, or the entire network partitions the day you want to rebuild, you can still type 'ant' and get what you want.
I'm not sure to see what you mean, but if I get you the problem I see is that in this case when you reproduce the build you are not in a usual development environment. So if you need to create a branch to fix things, or even develop new features, you will be a bit in trouble if you need to do a lot of dependencies update, won't you? Xavier When we do some long-life projects we add to clearcase the JDKs used in
the build; sometimes even vmware images. snapshotting metadata and artifacts is trivial in comparision.
