Forum OpenACS Development: direct manipulation of CVS repository and shifting packages into /contrib/obsolete-packages

it looks like a bunch of packages have been moved into /contrib/obsolete-packages on the CVS server by direct manipulation of the repository (photo-album, acs-content, acs-util, acs-workflow, bboard, bboard-portlets, mp3-jukebox, photo-album-lite, portal, postcard, ticket-tracker, ticket-tracker-lite, wap, wf-ticket-tracker)...

by directly manipulating the repository, there is now no record on the CVS server that these used to live in /packages and /contrib/packages, so doing a cvs up -Pd will not delete them from their existing location in my working copy since as far as the repository is concerned they were never deleted from there...

as a heads-up for CVS users, any directory you see this kind of error message for

cvs server: cannot open directory /cvsroot/openacs-4/packages/acs-util: No such file or directory
cvs server: skipping directory packages/acs-util
should be deleted manually in your working copy... it might also be worth fixing the repository by copying those directories back to their previous locations and then cvs rming them so that people's working copies will clean themselves up correctly the next time they update...
This has also broken all tags made prior to the change. If I (for example) want to bring something up to date that was implemented on oacs-4-6-2-final and perhaps used the old acs-workflow package, and I were to try and use CVS to find a nice small representation of the local changes, I would find that it was impossible because "oacs-4-6-2-final" no longer refers to the same thing it used to, it refers to the old oacs-4-6-2-final except with some of the core packages moved out to the obsolete directory.

This is, in my personal opinion, not acceptable. If the packages affected were all non-core it might be easier to wear, but 3 of them were previously "core", so this will screw people looking (for example) to upgrade from previous versions to OACS5.

Yes, this can be worked around, but we have revision control for a reason.

Hi Russell,

Is it safe to rm my local instance?  Fortunately for me currently its just an annoyance.  Although maybe in the near future I will be likely on the same boat as you.

Jun - are you following HEAD? If so then this is a non-issue for you - just delete the directories in your checked-out copy that cvs is complaining about and you'll be right. The problem is if you have checked-out sources against 4.x release tags, in which case the repository now has a different idea of what constitutes 4.whatever than it used to.
So exactly what should be done on the CVS repository to put things they way they should be, including having the obsoleted packages moved out of /packages?
This is one of the problems with CVS - there's no way of moving files or directories around that doesn't somehow suck. The easiest way in this case would be
  • copy (not move) the directories in the repository back to where they came from
  • do a full update in a -HEAD checkout, there should now be copies of these packages in both the old and new locations
  • use "cvs rm" to delete the files and directories from the old locations in the checkout
This will fix the revision history, but for 4.x releases also leave a second copy of these packages in the obsolete directory. To remove these, use "cvs tag -d tagname" to delete all the existing non-branch tags from the copies in the new location.

Relevant section of the CVS manual is at