[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Parmently removing directory from server to make space

From: Anil Bakshi <Anil.Bakshi_at_aptaracorp.com>
Date: Tue, 26 Mar 2013 16:19:22 +0530

Thanks Ryan,

Your suggestions are really eye opener for me. I will follow the
separate repository for each project.

But now I am stuck.

Regards,
Anil Kumar Bakshi
Sr. Multimedia Programmer | Education and Learning

Aptara, Inc. | Transforming Content into Knowledge
anil.bakshi_at_aptaracorp.com | aptaracorp.com
A-28, Mohan Cooperative Industrial Estate,
Mathura Road | New Delhi - 110044 | India
Mobile +91 9818907948

 

-----Original Message-----
From: Ryan Schmidt [mailto:subversion-2012c_at_ryandesign.com]
Sent: Tuesday, March 26, 2013 4:05 PM
To: Anil Bakshi
Cc: users_at_subversion.apache.org
Subject: Re: Parmently removing directory from server to make space

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.
Received on 2013-03-26 11:49:59 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.