On Mon, 2005-10-31 at 19:40 -0800, Denis Leroy wrote:
> Ralf Corsepius wrote:
> > Hi,
> >
> > What is this recommended/nominal procedure to rename a package in FE's
> > CVS?
> >
> > I could imagine 3 approaches:
> >
> > 1. I "cvs add" the "old-package" as "new-package", edit the files
> > accordingly, then subsequently "cvs rm old-package".
>
> I would recommend this, since this is the regular CVS approach. It's
> important that the new-package CVS commit message includes a pointer to
> the old name ("moved from old-package"), so that one is able to follow
> this link to consult the CVS history of the file if necessary. By
> removing the old-package files, and always using the -P (prune empty
> directories) with cvs update, the old empty directory will be removed
> automatically by CVS during the update.
This way, you're loosing CVS history of the files being involved.
Also, given the way FE's packages currently are implemented in CVS
(using a CVS module for "common"), CVSROOT/modules could be a problem
[1].
AFAIU, when you "cvs rm" all "old-package" subdirs, the corresponding
"common" entry in "modules" will have to remain, i.e.
'cvs co -dP "old-package"' will always give you a package directory with
a common/ subdirectory.
> > 2. Somebody with direct CVS repository moves the directories in CVS
> > ("cp old-package new-package") and I edit the files after the
> > directories have been moved.
>
> This corrupts the CVS repository because one can no longer checkout an
> older tree. Should be avoided.
Well, right, it "corrupts" the CVS repository in the sense, you mention,
however it doesn't corrupt the repository, in the sense of "rendering it
technically unusable". On the other hand, it preserves CVS history of
the renamed package. I.e. the old packages would still be present inside
of CVS except that they would appear in a different directory upon
checkouts.
How about "copying the directories (instead of moving)" directly in CVS,
and "untagging" all "inherited tags" in "new-package"? This way you'd
not loose a package's history, and wouldn't "corrupt" the repository.
CVSROOT/modules, would remain a problem.
Ralf
[1] CVSROOT/modules already is a problem elsewhere: GiNaC had been
renamed into "ginac":
ATM, in CVSROOT/modules, the GiNaC modules are being still mentioned,
but the directory rpms/GiNaC/ seems to have been physically removed
=> Though GiNaC had been released, the corresponding CVS seems to be
gone (corrupted CVS in your sense above).
=> cvs co GiNaC throws an error:
# cvs co GiNaC
cvs [checkout aborted]: there is no repository /cvs/extras/rpms/GiNaC
