> -----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
Received on Wed Mar 7 14:11:10 2007