On Tue, Jun 28, 2016 at 1:34 PM, Warren Young <[email protected]> wrote:
> > 5. My scheme modifies one of the input source files — as opposed to > modifying the built executable, as in Ron W’s scheme — which means you > could have an executable that claims to be built against the prior checkin > on the current branch instead of the current checkin. That is, if you edit > a file, build the software, test it, and then check the change in, the > checkin ID containing the change doesn’t match the checkin ID in the > executable until you build again. > As I mentioned in my post, our build system does a commit in the post link phase of the build, so the ID embedded in the executable matched the commit. I know some people don't like committing untested code, but our team follows a "commit early, commit often" philosophy. We do, for the most part, commit only code that compiles and links. Also, we have the option to do "debugger only" builds, which don't do the commit, and generates an executable that can only run with the debugger. Builds that are to be run without the debugger get programmed in to electronic modules. Because the modules can be picked up and taken away, it's very important we are able to identify the software in them. (We have a special tool to do that.)
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
