> > 1. in all checkouts of old stuff predating the rename, a file "newfile"
that
> > did not really exist in that configuration will now appear (this bit
me).
>
> This is absolutely not so. I've even tested it just now to be sure.
If you do a checkout using a tag, and that tag did not exist in the file, then the file will not appear. If you do a checkout by date, and no version in the file existed as of that date, then no file will appear.
If, however, the file name has been rendered stale (e.g. by 'cvs rm'), and a new file is later resurrected that chances to have the same name, then a checkout by date will think that the last stale version was current in the time when the file was dead.
Actually, the behavior also depends on the particulars of branching.
I got bit by this in the EROS tree. There was a time when I went back and forth between files ending in .hxx and files ending in .h, and a lot of things broke. This is because I did a rename on the file in the repository. See my comment below for why I did this rather than use the 'rename, cvs rm, cvs add' strategy.
> > 3. You can't track the history trail of newfile.
>
> Eh? In what sense?
Suppose I have a file foo.hxx that I rename to foo.h. When I run 'cvs log' on foo.h, I certainly want to see that a rename occurred, but I also want to see that there is history from the foo.hxx version. The problem with the strategy Ben outlines is that this history trail is broken.
It's a choice of bads. The other strategy I have heard people advocate is that you *copy* the RCS file in the repository. This preserves the history trail at the cost of having orphaned files appear in the intermediate versions.
Much of the necessary information exists in the CVS master commit log, but there is no record of the renaming available there.
> > What CVS really needs to do is capture a complete list of
rcs-file+version
> > for each configuration. This is roughly what PRCS does now, but PRCS
doesn't
> > provide remoting. I've talked to Josh about doing this, and it's
> > considerably harder to get right than it appears.
>
> cvs tag?
cvs tag doesn't actually do this. First, there is the problem that tags can be reused. Second, it's not unheard of for a tag to be applied to less than a complete configuration (i.e. a subtree). Finally, if a file in the repository is lost there is no way to detect that it is missing until the compile breaks.