Tom Lane wrote:
AFAICS the only nondestructive way to do this is to cvs delete and cvs add, with a commit comment saying where the files were moved from. Then when you are looking at them in CVS, you'd have to navigate over to the previous location (by hand, probably; the commit comment isn't going to automate this for you) and look in the Attic to read the prior CVS history. It's not impossible, certainly, but it discourages moving files for less than the very best of reasons.
You can also do a repository-side copy of the ,v file to the new location, remove old tags & branches from that new copy, and 'cvs delete' the old copy. That preserves history but the file should still show up in the old location (and not also in the new location) when older versions are checked out. In theory. It's all very hairy..
(I'm rather interested to know whether any other SCMs have a better solution to this problem, and if so what it is. It's not obvious how to do better.)
Subversion deals with this reasonably well. The main difference to CVS is that it does not try to track multiple lines of development in a particular file; instead, you make (internally cheap) copies *within* the repository tree when you branch or tag.
Once you have that, it's much easier to track file copies and deletions, as each path in the repository effectively has a linear history. A rename is just a copy and delete.
See http://svnbook.red-bean.com/svnbook-1.0/ch04s02.html for some more detail.
-O
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
