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.cooke_at_siemens.com> wrote:
>> -----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 12:03:43 CET