> -----Original Message----- > From: Johan Corveleyn [mailto:jcor...@gmail.com] > Sent: 13 December 2010 20:04 > To: users@subversion.apache.org > Subject: Archiving Projects (End-Of-Life) > > 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 ... > > With End-Of-Life I mean there will be no further maintenance on that > project, no more development, no more releases or patches, no more > users. It's really dead. But sometimes one might want to take a look > at the old code, check out its history, maybe even resurrect it, ... > I would like to get those projects out of sight, so it's more clear > what the active projects are. (I'm not talking about "obliterating", > to reclaim disk space or anything like that, quite the contrary: I > want to have them still available, just ... less visible). > > I know I could just "svn rm" them, but some of the "project owners" > feel a little bit uneasy about that. They consider it "probable" that > they will need to take another look at them sometime in the future. > And as we all know, it's not so easy to find a deleted > file/directory/project again (to find out what the latest revision was > in which the project still existed). > > My repository is currently structured as: > > trunk > \--project1 > \--project2 > \--... > branches > tags > > But I think the question is more or less the same if it's structured > in the other standard way (projects/TTB). > > Currently I have two options in mind: > - Move the EOL'ed projects to a new directory "archive", a new "root" > directory next to TTB. > - Move the EOL'ed projects to a tag (maybe also in an "archive" > subdirectory, under tags). If it ever needs to be resurrected, it can > be easily copied from that tag. > > Thoughts? Other ideas? Pros and cons? > I use separate repos (using parent path) for all projects unless closely related, and this is one of the main reasons why I do so. A little bit of extra work when creating new projects is a lot simpler than dumpfiltering projects out late in the lifecycle.
I'd be interested in any strong arguments for using one repo over many! ~ mark c
