[5867] in Release_7.7_team
Repository surgery alert
daemon@ATHENA.MIT.EDU (Greg Hudson)
Fri Oct 26 13:58:15 2007
Date: Fri, 26 Oct 2007 13:55:01 -0400
Message-Id: <200710261755.l9QHt1pS023624@equal-rites.mit.edu>
From: Greg Hudson <ghudson@MIT.EDU>
To: release-team@mit.edu
X-Spam-Flag: NO
X-Spam-Score: 0.00
The short version: there will be some mail spam to source-commits this
afternoon. You can safely ignore it.
The long version requires some historical background:
In the Athena repository, we import source into third/ on the vendor
branch (1.1.1.1, 1.1.1.2, etc.) and then make local modifications to
some of the files (1.2, 1.3, 1.4, etc.). Unmodified files have a
default branch of 1.1.1 (the vendor branch); modified files have a
default branch of the trunk.
Sometimes it stops being necessary to modify a file, e.g. if the
modifications were accepted upstream. Under normal CVS operation, CVS
continues maintaining those no-longer-modified files on the trunk,
performing trivial merges each time a new version is imported. That's
kind of wasteful, but everything works.
Circa 1999, disturbed by the wastefulness of this approach, I adopted
what I thought was a harmless hack where you would reset the default
branch to the vendor branch once a file was no longer modified on the
trunk. I stopped doing that a couple of years later when I realize it
had bad consequences for checkouts by date (which can't be made to
work perfectly anyway, but this makes it worse) and when disk space
had gotten cheaper to the point where I stopped caring about the
wastefulness.
Fast forward to 2007. The cvs2svn script does not know how to make
sense of this harmless hack, and throws a fatal error. There are 46
affected files. Repair is straightforward:
* If the top of the vendor branch is still the same as the top of
the trunk, just eliminate the default branch setting.
* Otherwise, force a checkin with no changes to the trunk, which
will put the right version on the trunk and eliminate the default
branch setting automatically.
