You cannot easily refactor code into seperate modules, used by multiple projects, with keeping of history.
Another easy one. ;) Hth, Nick Stolwijk ~Senior Java Developer~ iPROFS Wagenweg 208 2012 NM Haarlem T +31 23 547 6369 F +31 23 547 6370 I www.iprofs.nl On Tue, Dec 14, 2010 at 11:02 AM, Cooke, Mark <mark.co...@siemens.com> wrote: >> -----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 >