Subject: Re: bin/20200: Let etcupdate skip files with strictly local modifications (patch)
To: Christopher Richards <richards+netbsd@CS.Princeton.EDU>
From: Greg A. Woods <email@example.com>
Date: 02/04/2003 18:12:12
[ On , February 4, 2003 at 14:57:19 (-0500), Christopher Richards wrote: ]
> Subject: Re: bin/20200: Let etcupdate skip files with strictly local modifications (patch)
> On 4 Feb 2003 19:42:04 GMT, Greg A. Woods wrote:
> > Yes, absolutely -- I've been harping over this for years. Though the
> > trick with RCS ID strings works well enough for identifying that changes
> > have been made to the "master" version of at least those files which
> > contain RCS ID strings [...]
> You misunderstand what my change does. It does *not* use RCS ID
> strings to detect changes to the master version for the purpose of
> merging those changes.
I wasn't commenting on your change but rather on what David Laight said:
| It seemed to me that you needed to know the file that the user
| had started with. Then you can tell whether there are any local
| modifications, if not it is (probably) safe to install the new
| version of the file.
Indeed one does need to "know the file that the user had started with".
This is the ancestor copy, or "older" parameter in diff3's terms.
This is the only safe and sure way to determine if the new file has
changes which need to be merged into the possibly modified locally
installed file. This method does not depend on the RCS Ids in any way,
and thus is safe for all text files.
If you keep a copy of the original un-modified file and then run diff3
with it as the ancestor, and with the new one as "yours",:
diff3 -ATam /etc/rc /tmp/etc/rc /usr/share/examples/etc-orig/rc
then the output, if it contains no overlapping changes, can go right
back in over the locally installed file, /etc/rc in this example,
pending user approval of the upgrade's changes, of course. Once the
merging is done then the new files from the upgrade release are moved to
/usr/share/examples, overwriting the old copies, so that a future
upgrade can proceed with another merge from this new starting point.
I do wish diff3 had an interactive option ala sdiff, or alternately that
sdiff had an option to do a three-way merge ala diff3. Sdiff by itself
is kinda cool, but it's far too much work for most upgrade merges. On
the other hand if there are conflicts then the diff3 output requires
manual editing to resolve them, and doing that in postinstall or
etcupdate could be problematic.
Greg A. Woods
+1 416 218-0098; <firstname.lastname@example.org>; <email@example.com>
Planix, Inc. <firstname.lastname@example.org>; VE3TCP; Secrets of the Weird <email@example.com>