Re : Re: filter a dump without deleted files

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_at_atlantis-software.net
CC : users_at_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_at_subversion.tigris.org].
Received on 2009-04-28 14:34:55 CEST