You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Suelmar Castro <su...@yahoo.com.br> on 2007/03/06 17:20:01 UTC
Repository size!?
Hi guys,
what should i do when my repository becames to large? Can i delete oldest revision?
__________________________________________________
Fale com seus amigos de graça com o novo Yahoo! Messenger
http://br.messenger.yahoo.com/
RE: Repository size!?
Posted by Erik Hemdal <er...@comprehensivepower.com>.
> -----Original Message-----
> From: Ryan Schmidt [mailto:subversion-2007a@ryandesign.com]
> On Mar 6, 2007, at 13:35, Jared Hardy wrote:
>
> > That sounds a little too dangerous. The way FSFS works makes it
> > possible that the "oldest" revision files can hold
> necessary pieces of
> > "newest" files. I think the semi-officially supported route
> is moving
> > old revisions to different (larger, slower) volumes, including over
> > NFS, and then soft-linking ("ln -s ..." in UNIX) them from their
> > original position in the FSFS tree. Shut down and svn or
> Apache server
> > access while you're doing this, just to be safe. Also be careful to
> > keep the ACLs the same on the new volume.
>
> Yeah, that should work.
>
> > There is also an "svnobliterate.py" script in the contrib area
> > somewhere, but I'm not that familiar with its proper use,
> so details
> > will have to come from elsewhere. Otherwise, you will have to
> > "svnadmin dump ..." to another larger volume, and get
> really familiar
> > with the use of svndumpfilter. Loading a dump file into a
> 1.4.x FSFS
> > repository, from an older version, will also cut the space used in
> > about half, in my experience.
>
> I thought "svnobliterate" / "svnadmin obliterate" was a concept that
> had been proposed but that nothing had been implemented yet.
>
> If you want to throw away the history of the first, say, 1000
> revisions, you should be able to use "svnadmin dump" to dump
> revisions 1001 thru HEAD, then move your repository out of the way,
> then create a new repo, then load in the dumpfile. However, I
> believe
> this will renumber your revisions, so all existing working copies
> will become unusable and you will need to throw them away and check
> out new working copies. Also, if the files that were in the first
> 1000 revisions are still around in the repository today, then
> getting
> rid of the first 1000 revisions may not help you save any space. You
> could try it out as a test -- just dump recent revisions, load them
> into a new repository, and see if it's any smaller.
Ryan is exactly right here. I tried this on a test copy of one of my
repositories. When I was done, the repository with less history in it was
larger than the original. When you cut down the repository, many of your
deltas will become complete files (because you removed the base files they
were delta'd from). And you'll have complete files in places where you used
to have cheap copies, because the original file that let them be cheap is
now gone. So you can end up with a larger repository.
Another issue arises if your log entries refer to revision numbers, because
your revision numbers in the new repository will all be different. If I
drop the first 100 revisions, then what I logged as revision 101 now becomes
revision 1. But the log entries won't be automatically updated.
Erik
>
>
> --
>
> To reply to the mailing list, please use your mailer's Reply To All
> function
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Repository size!?
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Mar 6, 2007, at 13:35, Jared Hardy wrote:
> That sounds a little too dangerous. The way FSFS works makes it
> possible that the "oldest" revision files can hold necessary pieces of
> "newest" files. I think the semi-officially supported route is moving
> old revisions to different (larger, slower) volumes, including over
> NFS, and then soft-linking ("ln -s ..." in UNIX) them from their
> original position in the FSFS tree. Shut down and svn or Apache server
> access while you're doing this, just to be safe. Also be careful to
> keep the ACLs the same on the new volume.
Yeah, that should work.
> There is also an "svnobliterate.py" script in the contrib area
> somewhere, but I'm not that familiar with its proper use, so details
> will have to come from elsewhere. Otherwise, you will have to
> "svnadmin dump ..." to another larger volume, and get really familiar
> with the use of svndumpfilter. Loading a dump file into a 1.4.x FSFS
> repository, from an older version, will also cut the space used in
> about half, in my experience.
I thought "svnobliterate" / "svnadmin obliterate" was a concept that
had been proposed but that nothing had been implemented yet.
If you want to throw away the history of the first, say, 1000
revisions, you should be able to use "svnadmin dump" to dump
revisions 1001 thru HEAD, then move your repository out of the way,
then create a new repo, then load in the dumpfile. However, I believe
this will renumber your revisions, so all existing working copies
will become unusable and you will need to throw them away and check
out new working copies. Also, if the files that were in the first
1000 revisions are still around in the repository today, then getting
rid of the first 1000 revisions may not help you save any space. You
could try it out as a test -- just dump recent revisions, load them
into a new repository, and see if it's any smaller.
--
To reply to the mailing list, please use your mailer's Reply To All
function
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Repository size!?
Posted by Jared Hardy <ja...@gmail.com>.
On 3/6/07, Suelmar Castro <su...@yahoo.com.br> wrote:
> what should i do when my repository becames to large? Can i delete oldest
> revision?
That sounds a little too dangerous. The way FSFS works makes it
possible that the "oldest" revision files can hold necessary pieces of
"newest" files. I think the semi-officially supported route is moving
old revisions to different (larger, slower) volumes, including over
NFS, and then soft-linking ("ln -s ..." in UNIX) them from their
original position in the FSFS tree. Shut down and svn or Apache server
access while you're doing this, just to be safe. Also be careful to
keep the ACLs the same on the new volume.
There is also an "svnobliterate.py" script in the contrib area
somewhere, but I'm not that familiar with its proper use, so details
will have to come from elsewhere. Otherwise, you will have to
"svnadmin dump ..." to another larger volume, and get really familiar
with the use of svndumpfilter. Loading a dump file into a 1.4.x FSFS
repository, from an older version, will also cut the space used in
about half, in my experience.
Jred
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org