Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Using 2.5.03, Build 2382, I've found two bugs in cvs rename that required manual hacking of the repository for recovery: Problem 1: given subdirs a, b, and file a/foo cvs rename a/foo b/foo is accepted with no complaint, but results in the rename happening in dir a but not in dir b. The file essentially disappears. Recovery requires reverting the last revision in .directory_history,v for directory a, which requires hacking the repository. Note that: cd a; cvs rename foo ../b/foo works as advertised. E.g., a file can be moved from one directory to another, but only when executed from the current directory of the file. Problem 2: as above, but renames have happened on a branch in directory b but not on HEAD. Therefore, .directory_history has status DEAD in b. cvs rename foo ../b/foo; cd ../b; cvs commit results in an error in attempting to update .directory_history, apparently because it does not actually exist on HEAD. The fix I found is to cause .directory_history to exist but be empty on HEAD: in the repository for dir b: mv .directory_history,v dfoo,v in the sandbox directory b: touch dfoo cvs add dfoo cvs commit dfoo Then back in the repository: mv dfoo,v .directory_history,v Also, there is an annoyance: the documentation indicates after a move, cvs commit should be run from the parent directory. I find cvs commit must be run from within each directory where a rename action has occurred to actually do anything. When run from a parent directory, cvs commit does nothing. Mark