subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Schmidt <subversion-20...@ryandesign.com>
Subject Re: Parmently removing directory from server to make space
Date Tue, 26 Mar 2013 10:35:11 GMT

On Mar 26, 2013, at 02:25, Anil Bakshi wrote:

> Now our server is out of space and we decide to permanently remove few projects from
server.

If your projects are in individual repositories, this is easy: archive these old projects'
repositories to DVD, ideally in a future-proof format like a dumpfile, along with any special
repository configuration files or hook scripts, then delete the repositories from the server.
But if all your projects are in a single massive repository, then this is difficult.

Permanently removing some repository contents is an oft-requested feature, but it is difficult
to do at present, partly because it goes against the primary purpose of Subversion, which
is to keep a complete and unaltered history of your changes.

Understand that if you do manage to dump, filter, and load the parts of your old repository
that you want to keep into a new repository, the new repository will (must) have a new UUID,
meaning all existing working copies that your developers might have will need to be thrown
away and new working copies checked out. Your developers need to either check in all their
work before you perform this repository surgery, or will have to manually move their uncommitted
work from their old working copies to new ones. If you have many developers, this can add
up to a lot of inconvenience and a lot of wasted developer time.

Consider whether it would be a more effective use of time and money to purchase additional
storage space for the server. Hard drives are pretty cheap compared with the cost of developer
time. You can use symlinks of individual revision files to allow a large repository to span
more than one disk if necessary.

Also consider whether new projects could be started as individual repositories from now on,
instead of going into the single monolithic repository, to make these kinds of cleanup operations
easier in the future. If you're doing repository surgery now, you could also think about splitting
each project into its own repository now, so that you hopefully won't ever have to do this
again.




Mime
View raw message