Re: does CVS officially support renames?

[Andrew Cagney <andrew.cagney%gmail.com@localhost>]

On Thu, 8 Jan 2026 at 10:19, Martin Husemann <martin%duskware.de@localhost> wrote:
>
> On Thu, Jan 08, 2026 at 10:06:58AM -0500, Andrew Cagney wrote:
> > My fuzzy recollection is no, instead files are added/deleted as a commit.
>
> That is correct.

so, to follow this thought bubble through to a questionable end:

-> the existing CVS repo contains no rename information
a commit message may suggest a rename, and commit ID's may loosely tie
the add/delete to a single commit, but there's nothing to prevent, as
part of the shuffle, edits to the file et.al.

which means:

-> a CVS->mercurial conversion can't have rename information
for a conversion to include renames it would need to apply heuristics;
if there's one tiny bit of consensus around git vs mercurial it's that
rename heuristics aren't 100% reliable, from my POV it's better to
just preserve CVS's semantics and generate simple commits

which begs the question:

-> since the converted repo has no renames, why is supporting renames
a must-have requirement?

> > And based on Greg's comments, developers are copying .cvs files within
> > the repo in an attempt to fudge it.
>
> I don't think that happens (for NetBSD repositories).

I'll let Greg explain the problem.  All I know is, in the current git
conversion, hashes keep changing.

> Developers do not have access to the CVS server at that level and can not
> manually do any kind of surgery/forgery.
>
> What sometimes happens is that an import goes to the wrong directory
> (where the directory should not exist at all) and admins are asked to nuke
> all traces of that bogus import from the repository. That better happens
> before the (bogus) directory ever entered the repo conversion.
>
> Martin

"Better a diamond with a flaw than a pebble without one"