On 2/18/07, Joshua Isom <[EMAIL PROTECTED]> wrote:
On Feb 18, 2007, at 7:14 PM, Will Coleda wrote: > > On Feb 17, 2007, at 10:14 AM, Patrick R. Michaud via RT wrote: > > Yes, but our MANIFEST is just a list of everything in the repository > (modulo a single directory that we started skipping in r12600). It's best purpose is probably to make sure that your svn checkout was complete, or that your tarball contained everything it was suppose to. It's a nice neat way to figure out that the file you need to compile everything isn't there because your checkout was bad or your tarball was incomplete. It serves a good purpose for a fresh checkout/download, even if after that it's annoying.
which is most important when you're working with a tarball--for us, that means a release version. we should definitely include a manifest with a parrot release. and it's straightforward to modify the release instructions to make sure a manifest is generated, and that it's correct and complete. it's also possible using this strategy to have an automated daily tarball of current trunk which includes a manifest as well, but i'd like to leave the discussion of that extension for a future date.
> For the moment, disabling configure's manicheck by default would be a > good start. This isn't something we need every developer wasting their > time on given how we're using it right now; more of something that > should be handled by the release manager. You mean you don't use a little script to automatically run Configure.pl with your desired arguments, including --nomanicheck? > (How many times has the build been broken by a missing MANIFEST > update?)
i don't think manifest checking should be disabled until we have a replacement solution in place that makes sure the manifest is checked before every release. fortunately, the solution is simple. updating release instructions with a procedure to check manifest is sufficient, and --nomanifest can be enabled on Configure.pl by default. in the future, this option should be renamed to eliminate the negative.
If the MANIFEST is regenerated on the server whenever a file is added or deleted, it should stay accurate. But I have no clue how badly that would complicate things(add a file and instantly need to svn up).
i don't recommend a repository hook for this--the overhead you mention of required update after file addition/deletion isn't worth the trouble. the main use of a manifest, as mentioned above, is for verifying the contents of a release, not a repository. and that requirement is for end users, not developers. ~jerry
