Re: [Emacs-diffs] Changes to emacs/lisp/bookmark.el,v

[Eli Zaretskii <eliz@gnu.org>]

> From: Karl Fogel <kfogel@red-bean.com>
> Cc: Miles Bader <miles@gnu.org>,  schwab@suse.de,  cyd@stupidchicken.com,  emacs-devel@gnu.org
> Date: Fri, 21 Nov 2008 00:38:45 -0500
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> > As long as we use CVS, which lacks the means to see the change history
> > of a single file, 
> 
> Hrm?  'cvs log FILENAME'

That's the whole point: if several files are committed in one go, the
log message for each file will be usually taken from several ChangeLog
entries, sometimes from several different directories (e.g., if C
files and Lisp files are modified together, or if the documentation is
changed as well).  Then "cvs log FILENAME" will show a huge pile of
different entries for each FILENAME in the changeset.  What I want is
an option to "cvs log" that will show only the entries of the one file
I'm interested in.  CVS doesn't record that information, so I'm down
to grepping "cvs log" output, which is unreliable because I don't
always know what I'm looking for, and because of inconsistencies in
how the ChangeLog entries are formatted.

> > committing several files at once makes "cvs log"
> > unusable for the purposes of tracking the history of changes to some
> > specific code fragment in a single file, something I need to do a lot
> > in Emacs.
> 
> 'cvs annotate'

Not useful for tracking history, since it lacks the ability to show a
series of changes, or at least I'm not familiar with a way of having
it do that.

> > That is why I commit the files individually, and then commit all their
> > ChangeLog entries in one go.  Don't expect me to change that any time
> > soon.
> 
> By doing so, you are tossing away information that *can* be
> reconstructed (as per above).

That information is available in the ChangeLog files.

> When we convert to a modern version control system, other people's
> multi-file changes will be unified back into single changesets, but
> yours will not be, if you commit in the way you describe above.

Sorry, I hate wasting many minutes, sometimes hours, looking for a
history of a specific code fragment, so I will not make this problem
more grave by my own contributions.  When we switch to a more modern
VCS, I will review my practices, of course, but until then, we are
stuck with CVS and its limitations.