No, the directory name will be the same (new) name for current and for older revisions. I think normally this won't disturb, because in most cases you will revert only to an older version of one or a few single files - but if you want to revert to the old strategy (in this case: no more using the sane_include patch) you will of course have to rename the directory in the repository back manually again.
Jesse Pelton wrote: > > So, if the directories are just renamed at a shell prompt, CVS will still be > able to check out, say, version 1.3, and put files in the correct (old) > locations? > > -----Original Message----- > From: Michael Huedepohl [mailto:[EMAIL PROTECTED]] > Sent: Thursday, November 29, 2001 8:15 AM > To: [EMAIL PROTECTED] > Subject: Re: Plan for Xerces-C++ 1.6 > > We did this several times (renaming a directory in CVS) - > mainly with the same reasons (don't want to split the history, > avoid removing and creating large directories - double space!) > and we encountered not any serious problem. > The only point to put attention on is concurrent usage of the CVS > around the time when the directory is moved: The directories being > checked out may become invalid, leading to the need of removing > the directory at the client and checking it out again. So all > modifications should be committed before renaming the directory > - and this concerns only those users with write access. > > Jesse Pelton wrote: > > > > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
