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.
Also, isn't it possible that MANIFEST could eventually include
(generated) files that belong in the distribution but aren't
in the repository? If yes, then the repository cannot be the
canonical list of files going into the distribution.
Yup. Makes sense. So "die" is too strong, but "fixed" isn't.
If you manually update MANIFEST, then yes, it's possible. If you use
one of the programs to generate MANIFEST which relies on svn doing the
dirty work, then no, since only those files in the repository would be
in the MANIFEST.
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?)
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).
--
Will "Coke" Coleda
[EMAIL PROTECTED]
