Re: Any consequences over removing a subdir permanently?
S I wrote: > > Hi > > I know how to delete and commit files to the attic and on the next checkout > do a -P to prune out empty dirs but I have not seen any documentation on how > to remove empty dirs/subdirs permanently. Is this not recommended lest you > have to retrieve dead files later? And CVS wouldn't know what structure to > retrieve them to? Should I or not delete the empty dirs on the server side > or too dangerous? We have many, and I mean many, empty dirs just sitting > there! Deleting anything permanently out of a version control system is _usually_ a _very_ BAD idea. However if your project management really desires it, keep your self sane with a good backup, and go directly into the repository and `rm -fr offensive_directory_structure`. The reason that cvs does not have a built-in command (that I am aware of) for doing this is that it is such a _very_ BAD idea. Got permission and a backup? Happy hunting. :) -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Any consequences over removing a subdir permanently?
Thank you as always. Do you think though that deleting a dir and later retrieving a dead file would confuse the dead file where to implant itself? I have a dummy repository and I'm going to try this to find out the outcome. The subdirs I speak of are about 5 years old and don't think anyone would care. We have restructured our code so many times and we may soon port over to a completely clean repository without its history. So in our case it shouldn't matter but I see your point about NOT exercising this. Thanks. :) Original Message Follows From: Todd Denniston <[EMAIL PROTECTED]> To: S I <[EMAIL PROTECTED]> CC: info-cvs@gnu.org Subject: Re: Any consequences over removing a subdir permanently? Date: Thu, 14 Jul 2005 12:13:32 -0500 MIME-Version: 1.0 Received: from mail.ssa.crane.navy.mil ([164.227.42.3]) by mc7-f2.hotmail.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 14 Jul 2005 10:13:35 -0700 Received: from ssa.crane.navy.mil ([EMAIL PROTECTED] [164.227.42.142]) by mail.ssa.crane.navy.mil with ESMTP id MAA27385; Thu, 14 Jul 2005 12:15:22 -0500 X-Message-Info: JGTYoYF78jEHjJx36Oi8+Z3TmmkSEdPtfpLB7P/ybN8= Organization: Code 6067, NSWC Crane X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.25glock1 i686) X-Accept-Language: en References: <[EMAIL PROTECTED]> Return-Path: [EMAIL PROTECTED] X-OriginalArrivalTime: 14 Jul 2005 17:13:35.0856 (UTC) FILETIME=[5E9AA700:01C58897] S I wrote: > > Hi > > I know how to delete and commit files to the attic and on the next checkout > do a -P to prune out empty dirs but I have not seen any documentation on how > to remove empty dirs/subdirs permanently. Is this not recommended lest you > have to retrieve dead files later? And CVS wouldn't know what structure to > retrieve them to? Should I or not delete the empty dirs on the server side > or too dangerous? We have many, and I mean many, empty dirs just sitting > there! Deleting anything permanently out of a version control system is _usually_ a _very_ BAD idea. However if your project management really desires it, keep your self sane with a good backup, and go directly into the repository and `rm -fr offensive_directory_structure`. The reason that cvs does not have a built-in command (that I am aware of) for doing this is that it is such a _very_ BAD idea. Got permission and a backup? Happy hunting. :) -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Any consequences over removing a subdir permanently?
S I wrote: > > Thank you as always. > > Do you think though that deleting a dir and later retrieving a dead file > would confuse the dead file where to implant itself? Well ... if you "rm -fr"'d the directory structure the file was in, you'll likely be confused yourself, because not only is there no dead file to retrieve but there is no attic. :) This is the reason it is _usually_ a _very_ BAD idea to remove things from the repository. Because when they are gone from the version control file system / database they are GONE, NOT COMING BACK, DESTROYED. > I have a dummy > repository and I'm going to try this to find out the outcome. That is good practice, keep it up. :) > > The subdirs I speak of are about 5 years old and don't think anyone would > care. Be SURE, don't just think it. 8O > We have restructured our code so many times and we may soon port over > to a completely clean repository without its history. So in our case it > shouldn't matter but I see your point about NOT exercising this. A middle ground might be: 1) tell everyone to commit all changes they have currently. 2) backup to cold storage media. 3) copy the CVS tree to a new location. 4) do a checkout from the new location and then do a `cvs watch on -R` against that checkout. 5) find and mark all the directories in the new copies location read only, and setup a lockdir for it so people can do readonly checkouts. (lock it down) 6) again backup to cold storage media. 7) remove the unused directories. This should leave you with a copy in the new location for people who need to know the ancient history, a copy to recover from if you hit enter on the rm in the wrong directory, and a smaller repo but with all the history since the each of the files were last restructured. > > Thanks. :) > -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Any consequences over removing a subdir permanently?
Todd Denniston wrote: > Clerity demands I respond to my own post. sorry. > S I wrote: > > > > We have restructured our code so many times and we may soon port over > > to a completely clean repository without its history. So in our case it > > shouldn't matter but I see your point about NOT exercising this. > > A middle ground might be: > 1) tell everyone to commit all changes they have currently. > 2) backup to cold storage media. > 3) copy the CVS tree to a new location. > 4) do a checkout from the new location and then do a `cvs watch on -R` > against that checkout. > 5) find and mark all the directories in the new copies location read only, > and setup a lockdir for it so people can do readonly checkouts. (lock it > down) > 6) again backup to cold storage media. 7) remove the unused directories, in the original (and still current) version of the repo, i.e., no one has to change their CVSROOT values. 8) if people still have sand boxes from before there may be some difficulty in doing updates and such, have them check that `cvs update -dP` command works with out error at a minimum. If your really sure just have them remove all their old sandboxes and start fresh. > > This should leave you with a copy in the new location for people who need to > know the ancient history, a copy to recover from if you hit enter on the rm > in the wrong directory, and a smaller repo but with all the history since > the each of the files were last restructured. -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Any consequences over removing a subdir permanently?
Thanks for the input and all the helpful info. I'm glad I posted :) Original Message Follows From: Todd Denniston <[EMAIL PROTECTED]> To: S I <[EMAIL PROTECTED]>, info-cvs@gnu.org Subject: Re: Any consequences over removing a subdir permanently? Date: Thu, 14 Jul 2005 14:26:30 -0500 MIME-Version: 1.0 Received: from mail.ssa.crane.navy.mil ([164.227.42.3]) by MC6-F16.hotmail.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 14 Jul 2005 12:29:41 -0700 Received: from ssa.crane.navy.mil ([EMAIL PROTECTED] [164.227.42.142]) by mail.ssa.crane.navy.mil with ESMTP id OAA27690; Thu, 14 Jul 2005 14:28:20 -0500 X-Message-Info: JGTYoYF78jHlrUEQ9SNZpCQAWdASPfyipP4Os14W2EY= Organization: Code 6067, NSWC Crane X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.25glock1 i686) X-Accept-Language: en References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Return-Path: [EMAIL PROTECTED] X-OriginalArrivalTime: 14 Jul 2005 19:29:41.0641 (UTC) FILETIME=[61CA8F90:01C588AA] Todd Denniston wrote: > Clerity demands I respond to my own post. sorry. > S I wrote: > > > > We have restructured our code so many times and we may soon port over > > to a completely clean repository without its history. So in our case it > > shouldn't matter but I see your point about NOT exercising this. > > A middle ground might be: > 1) tell everyone to commit all changes they have currently. > 2) backup to cold storage media. > 3) copy the CVS tree to a new location. > 4) do a checkout from the new location and then do a `cvs watch on -R` > against that checkout. > 5) find and mark all the directories in the new copies location read only, > and setup a lockdir for it so people can do readonly checkouts. (lock it > down) > 6) again backup to cold storage media. 7) remove the unused directories, in the original (and still current) version of the repo, i.e., no one has to change their CVSROOT values. 8) if people still have sand boxes from before there may be some difficulty in doing updates and such, have them check that `cvs update -dP` command works with out error at a minimum. If your really sure just have them remove all their old sandboxes and start fresh. > > This should leave you with a copy in the new location for people who need to > know the ancient history, a copy to recover from if you hit enter on the rm > in the wrong directory, and a smaller repo but with all the history since > the each of the files were last restructured. -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
