Re: CVS commit: src

[Taylor R Campbell <campbell+netbsd-source-changes-d%mumble.net@localhost>]

> Date: Mon, 2 Sep 2019 14:23:14 +0000
> From: Taylor R Campbell <campbell+netbsd-source-changes-d%mumble.net@localhost>
> 
> > Date: Mon, 2 Sep 2019 16:53:34 +0900
> > From: Masanobu SAITOH <msaitoh%execsw.org@localhost>
> > 
> >         d) Any other options.
> 
> 1. Revert the commit for now, ASAP, to unblock people.

So, it turns out this is more complicated than I thought.

msaitoh pointed out that since the files have now been installed, it
seems appropriate to mark them as obsolete when reverting the commit.

However, if we add them to obsolete, then I expect that on a case-
insensitive file system, when build.sh distribution runs postinstall
on $DESTDIR, and it tries to delete the new (bad) files, it will have
the effect of deleting the old (good) files too because their names
differ only in case.

So we need to clean this up _without_ marking anything as obsolete
(and then add a note to UPDATING and post an announcement to
current-users explaining what happened and advising everyone to
manually delete the new (bad) files).


How do we clean it up?

1. We could simply revert the commits, but that will nevertheless
   break checkout by date on case-insensitive file systems, which
   implies breaking bisection over the past week on case-insensitive
   file systems.

2. We could move the ,v files to a subdirectory as christos suggested,
   but the Makefile changes would then refer to files that don't
   exist, which implies breaking bisection over the past week for
   everyone.

I am not seeing a good way out of this.  I'm inclined to weigh
`bisection for everyone' as more important than `bisection on
case-insensitive file systems', and to prefer (1) over (2), but maybe
there are other downsides to leaving the ,v files around and other
reasons why we should do (2) instead of (1).

Thoughts?