At Wed, 5 Nov 2025 17:01:39 +0000 (UTC), Benny Siegert <bsiegert%netbsd.org@localhost> wrote: Subject: Re: irt: Re: Core statement on version control systems > > You missed another, unfortunately much > more common operation that changes all > older commit hashes: If you delete a file > with a $NetBSD$ line in it, CVS will more > its ,v file to the Attic subdirectory. It > will then go back and retroactively > rewrite all revisions of the file with the > changed path to the ,v file including the > word Attic. Hmmm.... Yes, an interesting problem... The Attic directory is an optimization for CVS and shouldn't show up in any extracted version of a file. CVS doesn't actually modify anything in the ,v file that it moves to the attic, other than to add the normal revision for the deletion with the state marked as "dead". The token "Attic" does not appear in any ,v file. There is no actual rewriting of previous revisions. The only place one normally will see the token "Attic" in CVS output or CVS managed files is where it has purpose to refer to the location of the actual ,v file, e.g. in "cvs log" output. However the "$Header$" and "$Source$" keyword expansions will contain a full pathname to the RCS file in the CVS repository. Similarly "$CVSHeader$" expands to a relative path to the RCS file (with the CVS "root" stripped off). We could/should call these "poisonous" RCS keywords. Note though that expansions of the "$NetBSD" RCS/CVS keyword only include the filename, no path part, so it won't cause any problems. However there are indeed couple of files with at least the $Header$ RCS keyword in them. (such files are usually third-party "dist" files, and of course any import of a new release of a third-party package could add new files with such poison keywords and further imports could then remove old files with those poison keywords) On the other hand although CVS itself does indeed expand those poisonous keywords with the "/Attic/" part included when examining (checkout or update of) previous "live" revisions of those files, this is arguably a nasty bug and it should not happen. After all there is no actual real revision of the file where its RCS backing file is legitimately in the attic. Only the non-existent removed revision of the file has its RCS file properly in the attic. CVS should be presenting expansions of previous "live" revisions of files with the full RCS pathname expanded as if it was not yet removed, i.e. without ever including the "/Attic" part in any keyword expansion, ever. This is a private CVS optimisation that is leaking! So arguably such perturbations in any continuous migration process could, and perhaps should, be fixed and thus avoided. This would of course mean that there could be differences in lines containing these poisonous keywords between a "cvs checkout" or "cvs export" of an older release (using an un-fixed version of "cvs") and what will be seen in a checkout of the same release from any DVCS. However that's a different problem, and one that does not perturb the hashes of files in the migrated DVCS. -- Greg A. Woods <gwoods%acm.org@localhost> Kelowna, BC +1 250 762-7675 RoboHack <woods%robohack.ca@localhost> Planix, Inc. <woods%planix.com@localhost> Avoncote Farms <woods%avoncote.ca@localhost>
Attachment:
pgp1v9cQ570WX.pgp
Description: OpenPGP Digital Signature