If we are going to do that, I wonder if we should start having tests share their inputs. We don’t do that for source files because the cost of duplication is so small, and then you don’t have the hassle of adding something to a source fie for test A messes up test B. But for binaries like core files, it might be worth that hassle. Especially as we need to pick up core files for a bunch of different architectures.
Jim > On Nov 18, 2016, at 8:42 AM, Pavel Labath <lab...@google.com> wrote: > > labath added a comment. > > We probably don't want to check in zillions of core files, but I believe > having a couple of them is fine, particularly when care is taken to minimize > their size. I believe the benefits (being able to run tests on a piece of > code in a reproducible and platform-independent manner) outweigh the > downsides. And I don't expect these files to change every week (probably more > like never), so they won't bloat the history. Compare that with a 7MB python > reference html file we currently store in the repo, which we should update > (but we don't) on every API change. > > > https://reviews.llvm.org/D26676 > > > _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
