Discussion:
How to free up disk space for SVN server (other than removing log files suggested in FAQ)?
Cheng Wei Lee
2008-01-11 02:53:34 UTC
Permalink
Checked that there isn't much log files. Does deleting of files help in
recovering the disk space, since SVN doesn't really deletes any files? If it
doesn't, how else can I reclaim my disk space, if adding harddisks isn't a
viable option?

Cheers!
Andy Levy
2008-01-11 03:27:04 UTC
Permalink
Post by Cheng Wei Lee
Checked that there isn't much log files. Does deleting of files help in
recovering the disk space, since SVN doesn't really deletes any files?
Won't recover any space at all. If you dump the repository, then run
it through svndumpfilter to strip out items you don't want in the
repository at all, then reload it, you can reclaim space. At the
expense of losing history.
Post by Cheng Wei Lee
If it
doesn't, how else can I reclaim my disk space, if adding harddisks isn't a
viable option?
If your repository is using an older release of SVN, or has large
amounts of data/numbers of revisions which were created under an older
version, you /may/ see a size reduction by doing a dump/load cycle
using 1.4. But there's no guarantee there.

You can't free up a large amount of space without dropping history.
Disk is cheap; buy more.
Andy Levy
2008-01-11 11:57:38 UTC
Permalink
Please use Reply To All to ensure that replies stay on-list.
Yep, agree that disk is cheap, but I can't convince those system
administrator that.
If your system administrator won't address the needs of his users,
he's useless. If you're properly using SVN and not bloating the
repository with massive files that don't need to be versioned, then
the sysadmin is not doing his job properly by not giving you the space
required.
Is there some way that I can like archive the repository
into a dump file, then like what you say strip of some history to reclaim
space?
svndumpfilter. See the FAQ and book. But it seems rather foolish to
have to destroy history just to avoid buying a larger disk -
especially since in some cases, selectively removing things from
history can make the repository *bigger*. Destroying history negates
one of the benefits of using Subversion in the first place. My audit
department would lobby for the termination of my employment if I were
to make that choice (fortunately, my department's decision-makers
would prevent that by giving me the disk space required for the
system).
Post by Andy Levy
Post by Cheng Wei Lee
Checked that there isn't much log files. Does deleting of files help in
recovering the disk space, since SVN doesn't really deletes any files?
Won't recover any space at all. If you dump the repository, then run
it through svndumpfilter to strip out items you don't want in the
repository at all, then reload it, you can reclaim space. At the
expense of losing history.
Post by Cheng Wei Lee
If it
doesn't, how else can I reclaim my disk space, if adding harddisks isn't
a
Post by Andy Levy
Post by Cheng Wei Lee
viable option?
If your repository is using an older release of SVN, or has large
amounts of data/numbers of revisions which were created under an older
version, you /may/ see a size reduction by doing a dump/load cycle
using 1.4. But there's no guarantee there.
You can't free up a large amount of space without dropping history.
Disk is cheap; buy more.
Talden
2008-01-12 06:22:27 UTC
Permalink
Post by Andy Levy
Post by Cheng Wei Lee
Checked that there isn't much log files. Does deleting of files help in
recovering the disk space, since SVN doesn't really deletes any files?
Won't recover any space at all. If you dump the repository, then run
it through svndumpfilter to strip out items you don't want in the
repository at all, then reload it, you can reclaim space. At the
expense of losing history.
Unless of course there are branches and tags as cheap copies of the
paths that you filter out. In which case the repository will get
bigger since all of those cheap copies become full files each.

--
Talden
Andreas Schweigstill
2008-01-15 09:20:22 UTC
Permalink
Hello!
Post by Talden
Unless of course there are branches and tags as cheap copies of the
paths that you filter out. In which case the repository will get
bigger since all of those cheap copies become full files each.
In older Subversion releases it was possible to corrupt one's repository
by filtering out files using svndumpfilter that had been moved or copied
Has this been fixed for all circumstances in current 1.4 releases? Or
will this be a new feature for 1.5?

With best regards
Andreas Schweigstill
--
Dipl.-Phys. Andreas Schweigstill
Schweigstill IT | Embedded Systems
Schauenburgerstraße 116, D-24118 Kiel, Germany
Phone: (+49) 431 5606-435, Fax: (+49) 431 5606-436
Mobile: (+49) 171 6921973, Web: http://www.schweigstill.de/
Cheng Wei Lee
2008-01-17 12:54:52 UTC
Permalink
So other than buying/adding new disks, there's no out-of-the-box feature
from SVN to reclaim space?
Post by Andreas Schweigstill
Hello!
Post by Talden
Unless of course there are branches and tags as cheap copies of the
paths that you filter out. In which case the repository will get
bigger since all of those cheap copies become full files each.
In older Subversion releases it was possible to corrupt one's repository
by filtering out files using svndumpfilter that had been moved or copied
Has this been fixed for all circumstances in current 1.4 releases? Or
will this be a new feature for 1.5?
With best regards
Andreas Schweigstill
--
Dipl.-Phys. Andreas Schweigstill
Schweigstill IT | Embedded Systems
Schauenburgerstraße 116, D-24118 Kiel, Germany
Phone: (+49) 431 5606-435, Fax: (+49) 431 5606-436
Mobile: (+49) 171 6921973, Web: http://www.schweigstill.de/
---------------------------------------------------------------------
Marc Haisenko
2008-01-17 13:00:06 UTC
Permalink
Post by Cheng Wei Lee
So other than buying/adding new disks, there's no out-of-the-box feature
from SVN to reclaim space?
Correct.
Marc
--
Marc Haisenko

Comdasys AG
Rüdesheimer Str. 7
80686 München
Germany

Tel.: +49 (0)89 548 433 321
Loading...