Re: rename and clean unexec.c

[Eli Zaretskii <eliz@gnu.org>]

> Cc: emacs-devel@gnu.org
> From: Dan Nicolaescu <dann@gnu.org>
> Date: Fri, 30 Jul 2010 03:37:30 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Cc: emacs-devel@gnu.org
> >> From: Dan Nicolaescu <dann@gnu.org>
> >> Date: Thu, 29 Jul 2010 17:18:02 -0400
> >> 
> >> I am not sure why are so opposed to this.
> >
> > Not "so opposed", just opposed.  I'm opposed in principle to every
> > cosmetic change that doesn't have a very good reason.  
> 
> Maintainability is a very good reason.   Keeping bad names is not.

It should be obvious by now that we disagree on how much this
particular renaming will contribute to better maintainability.

> > That's because
> > such changes obscure real code changes and make forensics harder.
> 
> Can you please explain exactly how renaming a file managed by a decent
> VCS makes forensics harder?

I can only speak about Bazaar, as I'm not familiar enough with
similar facilities of other dVCSs.

The tools I use for forensics are:

  . bzr log
  . bzr diff
  . bzr annotate
  . bzr bisect (and bzr revert in general)
  . ChangeLog entries
  . related discussions on emacs-devel and bug-gnu-emacs

"bzr diff" and "bzr annotate" indeed support renaming nicely and
transparently, but they are never enough to fully investigate the
reasons for some change.  They just show what was changed and when,
and who did that, so they are only the starting point.

A minor gripe about "bzr bisect" and "bzr revert" is that they will
move the renamed (or deleted) files to alternate names, which is fine,
but requires one to be alert in order to prevent all kind of weird
errors and warnings down the line.

The rest of the tools I use have problems with renaming:

  . The latter two need that you know about the renaming, or else you
    won't hit relevant information in a search.
  . The first one generally shows a slightly edited copy of a
    ChangeLog entry, so it doesn't support renaming well, either; even
    the entry for the rename itself will only mention the renaming if
    the committer remembered to state that, i.e. it's prone to human
    error.

In addition, "bzr log" seems to have a bug that rears its ugly head
with renamed files.  Observe:

  $ bzr log -c26091 --long src/s/usg5-4-common.h
  bzr: ERROR: Path unknown at end or start of revision range: src/s/usg5-4-common.h

(It works if I use usg5-4.h, the name it had when revno 26091 was
committed.)

Granted, these are not acute problems, more like annoyances, but if
you are in a hurry and need to find the information quickly and
efficiently, they could defeat you.

Again, I don't object to renaming in general.  We renamed (or moved)
quite a few files lately, and I don't remember myself objecting to
even one of them.  I just don't see a good reason in this particular
case.

Now, I hope that my reasons are clear, as are yours.  If only the two
of us have opinions on this matter, we could go on arguing forever.  I
think at this point it would be good to hear opinions from others,
preferably Stefan and/or Chong.