I don't use CVS, but with the version control systems I have used, directly manipulating file system objects (renaming or deleting files or directories) used by the VC software is asking for horrendous problems. One of the most important benefits of VC systems is the ability to rebuild old versions, and this benefit is generally lost if you go behind the system's back to make such changes. This may or may not be the case with CVS, but no such change should be made unless we're certain it's benign. Jason's approach seems sound to me, but again, I don't have significant experience using CVS.
-----Original Message----- From: Renji Panicker [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 28, 2001 11:12 PM To: [EMAIL PROTECTED] Subject: CVS: RE: Plan for Xerces-C++ 1.6 I have found that renaming the sub-directory in my cvsroot does the trick. I don't kno how safe it is supposed to be, but I've not had a problem with it so far. -----Original Message----- From: Jason E. Stewart [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 28, 2001 1:49 AM To: [EMAIL PROTECTED] Subject: Re: Plan for Xerces-C++ 1.6 "Tinny Ng" <[EMAIL PROTECTED]> writes: > > Remember that this will require a cvs change. We need to rename the src directory > > to xercesc. Some cvs experts gave some advice about that at the time. > > > > Since CVS cannot rename, the cleanest way is to create everything as new directory > and new files, and then delete the old directory "src". And as far as I know, the > deleted directory information is still stored in CVS "Attic" and is still > accessible. Thus we can still access old history log if needed. As long as you mean 'remove' as in 'cvs remove' then you're correct. The real advantage to doing it that way is all the old tags still work, so that you can check out historical copies. The (slight) disadvantage is that all the history that should be associated with the file is in two separate places. It's unfortunate that CVS forces you to remove a file and then re-add it when it should just have a 'move' command. Luckily it seems that subversion (subversion.tigris.org) will be ready for general use pretty soon. I've got a couple of test repositories using the latest alpha of subversion and I'm pretty happy. jas. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
