At Sun, 29 Dec 2002 00:47:20 +0000 (UTC), "Perry E. Metzger" wrote:
> How about if one did a copy but altered the dates in the duplicate? It
> is pretty easy to do that. One then retains a modicum of revision
> history.

So, for the sake of "keeping history" you change that history?  "Hmm."

(Obviously, it begs the question what if you care _when_ a file was
broken, not just by whom or the log information?  Well, sure, you can
put the original commit date into the commit log by modifying it
further...)


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."


There's another issue here which may be worth bringing up:

OK, fine, say you consider having to look in a second place for the
history of the file a little less convenient.  I'll grant that it's a
little less convenient.

Consider the number of files which "should" be moved over time, and
the overall effort that is caused by doing the move via 'normal'
methods.  I sure as heck _hope_ the overall effort isn't too
great... because, uh, if it is, you're moving too many files around.

As far as I'm concerned, disincentive to move files around would be a
positive thing.  8-)

Compare that extra effort with the extra effort involved in doing
repository copies, and especially with the consequences should such
copies go awry.


I'm a big fan of special procedures, even hard-to-implement ones, so
long as they have significant benefit and so long as they can be
consistently implemented.

I don't know that repository copies _do_ have significant benefit, and
i don't see how they can be consistently implemented.  (at minimum
because of the issue of moving a file to a location where a file has
already existed).  Further, because of the relative infrequency of
code moves, they should be important in only relatively few cases.


(If NetBSD developers want to adopt wacko special procedures, I've got
one that works really, really well for doing imports of third-party
software.  It allows you to take an arbitrary amount of time to merge
changes in the newly-imported version on to trunk, w/ no modifications
visible on the trunk until the merge is done.  Of course, it's got
some of the same drawbacks as repository copies: it requires direct,
local, write access to the CVS repository...  And in order to get
diffs against the vendor branch to be clean of extraneous diff headers
it needs hacks to CVS which the CVS maintainers refused to take
back...  But to my mind the benefits are really worth it.)



cgd
--
Chris Demetriou                                            Broadcom Corporation
Principal Design Engineer                     Broadband Processor Business Unit
  Any opinions expressed in this message are mine, not necessarily Broadcom's.