Re : Re: filter a dump without deleted files

[Nicolas <n....@atlantis-software.net>]

Thanks for you answer. I know this  method but i have a lot of files and directory that can't be passed as arguments because my argument list is too long....Is it possible that svndumpfiler read excludes from a file ?Or another utility for doing this ?If i use the solution of dumping the HEAD revision how can i  create empty revisions in the new repositoryfrom 1 to HEAD  - 1 and load the dump after, for constitency of the already checkout users.Sorry for my english ...Escuder Nicolas__________________________________________________________________________

Le : 27/04/09 à 01:02
De : Ryan Schmidt
A : n.escuder@atlantis-software.net
CC : users@subversion.tigris.org
Objet : Re: filter a dump without deleted files
__________________________________________________________________________


On Apr 26, 2009, at 17:05, Nicolas wrote:

> How can i filter my dump file for removing history and deleted files ?
>
> Is there an utility for this ?

If you would li!
 ke to permanently remove files which have been deleted  
in HEAD, you will have to figure out the path those files used to be  
at, and filter them out of the dump, either with svndumpfilter or a  
more advanced tool like svndumptool. If the file had ever been moved  
or renamed during its lifetime, you'll have to list all the paths the  
file used to be at.


For removing some amount of past history, just don't dump that part.  
For example, to discard the first 1000 revisions of history, you could

svnadmin dump -r1000:HEAD /path/to/repo > dumpfile

Note, though, that removing history can *increase* the size of your  
repository, depending on what's in that history. For example, if in  
revisions before 1000 you made several copies of something -- for  
example you created 5 branches from trunk -- then Subversion has  
stored those as a cheap copy. If you now destroy revisions before  
1000, Subversion has no choice but to store 5 completely separate  
copies of the br!
 anch in your repository, which takes more space.  
Though, if !
 I understand it correctly, Subversion 1.6's new  
representation sharding feature may mitigate this:

http://subversion.tigris.org/svn_1.6_releasenotes.html#rep-sharing

Even if disk space is not increased, you would lose the knowledge  
that those five branches were at one time copied from a common  
ancestor. I'm not sure if this would have any other implications, for  
example for merging.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1963258

To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].