Re: I can't commit a simple change

[Stephen J. Turnbull]

Lars Ingebrigtsen writes:
 > "Stephen J. Turnbull" <address@hidden> writes:
 > 
 > > In that case, this is a one-off problem and removing and ignoring the
 > > info directory entirely was the right fix.
 > 
 > Like I said, there have been plenty of these one-off problems.

For you.  However, I haven't noticed a lot of reports though (not even
from you and Richard), and I do take an interest in any VCS problems
so I'd be likely to notice.

 > One might suspect that they aren't one-offs any more.

As I wrote before, if you aren't making unrecorded changes to the tree
(that includes personal notes files, apply-later-maybe patches, and
things like that), then "rm `bzr ls -u`; bzr revert" is safe and DWYWs.
But as Eli points out, Make cannot know that that is safe and
shouldn't do it.

Now, what I know is that a lot of developers just don't want to learn
anything about VCS (or, in less virulent form, about a VCS different
from the one they prefer) or change their workflows so that it is a
benefit rather than a cost.  Nothing wrong with that, but what I
suspect is that that is the root conflict here.

It caused the people who did the original import of the CVS repo to
Bazaar to mirror practices that are mostly benign in "collection of
files" VCSes like CVS (ie, keeping build products in the repo) but are
inconvenient or even malignant in a "tree-oriented" VCS.  If the build
products had been removed from the repo at the very beginning, nobody
ever would have had a problem (the repo would already be in good state
when the first checkout was done).

To the extent that the problems you are reporting are due to that,
each one is one-off, each one is a real bug (there is a tendency to
forget to commit build products and for various reasons the default
Emacs build doesn't build everything, so the built Emacs gets out of
sync with the sources, and should be fixed (by removing them from the
VCS registry), not papered over with additional build complexity --
which as Eli points out, won't work anyway because there are still
conflicts lurking every time you try to do anything that changes the
repo.

I admit I wouldn't have predicted the especially pernicious effect of
"bzr remove"-ing the info directory (turning it into an unregistered
but precious object because it *contains* build products, and then
that conflicts with the VCS unregister -- this wouldn't happen with
git because directories are not first-class objects in git:
unregistering "info/dir" would also effectively unregister "info").

AIUI, turning info/dir into a generated file was a developer decision,
and maybe it was a bad idea (I'm not familiar enough with Emacs's
build process to express an opinion one way of the other).  Once that
decision was made, however, the file and the directory needed to be
"bzr remove"-ed in order to *prevent* future conflicts.  The "rm `bzr
ls -u`; bzr revert" incantation is what is needed to guarantee a clean
tree.  In this case you could restrict to  "rm `bzr ls -u info`; bzr
revert" IIUC the Bazaar docs.