Ignoring trivial changes

[Becker, Mischa J]

Yes, sorry I wasn't clear.  All the deleting happens outside of hg.  It's been almost 9 years since I initially setup my process.  IIRC I never ran into any unfixable errors with LoadFromText that were caused by deleting some of those property lines from the saved file.  In general, Access just reverts the missing property to whatever is the default in your database when you load the file back in.

I just looked at my code.  Other than the properties I already named, the only ones I'm actually deleting are the ones stored in binary and therefore not mergeable.  I eventually re-added ConditionalFormat & ConditionalFormat14 once I started using them, but for PrtMip & the 4 PrtDev properties (page setup and other print settings) I ended up adding a separate process to write those out to text so I could merge them.

Left, Top, Right, & Bottom seem to correspond to the form's displayed window.  I only save those changes if I know I made a change I want to keep.

Mischa Becker

-----Original Message-----
From: Boylan, Ross <Ross.Boylan at ucsf.edu>
Sent: Friday, March 15, 2019 1:40 PM
To: Becker, Mischa J <mischa.becker at kroger.com>; mercurial at mercurial-scm.org
Subject: Re: Ignoring trivial changes

By "decompose script" do you mean your script that dumps MS Access code to text files, i.e., something completely outside of hg?
I'm guessing that because SaveAsText is an Access function.

At any rate, I hadn't considered dealing with the noise further upstream from hg; it's an interesting idea.  The problem is that I mostly don't know what the non-code stuff is doing, although one can often guess, and I certainly don't know what's safe to remove.

Ross

________________________________________
From: Becker, Mischa J <mischa.becker at kroger.com>
Sent: Friday, March 15, 2019 1:33:12 PM
To: Boylan, Ross; mercurial at mercurial-scm.org
Subject: RE: Ignoring trivial changes

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 <mercurial-bounces at mercurial-scm.org> On Behalf Of Boylan, Ross
Sent: Friday, March 15, 2019 12:29 PM
To: mercurial at mercurial-scm.org
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.