For myself I tweaked my decompose script to remove certain frequently changed lines from the SaveAsText files if their removal didn't cause problems when my compose script adds them back into Access and was something that I don't actually care about. (For example, I always delete the Checksum & RecSrcDt lines from my forms.)
Formatting stuff that I sometimes care about and sometimes don't gets left in. Most of the time I'll revert those changes but if there are a bunch of them that always come back after reverting and/or are mixed in with some other important formatting changes I did, I'll commit them separately as misc. office changes so I don't have to deal with them anymore. Mischa Becker -----Original Message----- From: Mercurial <[email protected]> On Behalf Of Boylan, Ross Sent: Friday, March 15, 2019 12:29 PM To: [email protected] Subject: Ignoring trivial changes Sometimes there are changes that are of no substantive interest, e.g., change in the date on the banner of a listing file or a change in dimensions of an object (e.g., text file included "Right = 800" and now is "Right = 845"). I would like advice on how to handle this, in two senses: the mechanics of how to do this, and what I should be doing. The first is more straightforward, and so I'll start with it. This is like EOL or other whitespace differences, including the fact that the "trivial" differences are sometimes so numerous that they obscure the real differences. HOW Is there a way to associate different diff tools with different file extensions? I did this before (code now vanished), and am not sure how I got around this. The merge tools seem to allow association of different tools with different file extensions, but not the diff tools. I may have just written a custom diff that checked the file extension. Previously I think I normalized the files by stripping line numbers and dates and then doing a diff; that was for SAS .lst files. Currently I'm more focused on exported MS-Access source code. What if I want the change to affect other things, e.g., status or merge? That is, if the only changes are trivial, status reports no change and merge thinks there is nothing to merge. WHAT If a file has only trivial changes, should I commit them anyway? If a file has only trivial changes, what status should it show? The "should" here means the most desirable behavior, not how hg currently behaves. Obviously if I adopt the normalization strategy, for example all occurrences of "Right=123", where 123 is any digit sequence, becomes "Right=N" where "N" is literal, I would not want to commit the normalized version of the file. Thanks for your thoughts. Ross ________________________________ This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain information that is confidential and protected by law from unauthorized disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. _______________________________________________ Mercurial mailing list [email protected] https://www.mercurial-scm.org/mailman/listinfo/mercurial
