On Sat, Dec 28, 2002 at 07:31:13PM -0800, cgd@broadcom.com wrote:
  | Like i said, I don't think repository copying is the right thing to
  | do.
  | 
  | It properly preserves the revision history of the file, with no wacko
  | special cases (e.g. to handle the case of moving a file to a location
  | where a file has already existed -- something that a repository copy
  | just can't handle).
  | 
  | An appropriate log message does The Right Thing as far as i'm
  | concerned: it says "this is when this file began at this location, if
  | you'd like the earlier history, look in this other location."

I agree with Chris (cgd).

I've been bitten in the past trawling through the cvs revision history
where the revisions had been marked dead (which you need to do if repo
copying, otherwise date based checkouts fail), and finding that all I
could see was the log messages; cvs diff and cvsweb were useless as
far as finding out the "guts" of the change.


As a variation on the ``copy files and import the "new file" with
a commit message saying "this is moved from foo/bar/baz"'', why not
also include in the initial commit a copy of the cvs log of the old
file (possibly culled and/or reformatted a bit).

That way, people who want to see the commit logs from "before" the
move can do so without having to reference the original file, and
this avoids the other hassles of repo copies mentioned (difficulty of
Doing It Correctly, having revisions in a file that cvs diff / cvsweb
can't actually do anything with, etc, etc, etc).

Of course, this could mean that revision 1.1 of copied files could
end up with a Large commit message :-|

Luke.