On Wed, Sep 9, 2015 at 12:21 PM, Richard Hipp <d...@sqlite.org> wrote:
> On 9/9/15, Ross Berteig <r...@cheshireeng.com> wrote: > > > > On 9/6/2015 7:13 PM, Richard Hipp wrote: > >> > >> Are there any projects (other than Fossil itself, and SQLite) that use > >> it? > > > > I use it in several of my non-toy, customer-facing projects. I do > > embedded systems firmware, and often want to leave a marker in released > > firmware for what checkin was used to build the release as shipped and > > installed in a device. > > > > I seem to re-invent that wheel a lot, and haven't settled on the perfect > > solution, but without enabling the manifest the archived tarball of a > > source snapshot would not be able to produce a bit-for-bit identical > > copy of the firmware because it is no longer associated with an open > > fossil repository. I assume that is the core reason it is used for the > > fossil and SQLite projects as well. > > Exactly. By setting the "manifest" flag to "on", the version > information appears inside of tarballs, meaning that Fossil is not > required to do the build. This is a very important consideration for > SQLite. > Note: when I said "created a manifest versionable setting" the other day, what I meant was "there exists a manifest versionable setting, is there a reason why we haven't used it with fossil / sqlite?" Seems like it would avoid issues with people accidentally turning off manifest in their own copy (either through the web UI or via command line while trying to copy settings around). Just a thought. -- Scott Robison
_______________________________________________ fossil-dev mailing list fossil-dev@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
