On Wed, Dec 15, 2010 at 06:44, Johan Corveleyn <jcor...@gmail.com> wrote: > On Mon, Dec 13, 2010 at 10:23 PM, David Weintraub <qazw...@gmail.com> wrote: >> On Mon, Dec 13, 2010 at 3:04 PM, Johan Corveleyn <jcor...@gmail.com> wrote: >>> Hi, >>> >>> I'm wondering if there is a (de-facto) standard way of "end-of-lifing" >>> projects in an SVN repository, or any suggestions for this from other >>> users on this list ... >>>> >>> I know I could just "svn rm" them, but some of the "project owners" >>> feel a little bit uneasy about that. >> >> Do they know that doing a "svn rm" doesn't actually remove those >> projects from the repository? All "svn rm" does is remove them from >> the HEAD of the repository. They can still access all the history, >> tags, branches and what not by simply using the -r <revision> >> parameter when you do a Subversion command. And, they can find out the >> revision by doing a "svn log". >> >> However, if that's to scary for them, create an "obsolete" folder and >> move all the projects in there. Then, via pre-commit hook or >> configuration, make all files and directories under "obsolete" >> read-only: >> >> +--obsolete (Whole subtree is read only) >> | | >> | trunk >> | branches >> | tags >> | >> +--trunk (Still read/write) >> +--branches (Still read/write) >> +--tags (Still read/write) >> >> That'll get the files out of the main project tree, prevent further >> changes in the code, yet still allow the developers to examine the >> code and reminisce about the good ol' days when men were men and UUCP >> was king. > > Thanks for the suggestions, all. I think I'm gonna go for David's > suggestion here above. I.e. create a top-level "obsolete" directory > with TTB inside, and "svn mv" the obsolete stuff in there. > > I'll take a look at making the obsolete directory "read-only" (or > add-only, like for tags). Thanks to David, I have this great perl > script lying around, which can be easily configured to enforce this > from my pre-commit hook :-).
If you just need to set the whole directory read-only unilaterally, you don't need a pre-commit hook; just use the built-in path-based authorization.
