Working w/ various combinations and permutations of complex(ish) builds, a ./configure phase for me will generate a config.old, and even though it's a good rule to not put build artifacts into version control, I do put the config.old in so I have an in-tree reference to changes from previous builds... breaking two rules w/ one commit ;)
-bch On 2/11/15, Stephan Beal <sgb...@googlemail.com> wrote: > On Wed, Feb 11, 2015 at 5:14 PM, Ron W <ronw.m...@gmail.com> wrote: > >> On Wed, Feb 11, 2015 at 7:54 AM, Richard Hipp <d...@sqlite.org> wrote: >> >>> Fossil uses file mtimes and sizes to help it detect changes. When >>> your tool moves foo to foo.bak, this changes neither the mtime or the >>> size. So Fossil fails to detect the change, by default. >> >> >> But, the "new" foo.bak would have the mtime and size of the "old" foo, >> which would be different from the "old" foo.bak >> > > And two unrelated points: > > a) having a .bak file completely undermines the reason for using source > control. It reveals old habits from pre-SCM days, which are no longer > relevant once one has an SCM. > > b) because x.bak will have the same content (i.e. same hash) has the prior > version of x, fossil will only keep one copy (the previous one), so having > x.bak does not unduly bloat the repo, regardless of how big it is. (Only a > filename mapping entry is needed.) > > > -- > ----- stephan beal > http://wanderinghorse.net/home/stephan/ > http://gplus.to/sgbeal > "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of > those who insist on a perfect world, freedom will have to do." -- Bigby > Wolf > _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
