> -----Original Message-----
> From: Johan Corveleyn [mailto:jcorvel_at_gmail.com]
> Sent: 13 December 2010 20:04
> To: users_at_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
Received on 2010-12-14 11:03:23 CET